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
