Hi Viviane,

For Arm platforms, you may get a complete reference software stack (including TF-A, boot loader, Linux kernel, and user-space filesystem) on the Arm Community website:
https://community.arm.com/developer/tools-software/oss-platforms/w/docs/224/release-notes

As you can see, the latest version is 19.01 but the TF-A developers team at Arm currently uses version 18.04, as advertised in the TF-A User guide. Either version should work, though!

Regards,
Sandrine

Thanks Sandrine!

I think that's not what I had in mind. When we boot from TF-A does it produces a hash confirming the boot process was successful? If positive, where can we find that hash?
I'm using Raspberry Pi 3 with OP-TEE and TF-A.

Thanks again!

Hi vivina,
Are you thinking something similar to measured boot ?
The TF-A implements what is called verified boot. Found a good description for difference between verified and measured boot here:
https://forums.juniper.net/t5/Security/What-s-the-Difference-between-Secure-Boot-and-Measured-Boot/ba-p/281251

Measured boot is not yet implemented by TF-A but it is something we would like to do.

In T464#5627, @soby-mathew wrote:

Hi vivina,

Hi @soby-mathew !

Are you thinking something similar to measured boot ?

Yes exactly!

The TF-A implements what is called verified boot. Found a good description for difference between verified and measured boot here:
https://forums.juniper.net/t5/Security/What-s-the-Difference-between-Secure-Boot-and-Measured-Boot/ba-p/281251

Thank for the link! It's one of the best I read on the topic so far!

Measured boot is not yet implemented by TF-A but it is something we would like to do.

I understand TF-A currently has no support to measured boot but I was wondering if there's anything I can use to prove my boot integrity while this feature is not implemented.
Is there any way to access the certificates used during boot (the ones which were verified) after initialization? Where do the certificates go after boot? :-)

Hello,

Sorry, I completely missed your point at first!

Verified boot in itself already proves the boot integrity of all firmware images from BL1 up to BL33.

BL1 is the root of trust and cannot be tampered with, as it is hardware-protected. All other BL image are signed and their signature is verified before they get executed: BL1 verifies the signature of BL2, and BL2 does the same for all subsequent BL3x images. If one of the signatures is invalid then TF-A refuses to execute the corresponding image. This is treated as a fatal error that the firmware cannot recover from and the platform will typically panic in this case.

The following 2 documents describe the verified boot design and implementation (called "Trusted Board Boot" in TF-A lingo) in more details, if you're interested:

https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/design/trusted-board-boot.rst
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/design/auth-framework.rst

In short, if your platform boots successfully then the boot integrity is proven! With verified boot, no unauthorized firmware code can be executed on the device.

Now I am guessing what you're looking for is a way for TF-A to send a proof of that to some attestation server?

I am afraid there is no way to retrieve the verified boot information after the boot phase right now. The certificates used during boot are loaded from non-secure storage into secure RAM, then authenticated and parsed to extract further information used to verify BL images. They are used "on the fly" and all this information is discarded after boot time, as they have served their purpose and are not needed later. The certificates themselves are still accessible from non-secure storage (typically in the FIP image stored on the flash) but they cannot be trusted without verifying them again first, as an attacker could tamper with non-secure storage.

Does that help?

Hi @sandrine-bailleux-arm !

Verified boot in itself already proves the boot integrity of all firmware images from BL1 up to BL33.

BL1 is the root of trust and cannot be tampered with, as it is hardware-protected. All other BL image are signed and their signature is verified before they get executed: BL1 verifies the signature of BL2, and BL2 does the same for all subsequent BL3x images. If one of the signatures is invalid then TF-A refuses to execute the corresponding image. This is treated as a fatal error that the firmware cannot recover from and the platform will typically panic in this case.

Got it! So, just to be clear: Imagine a scenario with two devices - one I made (I know the keys and code on BL1) and another one that some malicious user cloned (he signed with his own keys). My device will have a Root of Trust in BL1 based on my hardware and the keys I own. The second device also has a BL1 but that image was signed by someone I don't trust. In the end, both devices will boot up successfully because they are based on each individual Chain of Trust but there's no way a third party (i.e. remote attestation server) can know the difference between the malicious device and my device solely relying on Verified Boot, right?

The following 2 documents describe the verified boot design and implementation (called "Trusted Board Boot" in TF-A lingo) in more details, if you're interested:

https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/design/trusted-board-boot.rst
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/design/auth-framework.rst

Thanks! I'll check them ;)

In short, if your platform boots successfully then the boot integrity is proven! With verified boot, no unauthorized firmware code can be executed on the device.

Agreed!

Now I am guessing what you're looking for is a way for TF-A to send a proof of that to some attestation server?

Exactly!

I am afraid there is no way to retrieve the verified boot information after the boot phase right now. The certificates used during boot are loaded from non-secure storage into secure RAM, then authenticated and parsed to extract further information used to verify BL images. They are used "on the fly" and all this information is discarded after boot time, as they have served their purpose and are not needed later. The certificates themselves are still accessible from non-secure storage (typically in the FIP image stored on the flash) but they cannot be trusted without verifying them again first, as an attacker could tamper with non-secure storage.

Does that help?

A lot! Thank you!
That was my conclusion too but I was afraid I missed something or didn't understand anything properly.
Thank you so much for clarifying this to me!

Hi @vivinamartins16,

So, just to be clear: Imagine a scenario with two devices - one I made (I know the keys and code on BL1) and another one that some malicious user cloned (he signed with his own keys). My device will have a Root of Trust in BL1 based on my hardware and the keys I own. The second device also has a BL1 but that image was signed by someone I don't trust. In the end, both devices will boot up successfully because they are based on each individual Chain of Trust but there's no way a third party (i.e. remote attestation server) can know the difference between the malicious device and my device solely relying on Verified Boot, right?

Correct. Verified boot is meant to prevent an attacker from replacing the firmware on a device. If somehow they manage to circumvent it and install their own firmware then all bets are off. In this case, the malicious firmware can fool the attestation server, which won't be able to tell the difference. So verified boot alone is not enough but it is a prerequisite for measured boot, as it guarantees the integrity of the firmware executing on the device and thus that the measurements can be trusted.

Regards,
Sandrine

Yes within the TF A ecosystem there exist artifacts such as hashes and objects which play a crucial role in facilitating attestation subsequent to a successful boot process.
Snow Services in O'Fallon IL