Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops [ver #2]
On Tue, 9 Oct 2018, David Howells wrote: > > Hi James, > > Here's a set of patches that does the following, if you could pull it please: Applied to git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-keys and next-testing Please test. -- James Morris
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops [ver #2]
On Tue, 9 Oct 2018, David Howells wrote: > > Hi James, > > Here's a set of patches that does the following, if you could pull it please: Applied to git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-keys and next-testing Please test. -- James Morris
[PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops [ver #2]
Hi James, Here's a set of patches that does the following, if you could pull it please: (1) Adds keyctl() functions that permit an asymmetric-type key to be used to encrypt, decrypt, sign and verify a small piece of data (typically a session key or a hash) using the public and/or private key held in the kernel. A query function is also provided. (2) Adds an asymmetric-key parser for PKCS#8 to allow RSA private keys to be passed to the kernel. Currently only DER-encoded and unencrypted PKCS#8 is supported. (3) Adds an asymmetric-key parser for TPM-wrapped key blobs. The parser gets the TPM to unpack the blob and then attaches it to a key from which it can be used. Currently only TPM-1.2 is supported. Example usage for a PKCS#8 blob: openssl genrsa -out /tmp/privkey.foo.pem 2048 j=`openssl pkcs8 -in /tmp/privkey.foo.pem -topk8 -nocrypt -outform DER | keyctl padd asymmetric foo @s` Example usage for a TPM wrapped blob: openssl genrsa -out /tmp/privkey.foo.pem 2048 create_tpm_key -s 2048 -w /tmp/privkey.foo.pem /tmp/privkey.foo.tpm j=`openssl asn1parse -inform pem -in /tmp/privkey.foo.tpm -noout -out - | keyctl padd asymmetric foo @s` See http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#rfc.section.4.4 These keys can then be used thusly: echo -n abcdefghijklmnopqrst >/tmp/data keyctl pkey_encrypt $j /tmp/data enc=pkcs1 >/tmp/enc keyctl pkey_decrypt $j /tmp/enc enc=pkcs1 >/tmp/dec cmp /tmp/data /tmp/dec keyctl pkey_sign $j /tmp/data enc=pkcs1 hash=sha1 >/tmp/sig keyctl pkey_verify $j /tmp/data /tmp/sig enc=pkcs1 hash=sha1 The kernel patches can be found tagged here: https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/tag/?h=keys-asym-keyctl-20181009 and also on a branch here: http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-asym-keyctl The keyutils changes needed can be found here: http://git.kernel.org/cgit/linux/kernel/git/dhowells/keyutils.git/log/?h=next Changes --- v2: Updated the docs and a comment to indicate that the encoding should be a pointer to a string "raw" to denote no encoding and not NULL. David --- David Howells (8): KEYS: Provide key type operations for asymmetric key ops KEYS: Provide keyctls to drive the new key type ops for asymmetric keys KEYS: Provide missing asymmetric key subops for new key type ops KEYS: Make the X.509 and PKCS7 parsers supply the sig encoding type KEYS: Provide software public key query function KEYS: Allow the public_key struct to hold a private key KEYS: Implement encrypt, decrypt and sign for software asymmetric key KEYS: Implement PKCS#8 RSA Private Key parser Denis Kenzior (14): crypto: rsa-pkcs1pad: Allow hash to be optional KEYS: asym_tpm: add skeleton for asym_tpm KEYS: asym_tpm: extract key size & public key KEYS: Add parser for TPM-based keys KEYS: asym_tpm: Implement pkey_query KEYS: asym_tpm: Implement encryption operation KEYS: trusted: Expose common functionality KEYS: Move trusted.h to include/keys KEYS: asym_tpm: Add loadkey2 and flushspecific KEYS: asym_tpm: Implement tpm_unbind KEYS: asym_tpm: Implement the decrypt operation KEYS: asym_tpm: Implement signature verification KEYS: asym_tpm: Implement tpm_sign KEYS: asym_tpm: Add support for the sign operation Documentation/crypto/asymmetric-keys.txt | 26 + Documentation/security/keys/core.rst | 217 ++ crypto/asymmetric_keys/Kconfig| 31 + crypto/asymmetric_keys/Makefile | 25 + crypto/asymmetric_keys/asym_tpm.c | 988 + crypto/asymmetric_keys/asymmetric_keys.h |3 crypto/asymmetric_keys/asymmetric_type.c | 43 + crypto/asymmetric_keys/pkcs7_parser.c |1 crypto/asymmetric_keys/pkcs8.asn1 | 24 + crypto/asymmetric_keys/pkcs8_parser.c | 184 + crypto/asymmetric_keys/public_key.c | 191 +- crypto/asymmetric_keys/signature.c| 95 +++ crypto/asymmetric_keys/tpm.asn1 |5 crypto/asymmetric_keys/tpm_parser.c | 102 +++ crypto/asymmetric_keys/x509_cert_parser.c | 21 - crypto/rsa-pkcs1pad.c | 59 +- include/crypto/asym_tpm_subtype.h | 19 + include/crypto/public_key.h | 14 include/keys/asymmetric-subtype.h |9 include/keys/trusted.h| 136 include/linux/key-type.h | 11 include/linux/keyctl.h| 46 + include/uapi/linux/keyctl.h | 30 + security/keys/Makefile|1 security/keys/compat.c| 18 + security/keys/internal.h | 39 +
[PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops [ver #2]
Hi James, Here's a set of patches that does the following, if you could pull it please: (1) Adds keyctl() functions that permit an asymmetric-type key to be used to encrypt, decrypt, sign and verify a small piece of data (typically a session key or a hash) using the public and/or private key held in the kernel. A query function is also provided. (2) Adds an asymmetric-key parser for PKCS#8 to allow RSA private keys to be passed to the kernel. Currently only DER-encoded and unencrypted PKCS#8 is supported. (3) Adds an asymmetric-key parser for TPM-wrapped key blobs. The parser gets the TPM to unpack the blob and then attaches it to a key from which it can be used. Currently only TPM-1.2 is supported. Example usage for a PKCS#8 blob: openssl genrsa -out /tmp/privkey.foo.pem 2048 j=`openssl pkcs8 -in /tmp/privkey.foo.pem -topk8 -nocrypt -outform DER | keyctl padd asymmetric foo @s` Example usage for a TPM wrapped blob: openssl genrsa -out /tmp/privkey.foo.pem 2048 create_tpm_key -s 2048 -w /tmp/privkey.foo.pem /tmp/privkey.foo.tpm j=`openssl asn1parse -inform pem -in /tmp/privkey.foo.tpm -noout -out - | keyctl padd asymmetric foo @s` See http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#rfc.section.4.4 These keys can then be used thusly: echo -n abcdefghijklmnopqrst >/tmp/data keyctl pkey_encrypt $j /tmp/data enc=pkcs1 >/tmp/enc keyctl pkey_decrypt $j /tmp/enc enc=pkcs1 >/tmp/dec cmp /tmp/data /tmp/dec keyctl pkey_sign $j /tmp/data enc=pkcs1 hash=sha1 >/tmp/sig keyctl pkey_verify $j /tmp/data /tmp/sig enc=pkcs1 hash=sha1 The kernel patches can be found tagged here: https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/tag/?h=keys-asym-keyctl-20181009 and also on a branch here: http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-asym-keyctl The keyutils changes needed can be found here: http://git.kernel.org/cgit/linux/kernel/git/dhowells/keyutils.git/log/?h=next Changes --- v2: Updated the docs and a comment to indicate that the encoding should be a pointer to a string "raw" to denote no encoding and not NULL. David --- David Howells (8): KEYS: Provide key type operations for asymmetric key ops KEYS: Provide keyctls to drive the new key type ops for asymmetric keys KEYS: Provide missing asymmetric key subops for new key type ops KEYS: Make the X.509 and PKCS7 parsers supply the sig encoding type KEYS: Provide software public key query function KEYS: Allow the public_key struct to hold a private key KEYS: Implement encrypt, decrypt and sign for software asymmetric key KEYS: Implement PKCS#8 RSA Private Key parser Denis Kenzior (14): crypto: rsa-pkcs1pad: Allow hash to be optional KEYS: asym_tpm: add skeleton for asym_tpm KEYS: asym_tpm: extract key size & public key KEYS: Add parser for TPM-based keys KEYS: asym_tpm: Implement pkey_query KEYS: asym_tpm: Implement encryption operation KEYS: trusted: Expose common functionality KEYS: Move trusted.h to include/keys KEYS: asym_tpm: Add loadkey2 and flushspecific KEYS: asym_tpm: Implement tpm_unbind KEYS: asym_tpm: Implement the decrypt operation KEYS: asym_tpm: Implement signature verification KEYS: asym_tpm: Implement tpm_sign KEYS: asym_tpm: Add support for the sign operation Documentation/crypto/asymmetric-keys.txt | 26 + Documentation/security/keys/core.rst | 217 ++ crypto/asymmetric_keys/Kconfig| 31 + crypto/asymmetric_keys/Makefile | 25 + crypto/asymmetric_keys/asym_tpm.c | 988 + crypto/asymmetric_keys/asymmetric_keys.h |3 crypto/asymmetric_keys/asymmetric_type.c | 43 + crypto/asymmetric_keys/pkcs7_parser.c |1 crypto/asymmetric_keys/pkcs8.asn1 | 24 + crypto/asymmetric_keys/pkcs8_parser.c | 184 + crypto/asymmetric_keys/public_key.c | 191 +- crypto/asymmetric_keys/signature.c| 95 +++ crypto/asymmetric_keys/tpm.asn1 |5 crypto/asymmetric_keys/tpm_parser.c | 102 +++ crypto/asymmetric_keys/x509_cert_parser.c | 21 - crypto/rsa-pkcs1pad.c | 59 +- include/crypto/asym_tpm_subtype.h | 19 + include/crypto/public_key.h | 14 include/keys/asymmetric-subtype.h |9 include/keys/trusted.h| 136 include/linux/key-type.h | 11 include/linux/keyctl.h| 46 + include/uapi/linux/keyctl.h | 30 + security/keys/Makefile|1 security/keys/compat.c| 18 + security/keys/internal.h | 39 +
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Hi David, > Yes. It shouldn't be much code, either. You still have to check for > X.509 > DER since the kernel currently supports that. For reasons of backward compatibility, correct? The kernel also has mscode.asn1 which we would need to support as well. Since we can't break compatibility then perhaps this doesn't buy us a whole lot in the end. >>> >>> Don't worry about mscode - that's not an asymmetric key parser. That's only >>> ever used directly from verify_pefile_signature(). >>> >>> Currently, we have to retain support for DER-encoded X.509. >>> >>> But there's no reason we can't have a PEM parser that decodes the PEM and >>> selects X.509, PKCS#8 or TPM based on the ascii header in that. PKCS#8 and >>> TPM don't need to take DER directly. >> >> since we have to support DER-encoded anyway, can we get the current >> patches merged (with fixes to the commit messages for the openssl >> examples if needed) and then work on PEM support inside the kernel. >> For me these seems to be two independent features. And in the current >> form the patches have been tested and used. >> >> Or let me ask this differently, are there any objections to merging >> these patches with just DER support? > > Let me rephrase that question slightly: Are we happy to have to make > inferences from the ASN.1 structure, and in particular that a bare > OCTET-STRING is a TPMv1 blob? I believe James ended up doing something > somewhat more sensible for the TPMv2 blob so that might end up being > OK...? similar to Denis’ comment, I don’t see an issue here with using DER encoding. James, can you take this series into your -next tree? Regards Marcel
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Hi David, > Yes. It shouldn't be much code, either. You still have to check for > X.509 > DER since the kernel currently supports that. For reasons of backward compatibility, correct? The kernel also has mscode.asn1 which we would need to support as well. Since we can't break compatibility then perhaps this doesn't buy us a whole lot in the end. >>> >>> Don't worry about mscode - that's not an asymmetric key parser. That's only >>> ever used directly from verify_pefile_signature(). >>> >>> Currently, we have to retain support for DER-encoded X.509. >>> >>> But there's no reason we can't have a PEM parser that decodes the PEM and >>> selects X.509, PKCS#8 or TPM based on the ascii header in that. PKCS#8 and >>> TPM don't need to take DER directly. >> >> since we have to support DER-encoded anyway, can we get the current >> patches merged (with fixes to the commit messages for the openssl >> examples if needed) and then work on PEM support inside the kernel. >> For me these seems to be two independent features. And in the current >> form the patches have been tested and used. >> >> Or let me ask this differently, are there any objections to merging >> these patches with just DER support? > > Let me rephrase that question slightly: Are we happy to have to make > inferences from the ASN.1 structure, and in particular that a bare > OCTET-STRING is a TPMv1 blob? I believe James ended up doing something > somewhat more sensible for the TPMv2 blob so that might end up being > OK...? similar to Denis’ comment, I don’t see an issue here with using DER encoding. James, can you take this series into your -next tree? Regards Marcel
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
David, On 09/20/2018 11:45 AM, David Woodhouse wrote: On Thu, 2018-09-20 at 09:26 +0200, Marcel Holtmann wrote: Hi David, Yes. It shouldn't be much code, either. You still have to check for X.509 DER since the kernel currently supports that. For reasons of backward compatibility, correct? The kernel also has mscode.asn1 which we would need to support as well. Since we can't break compatibility then perhaps this doesn't buy us a whole lot in the end. Don't worry about mscode - that's not an asymmetric key parser. That's only ever used directly from verify_pefile_signature(). Currently, we have to retain support for DER-encoded X.509. But there's no reason we can't have a PEM parser that decodes the PEM and selects X.509, PKCS#8 or TPM based on the ascii header in that. PKCS#8 and TPM don't need to take DER directly. since we have to support DER-encoded anyway, can we get the current patches merged (with fixes to the commit messages for the openssl examples if needed) and then work on PEM support inside the kernel. For me these seems to be two independent features. And in the current form the patches have been tested and used. Or let me ask this differently, are there any objections to merging these patches with just DER support? Let me rephrase that question slightly: Are we happy to have to make inferences from the ASN.1 structure, and in particular that a bare OCTET-STRING is a TPMv1 blob? I believe James ended up doing something somewhat more sensible for the TPMv2 blob so that might end up being OK...? I think it should be OK. It is highly unlikely that we get another OCTET string type format, and even then we can actually peek inside and try to parse the TPM structure carried in the DER if there is indeed a conflict. Also, after refreshing my memory of how PEM format is actually specified, I'm no longer convinced that having it in the kernel is such a good idea. It would probably be made to work, but the PEM file format itself isn't that precise, at least compared to DER. James, is there a document / official place with your TPMKey ASN.1 format? The only reference I can find is here: https://kernel.googlesource.com/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine/+/93b2f4f3f0f2260292f54de4e6333219063c77b1/tpm2-asn.h Regards, -Denis
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
David, On 09/20/2018 11:45 AM, David Woodhouse wrote: On Thu, 2018-09-20 at 09:26 +0200, Marcel Holtmann wrote: Hi David, Yes. It shouldn't be much code, either. You still have to check for X.509 DER since the kernel currently supports that. For reasons of backward compatibility, correct? The kernel also has mscode.asn1 which we would need to support as well. Since we can't break compatibility then perhaps this doesn't buy us a whole lot in the end. Don't worry about mscode - that's not an asymmetric key parser. That's only ever used directly from verify_pefile_signature(). Currently, we have to retain support for DER-encoded X.509. But there's no reason we can't have a PEM parser that decodes the PEM and selects X.509, PKCS#8 or TPM based on the ascii header in that. PKCS#8 and TPM don't need to take DER directly. since we have to support DER-encoded anyway, can we get the current patches merged (with fixes to the commit messages for the openssl examples if needed) and then work on PEM support inside the kernel. For me these seems to be two independent features. And in the current form the patches have been tested and used. Or let me ask this differently, are there any objections to merging these patches with just DER support? Let me rephrase that question slightly: Are we happy to have to make inferences from the ASN.1 structure, and in particular that a bare OCTET-STRING is a TPMv1 blob? I believe James ended up doing something somewhat more sensible for the TPMv2 blob so that might end up being OK...? I think it should be OK. It is highly unlikely that we get another OCTET string type format, and even then we can actually peek inside and try to parse the TPM structure carried in the DER if there is indeed a conflict. Also, after refreshing my memory of how PEM format is actually specified, I'm no longer convinced that having it in the kernel is such a good idea. It would probably be made to work, but the PEM file format itself isn't that precise, at least compared to DER. James, is there a document / official place with your TPMKey ASN.1 format? The only reference I can find is here: https://kernel.googlesource.com/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine/+/93b2f4f3f0f2260292f54de4e6333219063c77b1/tpm2-asn.h Regards, -Denis
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
On Thu, 2018-09-20 at 09:26 +0200, Marcel Holtmann wrote: > Hi David, > > > > > Yes. It shouldn't be much code, either. You still have to check for > > > > X.509 > > > > DER since the kernel currently supports that. > > > > > > For reasons of backward compatibility, correct? The kernel also has > > > mscode.asn1 which we would need to support as well. Since we can't break > > > compatibility then perhaps this doesn't buy us a whole lot in the end. > > > > Don't worry about mscode - that's not an asymmetric key parser. That's only > > ever used directly from verify_pefile_signature(). > > > > Currently, we have to retain support for DER-encoded X.509. > > > > But there's no reason we can't have a PEM parser that decodes the PEM and > > selects X.509, PKCS#8 or TPM based on the ascii header in that. PKCS#8 and > > TPM don't need to take DER directly. > > since we have to support DER-encoded anyway, can we get the current > patches merged (with fixes to the commit messages for the openssl > examples if needed) and then work on PEM support inside the kernel. > For me these seems to be two independent features. And in the current > form the patches have been tested and used. > > Or let me ask this differently, are there any objections to merging > these patches with just DER support? Let me rephrase that question slightly: Are we happy to have to make inferences from the ASN.1 structure, and in particular that a bare OCTET-STRING is a TPMv1 blob? I believe James ended up doing something somewhat more sensible for the TPMv2 blob so that might end up being OK...? smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
On Thu, 2018-09-20 at 09:26 +0200, Marcel Holtmann wrote: > Hi David, > > > > > Yes. It shouldn't be much code, either. You still have to check for > > > > X.509 > > > > DER since the kernel currently supports that. > > > > > > For reasons of backward compatibility, correct? The kernel also has > > > mscode.asn1 which we would need to support as well. Since we can't break > > > compatibility then perhaps this doesn't buy us a whole lot in the end. > > > > Don't worry about mscode - that's not an asymmetric key parser. That's only > > ever used directly from verify_pefile_signature(). > > > > Currently, we have to retain support for DER-encoded X.509. > > > > But there's no reason we can't have a PEM parser that decodes the PEM and > > selects X.509, PKCS#8 or TPM based on the ascii header in that. PKCS#8 and > > TPM don't need to take DER directly. > > since we have to support DER-encoded anyway, can we get the current > patches merged (with fixes to the commit messages for the openssl > examples if needed) and then work on PEM support inside the kernel. > For me these seems to be two independent features. And in the current > form the patches have been tested and used. > > Or let me ask this differently, are there any objections to merging > these patches with just DER support? Let me rephrase that question slightly: Are we happy to have to make inferences from the ASN.1 structure, and in particular that a bare OCTET-STRING is a TPMv1 blob? I believe James ended up doing something somewhat more sensible for the TPMv2 blob so that might end up being OK...? smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Hi David, >>> Yes. It shouldn't be much code, either. You still have to check for X.509 >>> DER since the kernel currently supports that. >> >> For reasons of backward compatibility, correct? The kernel also has >> mscode.asn1 which we would need to support as well. Since we can't break >> compatibility then perhaps this doesn't buy us a whole lot in the end. > > Don't worry about mscode - that's not an asymmetric key parser. That's only > ever used directly from verify_pefile_signature(). > > Currently, we have to retain support for DER-encoded X.509. > > But there's no reason we can't have a PEM parser that decodes the PEM and > selects X.509, PKCS#8 or TPM based on the ascii header in that. PKCS#8 and > TPM don't need to take DER directly. since we have to support DER-encoded anyway, can we get the current patches merged (with fixes to the commit messages for the openssl examples if needed) and then work on PEM support inside the kernel. For me these seems to be two independent features. And in the current form the patches have been tested and used. Or let me ask this differently, are there any objections to merging these patches with just DER support? For example in ELL we have implemented the PEM to DER conversion before calling keyctl. This can be surely added to keyutils (if calling openssl is too much to ask) or even the kernel itself. However this doesn’t change the actual functionality of handling asymmetric key operations. And I would rather see that merged and established instead of worrying to much about the multitudes of possible encoding forms of keys. Regards Marcel
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Hi David, >>> Yes. It shouldn't be much code, either. You still have to check for X.509 >>> DER since the kernel currently supports that. >> >> For reasons of backward compatibility, correct? The kernel also has >> mscode.asn1 which we would need to support as well. Since we can't break >> compatibility then perhaps this doesn't buy us a whole lot in the end. > > Don't worry about mscode - that's not an asymmetric key parser. That's only > ever used directly from verify_pefile_signature(). > > Currently, we have to retain support for DER-encoded X.509. > > But there's no reason we can't have a PEM parser that decodes the PEM and > selects X.509, PKCS#8 or TPM based on the ascii header in that. PKCS#8 and > TPM don't need to take DER directly. since we have to support DER-encoded anyway, can we get the current patches merged (with fixes to the commit messages for the openssl examples if needed) and then work on PEM support inside the kernel. For me these seems to be two independent features. And in the current form the patches have been tested and used. Or let me ask this differently, are there any objections to merging these patches with just DER support? For example in ELL we have implemented the PEM to DER conversion before calling keyctl. This can be surely added to keyutils (if calling openssl is too much to ask) or even the kernel itself. However this doesn’t change the actual functionality of handling asymmetric key operations. And I would rather see that merged and established instead of worrying to much about the multitudes of possible encoding forms of keys. Regards Marcel
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Denis Kenzior wrote: > > Yes. It shouldn't be much code, either. You still have to check for X.509 > > DER since the kernel currently supports that. > > For reasons of backward compatibility, correct? The kernel also has > mscode.asn1 which we would need to support as well. Since we can't break > compatibility then perhaps this doesn't buy us a whole lot in the end. Don't worry about mscode - that's not an asymmetric key parser. That's only ever used directly from verify_pefile_signature(). Currently, we have to retain support for DER-encoded X.509. But there's no reason we can't have a PEM parser that decodes the PEM and selects X.509, PKCS#8 or TPM based on the ascii header in that. PKCS#8 and TPM don't need to take DER directly. David
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Denis Kenzior wrote: > > Yes. It shouldn't be much code, either. You still have to check for X.509 > > DER since the kernel currently supports that. > > For reasons of backward compatibility, correct? The kernel also has > mscode.asn1 which we would need to support as well. Since we can't break > compatibility then perhaps this doesn't buy us a whole lot in the end. Don't worry about mscode - that's not an asymmetric key parser. That's only ever used directly from verify_pefile_signature(). Currently, we have to retain support for DER-encoded X.509. But there's no reason we can't have a PEM parser that decodes the PEM and selects X.509, PKCS#8 or TPM based on the ascii header in that. PKCS#8 and TPM don't need to take DER directly. David
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Hi David, On 09/18/2018 11:55 AM, David Howells wrote: Denis Kenzior wrote: In theory the PEM file already contains the type of the certificate, at least at a high level. E.g. private, public, tpm. So if we accept PEM files directly that could be potentially a faster way of determining the parser to use and would still work with keyctl update/instantiate, right? Yes. It shouldn't be much code, either. You still have to check for X.509 DER since the kernel currently supports that. For reasons of backward compatibility, correct? The kernel also has mscode.asn1 which we would need to support as well. Since we can't break compatibility then perhaps this doesn't buy us a whole lot in the end. Regards, -Denis
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Hi David, On 09/18/2018 11:55 AM, David Howells wrote: Denis Kenzior wrote: In theory the PEM file already contains the type of the certificate, at least at a high level. E.g. private, public, tpm. So if we accept PEM files directly that could be potentially a faster way of determining the parser to use and would still work with keyctl update/instantiate, right? Yes. It shouldn't be much code, either. You still have to check for X.509 DER since the kernel currently supports that. For reasons of backward compatibility, correct? The kernel also has mscode.asn1 which we would need to support as well. Since we can't break compatibility then perhaps this doesn't buy us a whole lot in the end. Regards, -Denis
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Denis Kenzior wrote: > In theory the PEM file already contains the type of the certificate, at least > at a high level. E.g. private, public, tpm. So if we accept PEM files > directly that could be potentially a faster way of determining the parser to > use and would still work with keyctl update/instantiate, right? Yes. It shouldn't be much code, either. You still have to check for X.509 DER since the kernel currently supports that. David
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Denis Kenzior wrote: > In theory the PEM file already contains the type of the certificate, at least > at a high level. E.g. private, public, tpm. So if we accept PEM files > directly that could be potentially a faster way of determining the parser to > use and would still work with keyctl update/instantiate, right? Yes. It shouldn't be much code, either. You still have to check for X.509 DER since the kernel currently supports that. David
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Hi David, It passes it to each parser in turn till one says it can parse it. It's not ideal, but it seems to work - so far. Better would be to annotate it in some way. I have considered annotating the type field so that the payload doesn't have to have it added: keyctl padd asymmetric.x509 "" @s In theory the PEM file already contains the type of the certificate, at least at a high level. E.g. private, public, tpm. So if we accept PEM files directly that could be potentially a faster way of determining the parser to use and would still work with keyctl update/instantiate, right? Regards, -Denis
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Hi David, It passes it to each parser in turn till one says it can parse it. It's not ideal, but it seems to work - so far. Better would be to annotate it in some way. I have considered annotating the type field so that the payload doesn't have to have it added: keyctl padd asymmetric.x509 "" @s In theory the PEM file already contains the type of the certificate, at least at a high level. E.g. private, public, tpm. So if we accept PEM files directly that could be potentially a faster way of determining the parser to use and would still work with keyctl update/instantiate, right? Regards, -Denis
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
David Woodhouse wrote: > You are passing the raw DER to the kernel in both cases, right? I haven't put a PEM stripper and base64 decoder into the kernel, though we certainly could do that. We could even do the decode in-place in the same buffer since the resulting data would be smaller than the original. > And the kernel just happens to know that if it receives a bare OCTET-STRING > it's supposed to treat it as a TPMv1.2 key? It passes it to each parser in turn till one says it can parse it. It's not ideal, but it seems to work - so far. Better would be to annotate it in some way. I have considered annotating the type field so that the payload doesn't have to have it added: keyctl padd asymmetric.x509 "" @s
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
David Woodhouse wrote: > You are passing the raw DER to the kernel in both cases, right? I haven't put a PEM stripper and base64 decoder into the kernel, though we certainly could do that. We could even do the decode in-place in the same buffer since the resulting data would be smaller than the original. > And the kernel just happens to know that if it receives a bare OCTET-STRING > it's supposed to treat it as a TPMv1.2 key? It passes it to each parser in turn till one says it can parse it. It's not ideal, but it seems to work - so far. Better would be to annotate it in some way. I have considered annotating the type field so that the payload doesn't have to have it added: keyctl padd asymmetric.x509 "" @s
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Hi David, On 09/18/2018 11:17 AM, David Woodhouse wrote: On Tue, 2018-09-18 at 00:24 -0500, Denis Kenzior wrote: Hi David, On 09/18/2018 10:50 AM, David Howells wrote: Denis Kenzior wrote: openssl asn1parse -inform pem -in /tmp/privkey.2048.tpm -noout \ -out /tmp/privkey.2048.der You can use "... -out - | ..." instead. Aha! okay, that is even more elegant. Your openssl-fu is better than mine :) 'grep -v ^- | base64 -d' also works most of the time :) You are passing the raw DER to the kernel in both cases, right? And the kernel just happens to know that if it receives a bare OCTET-STRING it's supposed to treat it as a TPMv1.2 key? Short answer: right. Long answer: The kernel runs all the registered parsers until all fail or one of them recognizes the format. All the currently supported asymmetric key formats are DER based, e.g. PKCS8, PKCS7, TPM-1.2, etc. All these have a very specific DER structure with the TPM-1.2 being the simplest format. Regards, -Denis
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Hi David, On 09/18/2018 11:17 AM, David Woodhouse wrote: On Tue, 2018-09-18 at 00:24 -0500, Denis Kenzior wrote: Hi David, On 09/18/2018 10:50 AM, David Howells wrote: Denis Kenzior wrote: openssl asn1parse -inform pem -in /tmp/privkey.2048.tpm -noout \ -out /tmp/privkey.2048.der You can use "... -out - | ..." instead. Aha! okay, that is even more elegant. Your openssl-fu is better than mine :) 'grep -v ^- | base64 -d' also works most of the time :) You are passing the raw DER to the kernel in both cases, right? And the kernel just happens to know that if it receives a bare OCTET-STRING it's supposed to treat it as a TPMv1.2 key? Short answer: right. Long answer: The kernel runs all the registered parsers until all fail or one of them recognizes the format. All the currently supported asymmetric key formats are DER based, e.g. PKCS8, PKCS7, TPM-1.2, etc. All these have a very specific DER structure with the TPM-1.2 being the simplest format. Regards, -Denis
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
On Tue, 2018-09-18 at 00:24 -0500, Denis Kenzior wrote: > Hi David, > > On 09/18/2018 10:50 AM, David Howells wrote: > > Denis Kenzior wrote: > > > > > openssl asn1parse -inform pem -in /tmp/privkey.2048.tpm -noout \ > > > -out /tmp/privkey.2048.der > > > > You can use "... -out - | ..." instead. > > Aha! okay, that is even more elegant. Your openssl-fu is better than > mine :) 'grep -v ^- | base64 -d' also works most of the time :) You are passing the raw DER to the kernel in both cases, right? And the kernel just happens to know that if it receives a bare OCTET-STRING it's supposed to treat it as a TPMv1.2 key? smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
On Tue, 2018-09-18 at 00:24 -0500, Denis Kenzior wrote: > Hi David, > > On 09/18/2018 10:50 AM, David Howells wrote: > > Denis Kenzior wrote: > > > > > openssl asn1parse -inform pem -in /tmp/privkey.2048.tpm -noout \ > > > -out /tmp/privkey.2048.der > > > > You can use "... -out - | ..." instead. > > Aha! okay, that is even more elegant. Your openssl-fu is better than > mine :) 'grep -v ^- | base64 -d' also works most of the time :) You are passing the raw DER to the kernel in both cases, right? And the kernel just happens to know that if it receives a bare OCTET-STRING it's supposed to treat it as a TPMv1.2 key? smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Hi David, On 09/18/2018 10:50 AM, David Howells wrote: Denis Kenzior wrote: openssl asn1parse -inform pem -in /tmp/privkey.2048.tpm -noout \ -out /tmp/privkey.2048.der You can use "... -out - | ..." instead. Aha! okay, that is even more elegant. Your openssl-fu is better than mine :) Regards, -Denis
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Hi David, On 09/18/2018 10:50 AM, David Howells wrote: Denis Kenzior wrote: openssl asn1parse -inform pem -in /tmp/privkey.2048.tpm -noout \ -out /tmp/privkey.2048.der You can use "... -out - | ..." instead. Aha! okay, that is even more elegant. Your openssl-fu is better than mine :) Regards, -Denis
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Denis Kenzior wrote: > openssl asn1parse -inform pem -in /tmp/privkey.2048.tpm -noout \ > -out /tmp/privkey.2048.der You can use "... -out - | ..." instead. David
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Denis Kenzior wrote: > openssl asn1parse -inform pem -in /tmp/privkey.2048.tpm -noout \ > -out /tmp/privkey.2048.der You can use "... -out - | ..." instead. David
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
On Tue, 2018-09-18 at 16:02 +0100, David Howells wrote: > It's meant to be stripping off the PEM wrapper and outputting the DER, but see > below. > > > If I run it on a '-BEGIN TSS KEY BLOB-' file I have lying around, I > > get no output at all. > > I lost a bit from the cover note. It needs "-out -" attaching. > > openssl asn1parse -inform pem -in modulekey1.priv -noout -out - | wc > -c Ah, OK. So it's just a complex base64 decoder :) smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
On Tue, 2018-09-18 at 16:02 +0100, David Howells wrote: > It's meant to be stripping off the PEM wrapper and outputting the DER, but see > below. > > > If I run it on a '-BEGIN TSS KEY BLOB-' file I have lying around, I > > get no output at all. > > I lost a bit from the cover note. It needs "-out -" attaching. > > openssl asn1parse -inform pem -in modulekey1.priv -noout -out - | wc > -c Ah, OK. So it's just a complex base64 decoder :) smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Hi David, On 09/18/2018 01:59 AM, David Woodhouse wrote: On Wed, 2018-09-05 at 22:54 +0100, David Howells wrote: Example usage for a PKCS#8 blob: j=`openssl pkcs8 -in private_key.pem -topk8 -nocrypt -outform DER | \ keyctl padd asymmetric foo @s` The kernel expects a raw DER formatted PKCS8 certificate. And as you point out, keyctl doesn't grok PEM files. So, that is why this is being done via openssl. The example above simply shows one how to import a private key in PEM format into the kernel keys framework. Example usage for a TPM wrapped blob: openssl genrsa -out /tmp/privkey.foo.pem 2048 create_tpm_key -s 2048 -w /tmp/privkey.foo.pem /tmp/privkey.foo.tpm j=`openssl asn1parse -inform pem -in /tmp/privkey.foo.tpm -noout | keyctl padd asymmetric foo @s` Those examples aren't equivalent. For the PKCS#8 blob you are first using openssl to convert from an encrypted PKCS#8 PEM to unencrypted DER, presumably because you haven't added decryption support (or base64 decode) to keyctl yet. To be pedantic, it converts an optionally encrypted PEM to unencrypted DER. But yes, correct. For the TPM example though, you are also showing the *generation* of the key, and importing it into the TPM. And then I'm confused by the 'openssl asn1parse' line there... what is that actually doing? If I run it on a '-BEGIN TSS KEY BLOB-' file I have lying around, I get no output at all. Same thing applies as above. The kernel has no PEM parser, so the raw DER must be passed in. openssl asn1parse line simply does that. It strips the PEM layer leaving the raw DER. However, now that you mention it, the actual command incantation is wrong. It seems openssl asn1parse acts slightly different from openssl pkcs8 and so it needs to be modified to add an extra -out parameter. So the example incantation should be: openssl genrsa -out /tmp/privkey.2048.pem 2048 create_tpm_key -s 2048 -w /tmp/privkey.2048.pem /tmp/privkey.2048.tpm openssl asn1parse -inform pem -in /tmp/privkey.2048.tpm -noout \ -out /tmp/privkey.2048.der j=`cat /tmp/privkey.2048.der | keyctl padd asymmetric tpm @u` echo "TPM key serial is: $j" Sorry, I should have caught this earlier. Regards, -Denis
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Hi David, On 09/18/2018 01:59 AM, David Woodhouse wrote: On Wed, 2018-09-05 at 22:54 +0100, David Howells wrote: Example usage for a PKCS#8 blob: j=`openssl pkcs8 -in private_key.pem -topk8 -nocrypt -outform DER | \ keyctl padd asymmetric foo @s` The kernel expects a raw DER formatted PKCS8 certificate. And as you point out, keyctl doesn't grok PEM files. So, that is why this is being done via openssl. The example above simply shows one how to import a private key in PEM format into the kernel keys framework. Example usage for a TPM wrapped blob: openssl genrsa -out /tmp/privkey.foo.pem 2048 create_tpm_key -s 2048 -w /tmp/privkey.foo.pem /tmp/privkey.foo.tpm j=`openssl asn1parse -inform pem -in /tmp/privkey.foo.tpm -noout | keyctl padd asymmetric foo @s` Those examples aren't equivalent. For the PKCS#8 blob you are first using openssl to convert from an encrypted PKCS#8 PEM to unencrypted DER, presumably because you haven't added decryption support (or base64 decode) to keyctl yet. To be pedantic, it converts an optionally encrypted PEM to unencrypted DER. But yes, correct. For the TPM example though, you are also showing the *generation* of the key, and importing it into the TPM. And then I'm confused by the 'openssl asn1parse' line there... what is that actually doing? If I run it on a '-BEGIN TSS KEY BLOB-' file I have lying around, I get no output at all. Same thing applies as above. The kernel has no PEM parser, so the raw DER must be passed in. openssl asn1parse line simply does that. It strips the PEM layer leaving the raw DER. However, now that you mention it, the actual command incantation is wrong. It seems openssl asn1parse acts slightly different from openssl pkcs8 and so it needs to be modified to add an extra -out parameter. So the example incantation should be: openssl genrsa -out /tmp/privkey.2048.pem 2048 create_tpm_key -s 2048 -w /tmp/privkey.2048.pem /tmp/privkey.2048.tpm openssl asn1parse -inform pem -in /tmp/privkey.2048.tpm -noout \ -out /tmp/privkey.2048.der j=`cat /tmp/privkey.2048.der | keyctl padd asymmetric tpm @u` echo "TPM key serial is: $j" Sorry, I should have caught this earlier. Regards, -Denis
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
David Woodhouse wrote: > Those examples aren't equivalent No one said that they are. But if you really can't figure it out, I can add: openssl genrsa -out private_key.pem 2048 at the front of the PKCS#8 example;-) I can even change the examples to have the same private key name. > For the PKCS#8 blob you are first using openssl to convert from an encrypted > PKCS#8 PEM to unencrypted DER, presumably because you haven't added > decryption support (or base64 decode) to keyctl yet. It would probably be done in the kernel rather than keyctl. If it's done in userspace, there's no need to do it in keyctl. The PKCS#8 parser is primarily a test port - especially as it doesn't need anything like a TPM. It's of limited real utility, I think, because even if the blob is encrypted and you can pass the decryption password to the kernel, the password still has to be present in userspace, however briefly. > For the TPM example though, you are also showing the *generation* of > the key, and importing it into the TPM. And then I'm confused by the > 'openssl asn1parse' line there... what is that actually doing? It's meant to be stripping off the PEM wrapper and outputting the DER, but see below. > If I run it on a '-BEGIN TSS KEY BLOB-' file I have lying around, I > get no output at all. I lost a bit from the cover note. It needs "-out -" attaching. openssl asn1parse -inform pem -in modulekey1.priv -noout -out - | wc -c David
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
David Woodhouse wrote: > Those examples aren't equivalent No one said that they are. But if you really can't figure it out, I can add: openssl genrsa -out private_key.pem 2048 at the front of the PKCS#8 example;-) I can even change the examples to have the same private key name. > For the PKCS#8 blob you are first using openssl to convert from an encrypted > PKCS#8 PEM to unencrypted DER, presumably because you haven't added > decryption support (or base64 decode) to keyctl yet. It would probably be done in the kernel rather than keyctl. If it's done in userspace, there's no need to do it in keyctl. The PKCS#8 parser is primarily a test port - especially as it doesn't need anything like a TPM. It's of limited real utility, I think, because even if the blob is encrypted and you can pass the decryption password to the kernel, the password still has to be present in userspace, however briefly. > For the TPM example though, you are also showing the *generation* of > the key, and importing it into the TPM. And then I'm confused by the > 'openssl asn1parse' line there... what is that actually doing? It's meant to be stripping off the PEM wrapper and outputting the DER, but see below. > If I run it on a '-BEGIN TSS KEY BLOB-' file I have lying around, I > get no output at all. I lost a bit from the cover note. It needs "-out -" attaching. openssl asn1parse -inform pem -in modulekey1.priv -noout -out - | wc -c David
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
On Tue, 2018-09-18 at 08:00 +0100, David Woodhouse wrote: > > On Sat, 2018-09-08 at 16:26 +0100, David Howells wrote: > > Marcel Holtmann wrote: > > > > > > > > so I have reviewed and tested this code. In addition, we have > > > test cases for it in ELL (embedded linux library). > > > > I wonder if there's any practical way to add a test for this to the > > keyutils test suite. I'm guessing it's quite tricky, given the > > extra bits you need to emulate the TPM. > > Right, for a lot of userspace stuff we have the TPM emulator but for > the kernel you might need to run in qemu, which I believe can emulate > a TPM now (or at least, can talk to the TPM emulator, which has the > same effect). Actually, you don't necessarily. I use this patch: https://marc.info/?l=tpmdd-devel=148392353230117 Which allows me to make a TCP connection to the software TPM running in userspace without having to have the TPM components in qemu (or even to run virtual). I used it to debug all the in-kernel resource manager patches. It's TPM 2.0, but could easily be modified to work with 1.2 James
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
On Tue, 2018-09-18 at 08:00 +0100, David Woodhouse wrote: > > On Sat, 2018-09-08 at 16:26 +0100, David Howells wrote: > > Marcel Holtmann wrote: > > > > > > > > so I have reviewed and tested this code. In addition, we have > > > test cases for it in ELL (embedded linux library). > > > > I wonder if there's any practical way to add a test for this to the > > keyutils test suite. I'm guessing it's quite tricky, given the > > extra bits you need to emulate the TPM. > > Right, for a lot of userspace stuff we have the TPM emulator but for > the kernel you might need to run in qemu, which I believe can emulate > a TPM now (or at least, can talk to the TPM emulator, which has the > same effect). Actually, you don't necessarily. I use this patch: https://marc.info/?l=tpmdd-devel=148392353230117 Which allows me to make a TCP connection to the software TPM running in userspace without having to have the TPM components in qemu (or even to run virtual). I used it to debug all the in-kernel resource manager patches. It's TPM 2.0, but could easily be modified to work with 1.2 James
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
On Sat, 2018-09-08 at 16:26 +0100, David Howells wrote: > Marcel Holtmann wrote: > > > > > so I have reviewed and tested this code. In addition, we have test cases for > > it in ELL (embedded linux library). > > I wonder if there's any practical way to add a test for this to the keyutils > test suite. I'm guessing it's quite tricky, given the extra bits you need to > emulate the TPM. Right, for a lot of userspace stuff we have the TPM emulator but for the kernel you might need to run in qemu, which I believe can emulate a TPM now (or at least, can talk to the TPM emulator, which has the same effect). smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
On Sat, 2018-09-08 at 16:26 +0100, David Howells wrote: > Marcel Holtmann wrote: > > > > > so I have reviewed and tested this code. In addition, we have test cases for > > it in ELL (embedded linux library). > > I wonder if there's any practical way to add a test for this to the keyutils > test suite. I'm guessing it's quite tricky, given the extra bits you need to > emulate the TPM. Right, for a lot of userspace stuff we have the TPM emulator but for the kernel you might need to run in qemu, which I believe can emulate a TPM now (or at least, can talk to the TPM emulator, which has the same effect). smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
On Wed, 2018-09-05 at 22:54 +0100, David Howells wrote: > > Example usage for a PKCS#8 blob: > > j=`openssl pkcs8 -in private_key.pem -topk8 -nocrypt -outform DER | \ > keyctl padd asymmetric foo @s` > > Example usage for a TPM wrapped blob: > > openssl genrsa -out /tmp/privkey.foo.pem 2048 > create_tpm_key -s 2048 -w /tmp/privkey.foo.pem /tmp/privkey.foo.tpm > j=`openssl asn1parse -inform pem -in /tmp/privkey.foo.tpm -noout | > keyctl padd asymmetric foo @s` Those examples aren't equivalent. For the PKCS#8 blob you are first using openssl to convert from an encrypted PKCS#8 PEM to unencrypted DER, presumably because you haven't added decryption support (or base64 decode) to keyctl yet. For the TPM example though, you are also showing the *generation* of the key, and importing it into the TPM. And then I'm confused by the 'openssl asn1parse' line there... what is that actually doing? If I run it on a '-BEGIN TSS KEY BLOB-' file I have lying around, I get no output at all. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
On Wed, 2018-09-05 at 22:54 +0100, David Howells wrote: > > Example usage for a PKCS#8 blob: > > j=`openssl pkcs8 -in private_key.pem -topk8 -nocrypt -outform DER | \ > keyctl padd asymmetric foo @s` > > Example usage for a TPM wrapped blob: > > openssl genrsa -out /tmp/privkey.foo.pem 2048 > create_tpm_key -s 2048 -w /tmp/privkey.foo.pem /tmp/privkey.foo.tpm > j=`openssl asn1parse -inform pem -in /tmp/privkey.foo.tpm -noout | > keyctl padd asymmetric foo @s` Those examples aren't equivalent. For the PKCS#8 blob you are first using openssl to convert from an encrypted PKCS#8 PEM to unencrypted DER, presumably because you haven't added decryption support (or base64 decode) to keyctl yet. For the TPM example though, you are also showing the *generation* of the key, and importing it into the TPM. And then I'm confused by the 'openssl asn1parse' line there... what is that actually doing? If I run it on a '-BEGIN TSS KEY BLOB-' file I have lying around, I get no output at all. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Marcel Holtmann wrote: > so I have reviewed and tested this code. In addition, we have test cases for > it in ELL (embedded linux library). I wonder if there's any practical way to add a test for this to the keyutils test suite. I'm guessing it's quite tricky, given the extra bits you need to emulate the TPM. David
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Marcel Holtmann wrote: > so I have reviewed and tested this code. In addition, we have test cases for > it in ELL (embedded linux library). I wonder if there's any practical way to add a test for this to the keyutils test suite. I'm guessing it's quite tricky, given the extra bits you need to emulate the TPM. David
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
On Fri, 7 Sep 2018, Marcel Holtmann wrote: > Hi James, > > >> Here's a set of patches that does the following, if you could pull it > >> please: > > > > Thanks, it would be good to see more review / acks, though. > > so I have reviewed and tested this code. In addition, we have test cases for > it in ELL (embedded linux library). > > Tested-by: Marcel Holtmann > Reviewed-by: Marcel Holtmann Thanks! -- James Morris
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
On Fri, 7 Sep 2018, Marcel Holtmann wrote: > Hi James, > > >> Here's a set of patches that does the following, if you could pull it > >> please: > > > > Thanks, it would be good to see more review / acks, though. > > so I have reviewed and tested this code. In addition, we have test cases for > it in ELL (embedded linux library). > > Tested-by: Marcel Holtmann > Reviewed-by: Marcel Holtmann Thanks! -- James Morris
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Hi James, >> Here's a set of patches that does the following, if you could pull it please: > > Thanks, it would be good to see more review / acks, though. so I have reviewed and tested this code. In addition, we have test cases for it in ELL (embedded linux library). Tested-by: Marcel Holtmann Reviewed-by: Marcel Holtmann Regards Marcel
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Hi James, >> Here's a set of patches that does the following, if you could pull it please: > > Thanks, it would be good to see more review / acks, though. so I have reviewed and tested this code. In addition, we have test cases for it in ELL (embedded linux library). Tested-by: Marcel Holtmann Reviewed-by: Marcel Holtmann Regards Marcel
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
On Wed, 5 Sep 2018, David Howells wrote: > > Hi James, > > Here's a set of patches that does the following, if you could pull it please: Thanks, it would be good to see more review / acks, though. -- James Morris
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
On Wed, 5 Sep 2018, David Howells wrote: > > Hi James, > > Here's a set of patches that does the following, if you could pull it please: Thanks, it would be good to see more review / acks, though. -- James Morris
[PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Hi James, Here's a set of patches that does the following, if you could pull it please: (1) Adds keyctl() functions that permit an asymmetric-type key to be used to encrypt, decrypt, sign and verify a small piece of data (typically a session key or a hash) using the public and/or private key held in the kernel. A query function is also provided. (2) Adds an asymmetric-key parser for PKCS#8 to allow RSA private keys to be passed to the kernel. Currently only DER-encoded and unencrypted PKCS#8 is supported. (3) Adds an asymmetric-key parser for TPM-wrapped key blobs. The parser gets the TPM to unpack the blob and then attaches it to a key from which it can be used. Currently only TPM-1.2 is supported. Example usage for a PKCS#8 blob: j=`openssl pkcs8 -in private_key.pem -topk8 -nocrypt -outform DER | \ keyctl padd asymmetric foo @s` Example usage for a TPM wrapped blob: openssl genrsa -out /tmp/privkey.foo.pem 2048 create_tpm_key -s 2048 -w /tmp/privkey.foo.pem /tmp/privkey.foo.tpm j=`openssl asn1parse -inform pem -in /tmp/privkey.foo.tpm -noout | keyctl padd asymmetric foo @s` See http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#rfc.section.4.4 These keys can then be used thusly: echo -n abcdefghijklmnopqrst >/tmp/data keyctl pkey_encrypt $j /tmp/data enc=pkcs1 >/tmp/enc keyctl pkey_decrypt $j /tmp/enc enc=pkcs1 >/tmp/dec cmp /tmp/data /tmp/dec keyctl pkey_sign $j /tmp/data enc=pkcs1 hash=sha1 >/tmp/sig keyctl pkey_verify $j /tmp/data /tmp/sig enc=pkcs1 hash=sha1 The kernel patches can be found tagged here: https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/tag/?h=keys-asym-keyctl-20180905 and also on a branch here: http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-asym-keyctl The keyutils changes needed can be found here: http://git.kernel.org/cgit/linux/kernel/git/dhowells/keyutils.git/log/?h=next David --- David Howells (8): KEYS: Provide key type operations for asymmetric key ops KEYS: Provide keyctls to drive the new key type ops for asymmetric keys KEYS: Provide missing asymmetric key subops for new key type ops KEYS: Make the X.509 and PKCS7 parsers supply the sig encoding type KEYS: Provide software public key query function KEYS: Allow the public_key struct to hold a private key KEYS: Implement encrypt, decrypt and sign for software asymmetric key KEYS: Implement PKCS#8 RSA Private Key parser Denis Kenzior (14): crypto: rsa-pkcs1pad: Allow hash to be optional KEYS: asym_tpm: add skeleton for asym_tpm KEYS: asym_tpm: extract key size & public key KEYS: Add parser for TPM-based keys KEYS: asym_tpm: Implement pkey_query KEYS: asym_tpm: Implement encryption operation KEYS: trusted: Expose common functionality KEYS: Move trusted.h to include/keys KEYS: asym_tpm: Add loadkey2 and flushspecific KEYS: asym_tpm: Implement tpm_unbind KEYS: asym_tpm: Implement the decrypt operation KEYS: asym_tpm: Implement signature verification KEYS: asym_tpm: Implement tpm_sign KEYS: asym_tpm: Add support for the sign operation Documentation/crypto/asymmetric-keys.txt | 26 + Documentation/security/keys/core.rst | 217 ++ crypto/asymmetric_keys/Kconfig| 31 + crypto/asymmetric_keys/Makefile | 25 + crypto/asymmetric_keys/asym_tpm.c | 988 + crypto/asymmetric_keys/asymmetric_keys.h |3 crypto/asymmetric_keys/asymmetric_type.c | 43 + crypto/asymmetric_keys/pkcs7_parser.c |1 crypto/asymmetric_keys/pkcs8.asn1 | 24 + crypto/asymmetric_keys/pkcs8_parser.c | 184 + crypto/asymmetric_keys/public_key.c | 191 +- crypto/asymmetric_keys/signature.c| 95 +++ crypto/asymmetric_keys/tpm.asn1 |5 crypto/asymmetric_keys/tpm_parser.c | 102 +++ crypto/asymmetric_keys/x509_cert_parser.c | 21 - crypto/rsa-pkcs1pad.c | 59 +- include/crypto/asym_tpm_subtype.h | 19 + include/crypto/public_key.h | 14 include/keys/asymmetric-subtype.h |9 include/keys/trusted.h| 136 include/linux/key-type.h | 11 include/linux/keyctl.h| 46 + include/uapi/linux/keyctl.h | 30 + security/keys/Makefile|1 security/keys/compat.c| 18 + security/keys/internal.h | 39 + security/keys/keyctl.c| 24 + security/keys/keyctl_pkey.c | 323 + security/keys/trusted.c | 14 security/keys/trusted.h | 124 30 files changed, 2639
[PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Hi James, Here's a set of patches that does the following, if you could pull it please: (1) Adds keyctl() functions that permit an asymmetric-type key to be used to encrypt, decrypt, sign and verify a small piece of data (typically a session key or a hash) using the public and/or private key held in the kernel. A query function is also provided. (2) Adds an asymmetric-key parser for PKCS#8 to allow RSA private keys to be passed to the kernel. Currently only DER-encoded and unencrypted PKCS#8 is supported. (3) Adds an asymmetric-key parser for TPM-wrapped key blobs. The parser gets the TPM to unpack the blob and then attaches it to a key from which it can be used. Currently only TPM-1.2 is supported. Example usage for a PKCS#8 blob: j=`openssl pkcs8 -in private_key.pem -topk8 -nocrypt -outform DER | \ keyctl padd asymmetric foo @s` Example usage for a TPM wrapped blob: openssl genrsa -out /tmp/privkey.foo.pem 2048 create_tpm_key -s 2048 -w /tmp/privkey.foo.pem /tmp/privkey.foo.tpm j=`openssl asn1parse -inform pem -in /tmp/privkey.foo.tpm -noout | keyctl padd asymmetric foo @s` See http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#rfc.section.4.4 These keys can then be used thusly: echo -n abcdefghijklmnopqrst >/tmp/data keyctl pkey_encrypt $j /tmp/data enc=pkcs1 >/tmp/enc keyctl pkey_decrypt $j /tmp/enc enc=pkcs1 >/tmp/dec cmp /tmp/data /tmp/dec keyctl pkey_sign $j /tmp/data enc=pkcs1 hash=sha1 >/tmp/sig keyctl pkey_verify $j /tmp/data /tmp/sig enc=pkcs1 hash=sha1 The kernel patches can be found tagged here: https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/tag/?h=keys-asym-keyctl-20180905 and also on a branch here: http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-asym-keyctl The keyutils changes needed can be found here: http://git.kernel.org/cgit/linux/kernel/git/dhowells/keyutils.git/log/?h=next David --- David Howells (8): KEYS: Provide key type operations for asymmetric key ops KEYS: Provide keyctls to drive the new key type ops for asymmetric keys KEYS: Provide missing asymmetric key subops for new key type ops KEYS: Make the X.509 and PKCS7 parsers supply the sig encoding type KEYS: Provide software public key query function KEYS: Allow the public_key struct to hold a private key KEYS: Implement encrypt, decrypt and sign for software asymmetric key KEYS: Implement PKCS#8 RSA Private Key parser Denis Kenzior (14): crypto: rsa-pkcs1pad: Allow hash to be optional KEYS: asym_tpm: add skeleton for asym_tpm KEYS: asym_tpm: extract key size & public key KEYS: Add parser for TPM-based keys KEYS: asym_tpm: Implement pkey_query KEYS: asym_tpm: Implement encryption operation KEYS: trusted: Expose common functionality KEYS: Move trusted.h to include/keys KEYS: asym_tpm: Add loadkey2 and flushspecific KEYS: asym_tpm: Implement tpm_unbind KEYS: asym_tpm: Implement the decrypt operation KEYS: asym_tpm: Implement signature verification KEYS: asym_tpm: Implement tpm_sign KEYS: asym_tpm: Add support for the sign operation Documentation/crypto/asymmetric-keys.txt | 26 + Documentation/security/keys/core.rst | 217 ++ crypto/asymmetric_keys/Kconfig| 31 + crypto/asymmetric_keys/Makefile | 25 + crypto/asymmetric_keys/asym_tpm.c | 988 + crypto/asymmetric_keys/asymmetric_keys.h |3 crypto/asymmetric_keys/asymmetric_type.c | 43 + crypto/asymmetric_keys/pkcs7_parser.c |1 crypto/asymmetric_keys/pkcs8.asn1 | 24 + crypto/asymmetric_keys/pkcs8_parser.c | 184 + crypto/asymmetric_keys/public_key.c | 191 +- crypto/asymmetric_keys/signature.c| 95 +++ crypto/asymmetric_keys/tpm.asn1 |5 crypto/asymmetric_keys/tpm_parser.c | 102 +++ crypto/asymmetric_keys/x509_cert_parser.c | 21 - crypto/rsa-pkcs1pad.c | 59 +- include/crypto/asym_tpm_subtype.h | 19 + include/crypto/public_key.h | 14 include/keys/asymmetric-subtype.h |9 include/keys/trusted.h| 136 include/linux/key-type.h | 11 include/linux/keyctl.h| 46 + include/uapi/linux/keyctl.h | 30 + security/keys/Makefile|1 security/keys/compat.c| 18 + security/keys/internal.h | 39 + security/keys/keyctl.c| 24 + security/keys/keyctl_pkey.c | 323 + security/keys/trusted.c | 14 security/keys/trusted.h | 124 30 files changed, 2639
