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

[Mohit Sethi <[e-mail]>]

Hi Hannes,

On 6/15/23 17:33, Hannes Tschofenig wrote:
> 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:

And I can tell you how it is done in a real-world deployment where TPM 
is used in conjunction with an NXP i.MX 6 processor.

But the real question is, does the draft have appropriate terminology 
available for these different cases.

>
> 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%7C24b0b9fb84bf45fecd1e08db6dad8d68%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638224364826538666%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=Ko8SlTQHT%2FgzkBra4a4EjSDOaYVCn7g6nMi2Bo6mTDM%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.

Thank you for documenting these different options. I have practical 
experience with only one them.

The question still remains, does the draft have appropriate terminology 
available for the different cases you describe.

--Mohit

>
>
> Ciao
>
> Hanns
>
>
> _______________________________________________
> T2TRG mailing list
> [e-mail]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Ft2trg&data=05%7C01%7Cmohit.sethi%40aalto.fi%7C24b0b9fb84bf45fecd1e08db6dad8d68%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638224364826538666%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=UyJRfEnIjbut2cDUf%2B7pUSPu1qFYD89oqIk6cRL9Ldc%3D&reserved=0 
>