[U-Boot] [PATCH 1/3] tpm: Add function to load keys via their parent's SHA1 hash

[Simon Glass]

Hi Mario,

On 22 March 2017 at 08:07, Mario Six <mario.six at gdsys.cc> wrote:
> On Wed, Mar 22, 2017 at 2:27 PM, Simon Glass <sjg at chromium.org> wrote:
>> Hi Mario,
>>
>> On 22 March 2017 at 07:20, Mario Six <mario.six at gdsys.cc> wrote:
>>> On Wed, Mar 22, 2017 at 2:05 PM, Simon Glass <sjg at chromium.org> wrote:
>>>> On 20 March 2017 at 03:28, Mario Six <mario.six at gdsys.cc> wrote:
>>>>> If we want to load a key into a TPM, we need to know the designated parent
>>>>> key's handle, so that the TPM is able to insert the key at the correct place in
>>>>> the key hierarchy.
>>>>>
>>>>> However, if we want to load a key whose designated parent key we also
>>>>> previously loaded ourselves, we first need to memorize this parent key's handle
>>>>> (since the handles for the key are chosen at random when they are inserted into
>>>>> the TPM). If we are, however, unable to do so, for example if the parent key is
>>>>> loaded into the TPM during production, and its child key during the actual
>>>>> boot, we must find a different mechanism to identify the parent key.
>>>>>
>>>>> To solve this problem, we add a function that allows U-Boot to load a key into
>>>>> the TPM using their designated parent key's SHA1 hash, and the corresponding
>>>>> auth data.
>>>>>
>>>>> Signed-off-by: Mario Six <mario.six at gdsys.cc>
>>>>> ---
>>>>>  cmd/tpm.c           | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>  drivers/tpm/Kconfig |  8 ++++++++
>>>>>  include/tpm.h       | 12 ++++++++++++
>>>>>  lib/tpm.c           | 40 ++++++++++++++++++++++++++++++++++++++++
>>>>>  4 files changed, 109 insertions(+)
>>>>
>>>> Reviewed-by: Simon Glass <sjg at chromium.org>
>>>>
>>>> Perhaps you don't need a new Kconfig option? Is that to save code space?
>>>>
>>>>
>>>
>>> Yes, it's primarily to save code space. I haven't really investigated how much
>>> this option does impact the overall size, but since every recent addition to
>>> the TPM library was guarded with a new Kconfig option, I thought it was prudent
>>> to emulate that.
>>>
>>> If you think it's overkill, I can drop the option, and just have it
>>> compiled in by default.
>>
>> I think for now it is overkill, and I'm happy to just include the new
>> functionality always. We have a sandbox tpm emulator - can we use that
>> to write tests?
>>
>> Regards,
>> Simon
>>
>
> OK, no Kconfig option is good as well. :-)
>
> As for tests, I took a quick look at tpm_tis_sandbox.c: Right now, the driver
> doesn't support the TPM_LoadKey2 command, which is used to implement the
> loading mechanism. And it's decidedly non-trivial to implement it, primarily
> for the reason that U-Boot, at the moment, doesn't provide all the needed
> cryptographic primitives (the key blob that is loaded in is cryptographically
> secured). I know that RSA is implemented, but we would require OAEP padding,
> which is not implemented, and we would also need AES-128 in CBC mode. This
> could be overcome if we could somehow gain access to the host system's OpenSSL
> library from within the sandbox driver. Would that be possible? Then again, it
> would be pretty nice if we had working OAEP padding available for FIT image
> signing, so it might be worth implementing it.

Yes you can access OpenSSL - see for example os.c which is built by
the host tools and provides an interface between U-Boot and the C
libraries.

Also bear in mind that one option is to implement a 'fake', where it
appears to do the right thing, but in fact fakes most of its actions,
so that (for example) it doesn't provide any security checks. I'm not
suggesting that, but just pointing out that the primary purpose of
test code in U-Boot is to test U-Boot., so we don't need such faithful
implementations.

>
> So, bottom line: I'll look into it, but it will definitely take a while to have
> something usable at hand.
>
> Best regards,
>
> Mario

Regards,
Simon