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

[Mario Six]

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.

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

Best regards,

Mario