[PATCH 0/2] public key: IMA signer logging: Log public key of IMA Signature signer in IMA log

[PATCH 0/2] public key: IMA signer logging: Log public key of IMA Signature signer in IMA log

[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(-)

-- 
2.17.1

Re: [PATCH 0/2] public key: IMA signer logging: Log public key of IMA Signature signer in IMA log

[Mimi Zohar]

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(-)
> 

Re: [PATCH 0/2] public key: IMA signer logging: Log public key of IMA Signature signer in IMA log

[Lakshmi]

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

Re: [PATCH 0/2] public key: IMA signer logging: Log public key of IMA Signature signer in IMA log

[Ken Goldman]

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?

Re: [PATCH 0/2] public key: IMA signer logging: Log public key of IMA Signature signer in IMA log

[Mimi Zohar]

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

Re: [PATCH 0/2] public key: IMA signer logging: Log public key of IMA Signature signer in IMA log

[Lakshmi]

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

Re: [PATCH 0/2] public key: IMA signer logging: Log public key of IMA Signature signer in IMA log

[Ken Goldman]

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.

Re: [PATCH 0/2] public key: IMA signer logging: Log public key of IMA Signature signer in IMA log

[Lakshmi]

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

Re: [PATCH 0/2] public key: IMA signer logging: Log public key of IMA Signature signer in IMA log

[Ken Goldman]

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
> 

Re: [PATCH 0/2] public key: IMA signer logging: Log public key of IMA Signature signer in IMA log

[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