From 456e1ce8c890ba08caa0b83122ea63492f51f869 Mon Sep 17 00:00:00 2001 From: Ade Lee Date: Nov 12 2015 15:45:40 +0000 Subject: [PATCH 1/4] add 10.3 specs file to toc --- diff --git a/doc/source/index.rst b/doc/source/index.rst index be9d8b7..47f0b44 100644 --- a/doc/source/index.rst +++ b/doc/source/index.rst @@ -28,6 +28,14 @@ Juno approved specs: specs/juno/* +10.3 approved specs: + +.. toctree:: + :glob: + :maxdepth: 1 + + specs/10.3/* + ================== Indices and tables ================== From eeb31cff81da03ed0b2ba57f9e76018e7e859119 Mon Sep 17 00:00:00 2001 From: Ade Lee Date: Nov 12 2015 15:46:33 +0000 Subject: [PATCH 2/4] Initial design for signing as a service This is just some exploratory notes as part of identifying the use cases. Detailed design to follow based on feedback. --- diff --git a/specs/10.3/signing_as_a_service.rst b/specs/10.3/signing_as_a_service.rst new file mode 100644 index 0000000..b455c78 --- /dev/null +++ b/specs/10.3/signing_as_a_service.rst @@ -0,0 +1,329 @@ +.. + This work is licensed under a Creative Commons Attribution 3.0 Unported + License. + + http://creativecommons.org/licenses/by/3.0/legalcode + +==================== +Signing as a service +==================== + +With the expansion of the role of the KRA to store more than encryption +keys and the addition of the ability to generate symmetric and +asymmetric keys, and with the extension of access to the KRA to +end-users through GSS_API, some new functionality is possible. + +In particular, it is attractive to offer signing-as-a-service (and +its complimentary verification service). In particular, one could +potentially generate an asymmetric key pair on the KRA, mark that key +as non-extractable, and use that key to sign various objects -- DNSSEC +records, jars, rpms, image digests etc. Clients could contact the +KRA to verify signatures. All this would happen without the key +ever leaving the KRA - or in the case of a backing HSM - ever being exposed +unencrypted outside the HSM. + + +Problem Description +=================== + +Some of the main use cases for a signing service are detailed below: + +1. Signing Jars +2. Signing RPMs +3. Signing Images (Glance images in Openstack) +4. Signing DNSSEC records + +Case 1: Signing Jars +-------------------- + +Jars are typically signed by the java tool jarsigner, and are verified either +by jarsigner or by the JRE. A signed jar has contains signature files which +are generated by the signing process. In particular: + +* A manifest file contains a listing of the class files and a hash of each + file. + +* A signature file (.SF extension) contains a list of the class files + and a hash of the manifest entry for each class file. It also contains + the hash of the entire manifest file. + +* A signature block file contains a cryptographic signature of the .SF file, + as well as the certificate/cert chain for the private key used for signing. + +* The default signature algorithm/ hash function combinations are: + + * DSA/ SHA-1 + * RSA/SHA-256 + * ECC/ECDSA + +* It is possible to define an alternative signer class and classpath using + the altsigner/altsignerpath option. An altsigner is a Java class that + extends the com.sun.ContentSigner abstract class. This class defines + a single abstract method generateSignedData() which takes in parameters - + ContentSignerParameters (source and algortithm etc.) and returns a + PKCS#7 signed data message. We could, for example, implement this + method to contact the KRA, upload the content and retrieve the signature + in a PKCS#7 or CMS signed message. + +Case 2: Signing RPMs +-------------------- + +RPMS are typically signed by a private key using the GPG protocol. +Currently, Fedora Infrastructure uses sigul, a Python opensource project +written by mitr to sign rpms. sigul consists of a client, a bridge (which +communicates with the client) and a server that contains the keys and does +the relevant signing. + +The bridge authenticates and passes on signing requests to the sigul server, +which retrieves the relevant signing key and ends up calling: + + rpm --addsign + +to add the signature. + +The server here would be the KRA, though we would need some Java bindings to +the RPM API if we wanted to implement --addsign in the tomcat server. + +Further investgation is required for this use case. In this case, its not +clear, for example, that sending back a CMS message from the KRA would be +sufficient. We may need to call "rpm --addsign" on the server and return the +result. + +Case 3: Signing images (glance in Openstack) +-------------------------------------------- + +Currently, image signing in Openstack is only partially implemented. Users +need to follow a rather complicated process to generate an RSA-PSS signature +for the hash of the image, and then provide that signature to glance when the +image is uploaded. They also need to upload the certificate, public and +private key to Castellan/Barbican. [3] + +Code currently exists in glance to verify the signature prior to storing the +image. Similar code is being proposed for nova, so that it can verify the +signature prior to using the image to start up a VM. + +Changes will later be proposed for nova to sign images on behalf of end-users, +when the images is created in nova. + +Currently the key manager code in castellan retrieves the key from Barbican +and creates the RSA-PSS signature in Castellan. It is very likely that when +Barbican adds signing/verification as a service in its interface, this will +be exposed through Castellan as a simple call to sign/verify the image hash +without the key ever being extracted from Barbican. + +There would then be calls like:: + + openstack cert create <> --> contacts Barbican and generates an + asymmetric key pair, returns a cert container reference which contains + references to public key, private key and certificate + + openstack image create --sign --cert-ref=X --private-key-ref=Y + +The flow for that last call could be something like the following: +1. glance wouldcreate hash of image (image_hash) + +2. call castelan sign(image_hash, private_key_ref, cert_ref, signing_params) + +3. call Barbican sign(image_hash, private_key_ref, signing_params) + +4. call dogtag_plugin sign(image_hash, private_key_ref, signing_params) + +5. call sign() on the kra (image_hash, private_key_ref) + +6. KRA creates the signature of the image_hash using selected private key + and signing params. For instance, this would create a RSA-PSS + signature using RSA key X with SHA-256 hashing algorithm. + KRA returns a CMS message. + +7. dogtag plugin unpacks the CMS message and returns the signature to barbican + -core. + +8. barbican passes back signature to glance, which stores all in metadata. + +There are variations of the above flow, but the essential requirement is for +the KRA to be able to generate a (currently) RSA-PSS signature using the +specified stored key. + +Case 4: DNSSEC + +DNSSEC has a bunch of different records that need to be signed. The signatures +and certificates are stored with these records, and are used to validate the +records. + +In this case, a DNSSEC server could pass some data to a signing server and ask +for the data to be signed. There are several key/algorithm pairs that are +specified to be supported by RFC 6605:: + +* RSA/SHA-1 (key size 1024/2048) +* ECC/ECDSA P-256/ SHA-256 +* ECC/ECDSA P-384/ SHA 384 +* RSA/SHA-256 +* RSA/SHA-512 + +An open question is performance in this case. How many of these small records +need to be signed at any particular time? Can we sign a bunch of these in +batch to reduce round trips? + +Proposed Change +=============== + +The primary advantage for a security point of view for hosting +signing-as-a-service (and complementarily verification-as-a-service) on the +KRA is that the signing key would remain securely in the location where the +keys are stored. As mentioned before, this means for instance that the +key is never exposed unencrypted outside of the KRA's cryptographic module. + +This proposal therefore focuses on this scenario. It is always possible to +simply store the key in the KRA, and simply extract the key and generate +signatures on a different server -- a DNSSEC server or sigul for instance. + +Generating the signatures on the KRA means a few things: + +* The data to be signed must be uploaded to the KRA. This has performance + and storage implications for large files, which MAY be an issue for rpms + and jars. Certainly we will need restrictions on the size of the object + to be signed. + +* We need to determine how the signing key (and certificate) are to be stored + on the KRA. The most straightforward method is probably to create a + certificate enrollment profile that allows for the signing certificate to + be archived through the CA-> KRA connector. + + Currently, encryption keys that are stored through the connector are stored + with the certificate, and it is possible to search the KRA for a private + key given a public key (or a certificate). + + There is probably some additional work here vis a vis the new authorization + work and tagging in the KRA, so that the escrowed keys are correctly tagged. + + Another possibility we will need to allow is for the end-user to upload a + certificate and signing key to the KRA as a package. This would be the case + where the certificate was not issued by out CA. We will need to expand the + key archival REST API to permit this (assuming that the relevant signatures + checks pass). + +* We need to determine which signing algorithms/signing key characteristics/ + signature types to support based on the use cases above. We probably should + not support cases which are no longer secure - MD5 or RSA keys with small + sizes, for instance. It would be nice to advertise the combinations we do + support through the REST API. + +* We need to determine how to return the data. My immediate thought was that + the KRA would return a CMS Signed Data Content-Type. Additional processing + of this output -- to say construct a signed jar or otherwise - would be done + using the REST client or pki CLI. Its not clear yet how to do this with a + signed RPM though. + + Alternatively, we could do all the relevant processing on the KRA, and + return specific format based on the use case. For instance, we would + return signed RPMS if the type is denoted as an RPM, a signed jar if the + type is defined as a jar etc. + + This architecture simplifies the deployment, but also increases the scope + of functionality that needs to be added to the KRA server itself. + +Alternatives +------------ + +More to be added later. + +Data model impact +----------------- + +TBD. + +REST API impact +--------------- + +TBD. + +Security impact +--------------- + +TBD. + +Notifications & Audit Impact +---------------------------- + +TBD. + +Command Line Client Impact +-------------------------- + +TBD + +Other end user impact +--------------------- + +TBD + +Performance Impact +------------------ + +TBD + +Cloning Impact +-------------- + +This should have little to no impact on cloning as all the records +will be replicated. + +Other deployer impact +--------------------- + +TBD + +Developer impact +---------------- + +TBD + +Implementation +============== + +Assignee(s) +----------- + +TBD + +Work Items +---------- + +TBD + +Dependencies +============ + +TBD + +Testing +======= + +TBD + +Documentation Impact +==================== + +TBD + +References +========== + +1. Jarsigner documentation: +https://docs.oracle.com/javase/7/docs/technotes/tools/windows/jarsigner.html + +2. ContentSigner definition: +http://www.docjar.com/html/api/com/sun/jarsigner/ContentSigner.java.html + +3. Sigul https://fedorahosted.org/sigul/ + +4. CMS https://tools.ietf.org/html/rfc5652 + +5. Image and signature preparation instructions for glance: +https://etherpad.openstack.org/p/liberty-glance-image-signing-instructions + +6. Blueprint for glance image signing: +https://specs.openstack.org/openstack/glance-specs/specs/liberty/image-signing-and-verification-support.html (overall glance spec) + +7. Another glance blueprint for nova changes: +https://review.openstack.org/#/c/188874/19/specs/mitaka/approved/image-verification.rst,cm (nova, scheduled for mitaka) From f0c7ad8b6e47130feb1c0a8f345cb2c2c96988e9 Mon Sep 17 00:00:00 2001 From: Ade Lee Date: Nov 16 2015 17:54:55 +0000 Subject: [PATCH 3/4] Added some comments based on discussions with edewata, cfu --- diff --git a/specs/10.3/signing_as_a_service.rst b/specs/10.3/signing_as_a_service.rst index b455c78..38442a0 100644 --- a/specs/10.3/signing_as_a_service.rst +++ b/specs/10.3/signing_as_a_service.rst @@ -22,6 +22,24 @@ KRA to verify signatures. All this would happen without the key ever leaving the KRA - or in the case of a backing HSM - ever being exposed unencrypted outside the HSM. +We should note that, up to now, we have not stored signing keys in the +KRA because this introduces the risk that these keys would be vulnerable to +a KRA agent or admin user. At that point, it would not be possible to content +in a "court of law" that only the user had access to the signing key and therefore +that the signature was non-repudiable. + +It is possible to escrow signing keys in the KRA using IPA Vault because these +keys are pre-encrypted prior to being stored in the Vault, so that to the +KRA admins, the contents stored are just an encrypted blob. + +For the KRA to actually do signing though, the keys would need to be +decipherable to the KRA and thereby possibly accessible to KRA agents. + +There are cases in which this security tradeoff may be acceptable. In particular, +for DNSSEC, we would be storing the signing key for a service user. This user +needs to have a signing key accessible online to be able to make changes to DNS +zones dynamically. There is arguably better security if the signing key never +leaves the KRA crypto module. Problem Description =================== From dadbe8d200834806e7bc70271690555c39143ddf Mon Sep 17 00:00:00 2001 From: Ade Lee Date: Mar 14 2016 15:35:27 +0000 Subject: [PATCH 4/4] Second draft of signing service design --- diff --git a/specs/10.3/signing_as_a_service.rst b/specs/10.3/signing_as_a_service.rst index 38442a0..aabd815 100644 --- a/specs/10.3/signing_as_a_service.rst +++ b/specs/10.3/signing_as_a_service.rst @@ -13,14 +13,12 @@ keys and the addition of the ability to generate symmetric and asymmetric keys, and with the extension of access to the KRA to end-users through GSS_API, some new functionality is possible. -In particular, it is attractive to offer signing-as-a-service (and -its complimentary verification service). In particular, one could -potentially generate an asymmetric key pair on the KRA, mark that key -as non-extractable, and use that key to sign various objects -- DNSSEC -records, jars, rpms, image digests etc. Clients could contact the -KRA to verify signatures. All this would happen without the key -ever leaving the KRA - or in the case of a backing HSM - ever being exposed -unencrypted outside the HSM. +In particular, it is attractive to offer signing-as-a-service. +One could potentally generate an asymmetric key pair on the KRA, +mark that key as non-extractable, and use that key to sign various objects - +DNSSEC records, jars, rpms, image digests etc. All this would happen +without the private key ever leaving the KRA - or in the case of a backing HSM - +ever being exposed unencrypted outside the HSM. We should note that, up to now, we have not stored signing keys in the KRA because this introduces the risk that these keys would be vulnerable to @@ -182,64 +180,103 @@ An open question is performance in this case. How many of these small records need to be signed at any particular time? Can we sign a bunch of these in batch to reduce round trips? -Proposed Change -=============== +Work Flows +---------- -The primary advantage for a security point of view for hosting -signing-as-a-service (and complementarily verification-as-a-service) on the -KRA is that the signing key would remain securely in the location where the -keys are stored. As mentioned before, this means for instance that the -key is never exposed unencrypted outside of the KRA's cryptographic module. +It is possible to imagine some of the following scenarios: -This proposal therefore focuses on this scenario. It is always possible to -simply store the key in the KRA, and simply extract the key and generate -signatures on a different server -- a DNSSEC server or sigul for instance. +1. In the simplest case, the user provides a hash to sign and specifies the + key and type of signature. The signature is returned immediately. -Generating the signatures on the KRA means a few things: +2. Approval Case: A bot creates and uploads some software packages and creates + a signing request. This request must be approved by a human before the + packages are signed. -* The data to be signed must be uploaded to the KRA. This has performance - and storage implications for large files, which MAY be an issue for rpms - and jars. Certainly we will need restrictions on the size of the object - to be signed. +3. A document requires the approval of N agents before being signed. -* We need to determine how the signing key (and certificate) are to be stored - on the KRA. The most straightforward method is probably to create a - certificate enrollment profile that allows for the signing certificate to - be archived through the CA-> KRA connector. +Proposed Change +=============== + +To handle all these cases, as well as the workflows above, we propose an +architecture containing many of the same functional components used in Dogtag +for certificate signing and secret archival/retrieval. + +1. A signing request service. This service would allow users to create + signing requests on a request queue in the internal DB. Using this service + could require authentication so that the requestor is identified. + + Methods would be provided for agents to approve requests and move them to + the APPROVED state. All approvers would be recorded in the approval + +2. A signing service which would process the APPROVED signing requests + asynchronously and generate the relevant signature. The signature could + then be stored with the signing request, and the request could be marked as + DONE. + +3. A signing profile service. A signing profile is a specification (similar + to a certificate profile) which specifies the policies and specifics for + a signing operation. Things that could be included: + + * name + * description + * requestor info - authentication and authorization plugins + * acceptance policy - number of agents required, who constitutes an agent + * data to be signed info - type (hash, data, rpm, jar ...), + location (data provided in request, or link to local file or directory + and file pattern) + * signature plugin -- specifies format of signature, parameters required, + key type and size etc. There could be multiple signature plugins + defined to produce multiple signatures for a given signing request. + +A number of the plugins and components of the signing profile already exist +in the CA code - authz and auth plugins for instance, and certain types of +signature code which could be incorporated into a signature plugin. + +The initial focus would be on creating REST interfaces and client code to be used +in CLI clients. There are, however, some well established precedents in +converting profile components (in the CA and TPS) into UI input and output +components. + +Some considerations: + +* The data to be signed must be uploaded to the KRA. Certainly, any data that + is sent as part of the request will be constrained to a small size as HTTP + is not efficient for transfer of large files. More likely than not, this will + be used for the transfer of hashes. + + For large files (rpms, jars, documents), we would need to provide a separate + service to allow this data to be copied locally - perhaps as an NFS mount + through an FTP service. This is something that would be managed by IPA + for instance. + +* We need to consider how the signing key would be stored in the KRA and the + certificate or public key would be published for clients to verify. This is + a problem that is related but orthogonal to this proposal. + + One straightforward way would be to generate a signing key and certificate + through an enrollment profile on the CA, allowing the signing certificate + to be archived through the CA-> KRA connector. The certificate could then + be published to an LDAP server through a CA publisher. Currently, encryption keys that are stored through the connector are stored with the certificate, and it is possible to search the KRA for a private key given a public key (or a certificate). - There is probably some additional work here vis a vis the new authorization - work and tagging in the KRA, so that the escrowed keys are correctly tagged. - Another possibility we will need to allow is for the end-user to upload a certificate and signing key to the KRA as a package. This would be the case where the certificate was not issued by out CA. We will need to expand the key archival REST API to permit this (assuming that the relevant signatures checks pass). + There is probably some additional work here vis a vis the new authorization + work and tagging in the KRA, so that the escrowed keys are correctly tagged. + * We need to determine which signing algorithms/signing key characteristics/ signature types to support based on the use cases above. We probably should not support cases which are no longer secure - MD5 or RSA keys with small sizes, for instance. It would be nice to advertise the combinations we do support through the REST API. -* We need to determine how to return the data. My immediate thought was that - the KRA would return a CMS Signed Data Content-Type. Additional processing - of this output -- to say construct a signed jar or otherwise - would be done - using the REST client or pki CLI. Its not clear yet how to do this with a - signed RPM though. - - Alternatively, we could do all the relevant processing on the KRA, and - return specific format based on the use case. For instance, we would - return signed RPMS if the type is denoted as an RPM, a signed jar if the - type is defined as a jar etc. - - This architecture simplifies the deployment, but also increases the scope - of functionality that needs to be added to the KRA server itself. - Alternatives ------------ @@ -345,3 +382,7 @@ https://specs.openstack.org/openstack/glance-specs/specs/liberty/image-signing-a 7. Another glance blueprint for nova changes: https://review.openstack.org/#/c/188874/19/specs/mitaka/approved/image-verification.rst,cm (nova, scheduled for mitaka) + +8. Some discussions about signing requirements with IdM: +http://idm.etherpad.corp.redhat.com/idm-signing-and-dogtag +