Linux-Integrity Archive on
 help / color / Atom feed
From: Lakshmi <>
To: Ken Goldman <>,
	Linux Integrity <>,
	Mimi Zohar <>,
	David Howells <>,
	James Morris <>,
	Linux Kernel <>
Cc: Balaji Balasubramanyan <>,
	Prakhar Srivastava <>,
Subject: Re: [PATCH 0/2] public key: IMA signer logging: Log public key of IMA Signature signer in IMA log
Date: Mon, 20 May 2019 16:15:28 -0700
Message-ID: <> (raw)
In-Reply-To: <>

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.

- 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.


  reply index

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-14 17:14 Lakshmi
2019-05-14 17:29 ` Mimi Zohar
2019-05-15 18:17   ` Lakshmi
2019-05-16 22:45     ` Mimi Zohar
2019-05-16 14:34 ` Ken Goldman
2019-05-17  1:29   ` Lakshmi
2019-05-17 14:41     ` Ken Goldman
2019-05-20 23:15       ` Lakshmi [this message]
2019-05-22 18:57         ` Ken Goldman
2019-05-22 19:37           ` Lakshmi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Integrity Archive on

Archives are clonable:
	git clone --mirror linux-integrity/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-integrity linux-integrity/ \
	public-inbox-index linux-integrity

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone