Linux-Integrity Archive on
 help / color / Atom feed
From: Ken Goldman <>
To: Lakshmi <>,
	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: Thu, 16 May 2019 10:34:12 -0400
Message-ID: <> (raw)
In-Reply-To: <>

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?

  parent 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 [this message]
2019-05-17  1:29   ` Lakshmi
2019-05-17 14:41     ` Ken Goldman
2019-05-20 23:15       ` Lakshmi
2019-05-22 18:57         ` Ken Goldman
2019-05-22 19:37           ` Lakshmi

Reply instructions:

You may reply publically 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

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox