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

[Mohit Sethi <[e-mail]>]

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 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.
>
> 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).

Clearly you are an expert in this area. Maybe you can help the existing 
authors with appropriate text and even consider joining as a co-author 
(obliviously with the blessings of the existing authors and chairs see).

--Mohit

>
>
> Ciao
> Hannes
>
>