Re: [T2TRG] T2TRG interim meeting follow-ups - draft-irtf-t2trg-taxonomy-manufacturer-anchors-00

[Hannes Tschofenig <[e-mail]>]

Hi Mohit,


Am 15.06.2023 um 12:29 schrieb Mohit Sethi:
> Hi Hannes,
>
> On 6/15/23 12:57, Hannes Tschofenig wrote:
>> Hi Mohit,
>>
>>
>> Am 15.06.2023 um 11:34 schrieb Mohit Sethi:
>>>
>>> * Generally, reading and writing to TPM requires some minimal OS? How
>>> is that signed/verified/booted?
>>>
>>
>> A typical implementation of a TPM chip is some form of Cortex M
>> processor (with crypto hardware) running a firmware to support the TPM
>> specification functionality.
>>
>>
>> The code calling the TPM features is run on a separate processor. You
>> could call it the "application processor" since it will run the actual
>> application code. Typically, TPM chips are used with higher-end
>> processors (like Cortex A-class processors or similar) and they often
>> run embedded Linux or similar.
>
> This is exactly my point. How is the embedded Linux signed, installed,
> and trusted for interacting with the initially blank TPM in the
> factory assembly line. Hence, my question "TPM requires some minimal
> OS? How is that signed/verified/booted?"
>
I can tell you how this is done using non-TPM-based chips. The process
is simple:

The ROM-based bootloader starts. Let's call this the first stage boot
loader. It is typically located on a security processor (which is
nothing more than a Cortex M MCU, which has some hardware crypto). This
initial bootloader does very little since you cannot update it. It still
has to be able to verify the second stage boot loader. It does so by
verifying the digital signature covering the firmware image of the
second stage BL. Therefore, the first stage BL needs to have crypto
functionality for signature verification (typically the actual crypto
will be in hardware but there is a software layer around it to fetch the
public key and to call the API). Then, the first stage BL will release
control to the second stage BL. At this point only the security chip is
powered up. The second stage bootloader executes and now needs to load
code from flash (or some other external storage) to RAM to boot the
application processor. The details will vary depending what processor it
is. If it is an A-class processor, it needs to start with the secure
world first. Hence, it needs to load the code needed for that processor
into memory before triggering it. Before it does so, it again has to do
a signature check. The code on the secure world running on an A-class
processor consists of multiple layers, from Arm Trusted Firmware-A to
the trusted applications. Details again vary on what processor you use
and how much software layers you want. Then, when the secure world OS is
started it is time to start the normal world (which requires a
bootloader again, such as U-boot). At each layer you would then verify
the signature of the code running at the next layer.


>>
>> I have not seen TPM chips being used alongside low-end microcontrollers.
>>
>> Secure boot is also a simple concept: At every layer of the boot chain
>> you verify the next layer (before you hand over control to that next
>> layer). Since there are multiple layers in the boot process, the
>> hand-over happens several times.
>>
>> With secure boot the idea is that you stop the boot process when you
>> fail to successfully verify software/firmware. With measured boot, you
>> continue but report what you "measured". Measured typically means
>> computing a hash over the software/firmware plus some meta data.
> Thankfully, I understand the difference but somehow the terms are not
> explained or distinguished in the draft. And as you write below,
> manufacturers use a mixture of terminology which this draft should
> identify and highlight. At least I have seen some people use "Secure
> Boot" and "Verified Boot" interchangeably, as well as, use "Measured
> Boot" and "Trusted Boot" interchangeably.


Manufacturers invent new terms for marketing purposes. I would not
capture those in the draft.

For the "secure boot" and "measured boot" terminology reference some
existing document. Forget verified and trusted boot.


>>
>> See also
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedia.fidoalliance.org%2Fwp-content%2Fuploads%2F2022%2F12%2FFIDO-Device-Onboard-The-Device-Key-White-Paper.pdf&data=05%7C01%7Cmohit.sethi%40aalto.fi%7C1d643e061b2c4709a2ab08db6d86fcbb%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638224199461843832%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rXOcTVSx518cVbDSkVBQWiaOm70OmVzyU7dY8Krx3Vw%3D&reserved=0
>>
>> for more discussion about measured and secure boot.
>>
>>
>>> * When manufacturing my IoT device, how is the primary stage
>>> bootloader signed and verified?
>>
>>
>> The concept is simple: there is a root of trust, which is used to get
>> started. The root of trust includes a "minimum" amount of software,
>> hardware, keys and configuration which everything else relies on. For
>> the first stage bootloader you have to assume an immutable bootloader
>> code (typically stored in ROM) and immutable public keys (serving as
>> trust anchors). From a terminology point of view you have to decide
>> whether you call the first stage the immutable part  or the bootloader
>> that is started by the immutable part. When you read the data sheets of
>> manufacturers then you will realize that they mix the terminology (and
>> even invent their own terms). Hence, you have to read carefully.
>
> I think the draft does not explain the two possibilities: I give some
> public keys to the chip vendor which are fused and then I am
> responsible for signing my own bootloader. Or I give some public keys
> which are incorporated into the bootloader written by the chip vendor
> (which is then used for verifying the second stage of the boot process).


The question is: How much flexibility do you want in manufacturing?

You can ask a manufacturer to put your first stage bootloader with your
cert into immutable memory (ROM). Then, you control what software is
loaded in the second stage.

You can also put the cert of the manufacturer in the first stage
bootloader (in ROM). Then, you need to ask the manufacturer to sign your
public key to be able to get code onto the device. (Involving your
manufacturer every time you want to load a new second stage bootloader
on your device is probably not a great idea.)

You can also postpone loading the trust anchor to the chip to a later
stage in the lifecycle by using OTP memory.


Ciao

Hanns