| Message ID | 6b69f115-96cf-890a-c92b-0b2b05798357@linux.microsoft.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | public key: IMA signer logging: Log public key of IMA Signature signer in IMA log | expand |
On Tue, 2019-05-14 at 10:14 -0700, Lakshmi wrote: > The motive behind this patch series is to measure the public key > of the IMA signature signer in the IMA log. > > The IMA signature of the file, logged using ima-sig template, contains > the key identifier of the key that was used to generate the signature. > But outside the client machine this key id is not sufficient to > uniquely determine which key the signature corresponds to. > Providing the public key of the signer in the IMA log would > allow, for example, an attestation service to securely verify > if the key used to generate the IMA signature is a valid and > trusted one, and that the key has not been revoked or expired. > > An attestation service would just need to maintain a list of > valid public keys and using the data from the IMA log can attest > the system files loaded on the client machine. > > To achieve the above the patch series does the following: > - Adds a new method in asymmetric_key_subtype to query > the public key of the given key > - Adds a new IMA template namely "ima-sigkey" to store\read > the public key of the IMA signature signer. This template > extends the existing template "ima-sig" Why duplicate the certificate info on each record in the measurement list? Why not add the certificate info once, as the key is loaded onto the .ima and .platform keyrings? Mimi > > Lakshmi (2): > add support for querying public key from a given key > add a new template ima-sigkey to store/read the public, key of ima > signature signer > > .../admin-guide/kernel-parameters.txt | 2 +- > Documentation/crypto/asymmetric-keys.txt | 1 + > Documentation/security/IMA-templates.rst | 5 +- > crypto/asymmetric_keys/public_key.c | 7 +++ > crypto/asymmetric_keys/signature.c | 24 +++++++++ > include/crypto/public_key.h | 1 + > include/keys/asymmetric-subtype.h | 3 ++ > security/integrity/digsig.c | 54 +++++++++++++++++-- > security/integrity/digsig_asymmetric.c | 44 +++++++++++++++ > security/integrity/ima/Kconfig | 3 ++ > security/integrity/ima/ima_template.c | 3 ++ > security/integrity/ima/ima_template_lib.c | 43 +++++++++++++++ > security/integrity/ima/ima_template_lib.h | 4 ++ > security/integrity/integrity.h | 29 +++++++++- > 14 files changed, 216 insertions(+), 7 deletions(-) >
Hi Mimi, I would like to make sure I understood your feedback. > > Why duplicate the certificate info on each record in the measurement > list? Why not add the certificate info once, as the key is loaded > onto the .ima and .platform keyrings? > > Mimi > key_create_or_update function in security/keys/key.c is called to add\update a key to a keyring. Are you suggesting that an IMA function be called from here to add the certificate info to the IMA log? Our requirement is that the key information is available in the IMA log which is TPM backed. Thanks, -lakshmi
On 5/14/2019 1:14 PM, Lakshmi wrote: > The motive behind this patch series is to measure the public key > of the IMA signature signer in the IMA log. I have some questions about the rationale for the design ... > > The IMA signature of the file, logged using ima-sig template, contains > the key identifier of the key that was used to generate the signature. > But outside the client machine this key id is not sufficient to > uniquely determine which key the signature corresponds to. Why is this not sufficient? In my implementation, I create a lookup table at the attestation service that maps the 4-byte IMA log key identifier to the signing public key. Are you concerned about collisions? Something else? > Providing the public key of the signer in the IMA log would > allow, for example, an attestation service to securely verify > if the key used to generate the IMA signature is a valid and > trusted one, and that the key has not been revoked or expired. Are you suggesting that the client supply the verification public key and that the verifier trust it? Wouldn't that make the log self signed? How would the verifier determine that the key from the IMA log is valid / trusted / not revoked from the log itself? > An attestation service would just need to maintain a list of > valid public keys and using the data from the IMA log can attest > the system files loaded on the client machine. If the verifier has the list of valid keys, why must they also come with the IMA log? > > To achieve the above the patch series does the following: > - Adds a new method in asymmetric_key_subtype to query > the public key of the given key > - Adds a new IMA template namely "ima-sigkey" to store\read > the public key of the IMA signature signer. This template > extends the existing template "ima-sig" A minor question here. Are you proposing that the IMA log contain a single ima-sigkey entry per public key followed by ima-sig entries? Or are you proposing that ima-sig be replaced by ima-sigkey, and that each event would contain both the signature and the public key? If the latter, this could add 25M to a server's 100K log. Would that increase in size concern anyone? Could it be a concern on the other end, an IoT device with limited memory?
On Wed, 2019-05-15 at 11:17 -0700, Lakshmi wrote: > Hi Mimi, > > I would like to make sure I understood your feedback. > > > > > Why duplicate the certificate info on each record in the measurement > > list? Why not add the certificate info once, as the key is loaded > > onto the .ima and .platform keyrings? > > > > key_create_or_update function in security/keys/key.c is called to > add\update a key to a keyring. Are you suggesting that an IMA function > be called from here to add the certificate info to the IMA log? There's an existing LSM hook in alloc_key(), but the keyring isn't being passed. Again a decision would need to be made as to whether this needs to be an LSM or IMA hook. > > Our requirement is that the key information is available in the IMA log > which is TPM backed. > There's some confusion as to why adding the keys to the measurement list is needed. Could you respond to Ken's questions please? Mimi
On 5/16/19 7:34 AM, Ken Goldman wrote: >> But outside the client machine this key id is not sufficient to >> uniquely determine which key the signature corresponds to. > > Why is this not sufficient? > > In my implementation, I create a lookup table at the attestation service > that maps the 4-byte IMA log key identifier to the signing public key. > > Are you concerned about collisions? Something else? Yes - the concern is collision. The "Subject Key Identifier" (SKI) for no two certificate can be the same. But since we are using only the last 4 bytes of the SKI it can collide. That's mainly the reason I want to log the entire public key. > > Are you suggesting that the client supply the verification public key > and that the verifier trust it? Wouldn't that make the log self signed? > > How would the verifier determine that the key from the IMA log is valid > / trusted / not revoked from the log itself? IMA log is backed by the TPM. So if the public key is added to the IMA log the attestation service can validate the key information. I am not sure if that answers your question. > > A minor question here. > > Are you proposing that the IMA log contain a single ima-sigkey entry per > public key followed by ima-sig entries? > > Or are you proposing that ima-sig be replaced by ima-sigkey, and that > each event would contain both the signature and the public key? > > If the latter, this could add 25M to a server's 100K log. Would that > increase in size concern anyone? Could it be a concern on the other > end, an IoT device with limited memory? Mimi had raised the same concern. I will update my implementation to include the certification information in the IMA log only once per key - when that key is added to the IMA or Platform keyring. Thanks, -lakshmi
On 5/16/2019 9:29 PM, Lakshmi wrote: > On 5/16/19 7:34 AM, Ken Goldman wrote: > >>> But outside the client machine this key id is not sufficient to >>> uniquely determine which key the signature corresponds to. >> >> Why is this not sufficient? >> >> In my implementation, I create a lookup table at the attestation >> service that maps the 4-byte IMA log key identifier to the signing >> public key. >> >> Are you concerned about collisions? Something else? > > Yes - the concern is collision. > > The "Subject Key Identifier" (SKI) for no two certificate can be the > same. But since we are using only the last 4 bytes of the SKI it can > collide. That's mainly the reason I want to log the entire public key. > Since a platform typically uses only a few signing keys, 4 bytes makes the chance of a collision quite small. The collision would have to be within the same log, not global. In that worst case, the verifier would have to try two keys. It's a slight performance penalty, but does anything break? A new template with a larger SKI, perhaps 8 bytes, might be safer. It doesn't expand the log size nearly as much as having a full public key. >> Are you suggesting that the client supply the verification public key >> and that the verifier trust it? Wouldn't that make the log self signed? >> >> How would the verifier determine that the key from the IMA log is >> valid / trusted / not revoked from the log itself? > > IMA log is backed by the TPM. So if the public key is added to the IMA > log the attestation service can validate the key information. > I am not sure if that answers your question. The TPM just ensures that the log has not been altered. It does nothing for signature verification, right? The verifier can check that the supplied signature matches the supplied public key. However, how could it verify that the public key is trusted to sign the code? Doesn't that have to be out of band? E.g., an attacker could create a log with their own signatures and public keys. The signature would verify, but it's the attacker's key. It's essentially a self-signed file. >> A minor question here. >> >> Are you proposing that the IMA log contain a single ima-sigkey entry >> per public key followed by ima-sig entries? >> >> Or are you proposing that ima-sig be replaced by ima-sigkey, and that >> each event would contain both the signature and the public key? >> >> If the latter, this could add 25M to a server's 100K log. Would that >> increase in size concern anyone? Could it be a concern on the other >> end, an IoT device with limited memory? > > Mimi had raised the same concern. I will update my implementation to > include the certification information in the IMA log only once per key - > when that key is added to the IMA or Platform keyring. If you include the public key only once, don't you have the same collision problem? Two log entries could (in theory) and the same SKI. How would the verifier know which public key to use. However, I think the fundamental question is whether the verifier can accept public keys supplied by the untrusted client. I believe that the verifier has to receive the public keys out of band, from a trusted source - not the client.
On 5/17/19 7:41 AM, Ken Goldman wrote: Hi Ken, Apologize for the delay in responding. > Since a platform typically uses only a few signing keys, 4 bytes makes > the chance of a collision quite small. The collision would have to be > within the same log, not global. > > In that worst case, the verifier would have to try two keys. It's a > slight performance penalty, but does anything break? Problem Statement: - If the attestation service has to re-validate the signature reported in the IMA log, the service has to maintain the hash\signature of all the binaries deployed on all the client nodes. This approach will not scale for large cloud deployments. - Possibility of collision of "Key Ids" is non-zero - In the service if the "Key Id" alone is used to verify using a map of "Key Id" to "Signing Key(s)", the service cannot determine if the trusted signing key was indeed used by the client for signature validation (Due to "Key Id" collision issue or malicious signature). Proposed Solution: - The service receives known\trusted signing key(s) from a trusted source (that is different from the client machines) - The clients measure the keys in key rings such as IMA, Platform, BuiltIn Trusted, etc. as early as possible in the boot sequence. - Leave all IMA measurements the same - i.e., we don't log public keys in the IMA log for each file, but just use what is currently available in IMA. Impact: - The service can verify that the keyrings have only known\trusted keys. - The service can cross check the "key id" with the key rings measured. - The look up of keys using the key id would be simpler and faster on the service side. - It can also handle collision of Key Ids. Note that the following is a key assumption: - Only keys signed by a key in the "BuiltIn Trusted Keyring" can be added to IMA\Platform keyrings. Thanks, -lakshmi
On 5/20/2019 7:15 PM, Lakshmi wrote: > On 5/17/19 7:41 AM, Ken Goldman wrote: > > Hi Ken, > > Apologize for the delay in responding. > >> Since a platform typically uses only a few signing keys, 4 bytes makes >> the chance of a collision quite small. The collision would have to be >> within the same log, not global. >> >> In that worst case, the verifier would have to try two keys. It's a >> slight performance penalty, but does anything break? > > Problem Statement: > - If the attestation service has to re-validate the signature reported > in the IMA log, the service has to maintain the hash\signature of all > the binaries deployed on all the client nodes. This approach will not > scale for large cloud deployments. 1 - How is your solution - including a public key with each event - related to this issue? 2 - I don't understand how a large cloud affects scale. Wouldn't the verifier would typically be checking known machines - those of their enterprise - not every machine on the cloud? Can't we assume a typical attestation use case has a fairly locked down OS with a limited number of applications. > - Possibility of collision of "Key Ids" is non-zero > - In the service if the "Key Id" alone is used to verify using a map of > "Key Id" to "Signing Key(s)", the service cannot determine if the > trusted signing key was indeed used by the client for signature > validation (Due to "Key Id" collision issue or malicious signature). Like I said, it should be rare. In the worst case, can't the service tell by trying both keys? > > Proposed Solution: > - The service receives known\trusted signing key(s) from a trusted > source (that is different from the client machines) > - The clients measure the keys in key rings such as IMA, Platform, > BuiltIn Trusted, etc. as early as possible in the boot sequence. > - Leave all IMA measurements the same - i.e., we don't log public keys > in the IMA log for each file, but just use what is currently available > in IMA. I thought your solution was to change the IMA measurements, adding the public key to each entry with a new template? Did I misunderstand, or do you have a new proposal? > > Impact: > - The service can verify that the keyrings have only known\trusted keys. If the service already has trusted keys from a trusted source, why do they have to come from the client at all? > - The service can cross check the "key id" with the key rings measured. > - The look up of keys using the key id would be simpler and faster on > the service side. > - It can also handle collision of Key Ids. How does this solve the collision issue? If there are two keys with the same key ID, isn't there still a collision? > > Note that the following is a key assumption: > > - Only keys signed by a key in the "BuiltIn Trusted Keyring" can be > added to IMA\Platform keyrings. I understand how the client keyring is used in IMA to check file signatures, but how is that related to the attestation service? > > > Thanks, > -lakshmi >
On 5/22/19 11:57 AM, Ken Goldman wrote: > > 1 - How is your solution - including a public key with each event - > related to this issue? This a change from my earlier proposal. In the new proposal I am making the public key is not included with each event. The data included in each IMA event does not change. For instance, when IMA signature validation is selected (ima-sig template, for instance), each event will have the IMA signature (which includes the 4 Byte Key Identifier and the Signature) > 2 - I don't understand how a large cloud affects scale. Wouldn't the > verifier would typically be checking known machines - those of their > enterprise - not every machine on the cloud? > > Can't we assume a typical attestation use case has a fairly locked down > OS with a limited number of applications. Yes - the attestation service (verifier) will be attesting only client machines known to the enterprise. But such clients could be running different versions of the OS and the kernel modules. We cannot assume that this would be a limited set. Therefore, maintaining the hash\signature of all such components, for all versions of the components, and re-validating that in the service is not a scalable solution. Instead, we want the IMA sub-system on the clients to do the signature validation (As it is done today). In addition to that, the clients will log the public keys from keyrings such as IMA, Platform, and BuiltIn Trusted Keys - this will be done only once and not in each IMA event (This is a change from my earlier proposal). Using this data the service will verify that the clients used only trusted key(s) for signature validation. > > Like I said, it should be rare. In the worst case, can't the service > tell by trying both keys?If the service is validating the signature again it can try all the keys. But we don't want to take that approach - instead we want to verify the keys used by the client. > > I thought your solution was to change the IMA measurements, adding the > public key to each entry with a new template? Did I misunderstand, or > do you have a new proposal? I have a new proposal as described above. Sorry if I had confused you. > How does this solve the collision issue? If there are two keys with the > same key ID, isn't there still a collision? Like I have said above, the client will log all the keys from the relevant keyrings (IMA, Platform, etc.) The service will verify that they are all known\trusted keys - which gives the assurance that the IMA signature validation done by the client was performed using trusted signing key(s). > I understand how the client keyring is used in IMA to check file > signatures, but how is that related to the attestation service? In my new proposal, the keys in the client keyrings will be logged in the IMA log. The attestation service will verify that they are known\trusted keys. Thanks, -lakshmi
The motive behind this patch series is to measure the public key of the IMA signature signer in the IMA log. The IMA signature of the file, logged using ima-sig template, contains the key identifier of the key that was used to generate the signature. But outside the client machine this key id is not sufficient to uniquely determine which key the signature corresponds to. Providing the public key of the signer in the IMA log would allow, for example, an attestation service to securely verify if the key used to generate the IMA signature is a valid and trusted one, and that the key has not been revoked or expired. An attestation service would just need to maintain a list of valid public keys and using the data from the IMA log can attest the system files loaded on the client machine. To achieve the above the patch series does the following: - Adds a new method in asymmetric_key_subtype to query the public key of the given key - Adds a new IMA template namely "ima-sigkey" to store\read the public key of the IMA signature signer. This template extends the existing template "ima-sig" Lakshmi (2): add support for querying public key from a given key add a new template ima-sigkey to store/read the public, key of ima signature signer .../admin-guide/kernel-parameters.txt | 2 +- Documentation/crypto/asymmetric-keys.txt | 1 + Documentation/security/IMA-templates.rst | 5 +- crypto/asymmetric_keys/public_key.c | 7 +++ crypto/asymmetric_keys/signature.c | 24 +++++++++ include/crypto/public_key.h | 1 + include/keys/asymmetric-subtype.h | 3 ++ security/integrity/digsig.c | 54 +++++++++++++++++-- security/integrity/digsig_asymmetric.c | 44 +++++++++++++++ security/integrity/ima/Kconfig | 3 ++ security/integrity/ima/ima_template.c | 3 ++ security/integrity/ima/ima_template_lib.c | 43 +++++++++++++++ security/integrity/ima/ima_template_lib.h | 4 ++ security/integrity/integrity.h | 29 +++++++++- 14 files changed, 216 insertions(+), 7 deletions(-)