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

Simon Glass sjg at chromium.org
Mon Mar 27 02:27:20 UTC 2017


On 22 March 2017 at 08:47, Simon Glass <sjg at chromium.org> wrote:
> 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.
>>

OK, keep it simple!

Applied to u-boot-dm, thanks!


More information about the U-Boot mailing list