From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
linux-integrity@vger.kernel.org, linux-crypto@vger.kernel.org,
linux-security-module@vger.kernel.org,
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [PATCH v4 2/7] tpm2-sessions: Add full HMAC and encrypt/decrypt session handling
Date: Thu, 25 Oct 2018 16:56:45 +0100 (IST) [thread overview]
Message-ID: <alpine.DEB.2.21.1810251643080.4065@jsakkine-mobl1> (raw)
In-Reply-To: <1540373514.3008.45.camel@HansenPartnership.com>
On Wed, 24 Oct 2018, James Bottomley wrote:
>>> +static void KDFa(u8 *key, int keylen, const char *label, u8 *u,
>>> + u8 *v, int bytes, u8 *out)
>>
>> Should this be in lower case? I would rename it as tpm_kdfa().
>
> This one is defined as KDFa() in the standards and it's not TPM
> specific (although some standards refer to it as KDFA). I'm not averse
> to making them tpm_kdfe() and tpm_kdfa() but I was hoping that one day
> the crypto subsystem would need them and we could move them in there
> because KDFs are the new shiny in crypto primitives (TLS 1.2 started
> using them, for instance).
I care more about tracing and debugging than naming and having 'tpm_' in
front of every TPM function makes tracing a lean process. AFAIK using
upper case letters is against kernel coding conventions. I'm not sure
why this would make an exception on that.
>> Why doesn't it matter here?
>
> Because, as the comment says, it eventually gets overwritten by running
> ecdh to derive the two co-ordinates. (pointers to these two
> uninitialized areas are passed into the ecdh destination sg list).
Oh, I just misunderstood the comment. Wouldn't it be easier to say that
the data is initialized later?
>>> + buf_len = crypto_ecdh_key_len(&p);
>>> + if (sizeof(encoded_key) < buf_len) {
>>> + dev_err(&chip->dev, "salt buffer too small needs
>>> %d\n",
>>> + buf_len);
>>> + goto out;
>>> + }
>>
>> In what situation this can happen? Can sizeof(encoded_key) >=
>> buf_len?
>
> Yes, but only if someone is trying to crack your ecdh. One of the
> security issues in ecdh is if someone makes a very specific point
> choice (usually in the cofactor space) that has a very short period,
> the attacker can guess the input to KDFe. In this case if TPM genie
> provided a specially crafted attack EC point, we'd detect it here
> because the resulting buffer would be too short.
Right. Thank you for the explanation. Here some kind of comment might
not be a bad idea...
>> In general this function should have a clear explanation what it does
>> and maybe less these one character variables but instead variables
>> with more documenting names. Explain in high level what algorithms
>> are used and how the salt is calculated.
>
> I'll try, but this is a rather complex function.
Understood. I do not expect perfection here and we can improve
documetation later on.
For anyone wanting to review James' patches and w/o much experience on
EC, I recommend reading this article:
https://arstechnica.com/information-technology/2013/10/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/
I read it few years ago and refreshed my memory few days ago by
re-reading it.
>
>>> +
>>> +/**
>>> + * tpm_buf_append_hmac_session() append a TPM session element
>>> + * @buf: The buffer to be appended
>>> + * @auth: the auth structure allocated by
>>> tpm2_start_auth_session()
>>> + * @attributes: The session attributes
>>> + * @passphrase: The session authority (NULL if none)
>>> + * @passphraselen: The length of the session authority (0 if none)
>>
>> The alignment.
>
> the alignment of what?
We generally have parameter descriptions tab-aligned.
>> Why there would be trailing zeros?
>
> Because TPM 1.2 mandated zero padded fixed size passphrases so the TPM
> 2.0 standard specifies a way of converting these to variable size
> strings by eliminating the zero padding.
Ok.
> James
I'm also looking forward for the CONTEXT_GAP patch based on the
yesterdays discussion. We do want it and I was stupid not to take it
couple years ago :-) Thanks.
/Jarkko
next prev parent reply other threads:[~2018-10-25 15:56 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-22 7:33 [PATCH v4 0/7] add integrity and security to TPM2 transactions James Bottomley
2018-10-22 7:35 ` [PATCH v4 1/7] tpm-buf: create new functions for handling TPM buffers James Bottomley
2018-10-23 19:12 ` Jarkko Sakkinen
2018-10-23 19:16 ` Jarkko Sakkinen
2018-10-22 7:36 ` [PATCH v4 2/7] tpm2-sessions: Add full HMAC and encrypt/decrypt session handling James Bottomley
2018-10-22 22:19 ` Ard Biesheuvel
2018-10-23 7:01 ` James Bottomley
2018-10-23 10:08 ` Ard Biesheuvel
2018-10-24 8:40 ` Jarkko Sakkinen
2018-10-23 23:48 ` Jarkko Sakkinen
2018-10-24 9:31 ` James Bottomley
2018-10-25 15:56 ` Jarkko Sakkinen [this message]
2018-10-22 7:37 ` [PATCH v4 3/7] tpm2: add hmac checks to tpm2_pcr_extend() James Bottomley
2018-10-22 7:37 ` [PATCH v4 4/7] tpm2: add session encryption protection to tpm2_get_random() James Bottomley
2018-10-22 7:38 ` [PATCH v4 5/7] trusted keys: Add session encryption protection to the seal/unseal path James Bottomley
2018-10-24 0:03 ` Jarkko Sakkinen
2018-10-22 7:39 ` [PATCH v4 6/7] tpm: add the null key name as a tpm2 sysfs variable James Bottomley
2018-10-22 7:40 ` [PATCH v4 7/7] tpm2-sessions: NOT FOR COMMITTING add sessions testing James Bottomley
2018-10-22 13:53 ` [PATCH v4 0/7] add integrity and security to TPM2 transactions Ken Goldman
2018-10-22 14:18 ` James Bottomley
2018-10-22 15:50 ` Ken Goldman
2018-10-22 15:55 ` James Bottomley
2018-10-24 0:13 ` Jarkko Sakkinen
2018-10-24 7:41 ` James Bottomley
2018-10-25 15:39 ` Jarkko Sakkinen
2018-10-24 0:06 ` Jarkko Sakkinen
2018-10-24 7:34 ` James Bottomley
2018-10-25 16:53 ` Ken Goldman
2018-10-23 23:51 ` Jarkko Sakkinen
2018-10-24 7:43 ` James Bottomley
2018-10-25 15:42 ` Jarkko Sakkinen
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.21.1810251643080.4065@jsakkine-mobl1 \
--to=jarkko.sakkinen@linux.intel.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=ard.biesheuvel@linaro.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).