2

I'm using BBB in my project. I need to prevent any changes to the software running on it. I've been reading about uBoot and TPM. But if I understand everything correctly, this can't be implemented correctly, that is, in a really secure manner. I understand that during boot, each boot stage passes "something" to TPM, TPM hashes it with the previous value and stores the result in the proper register. But for it to work as expected, at least the first stage must be engraved in stone (or at least unchangeable by third party). This is not the case if the first stage (uBoot in my case) can be easily replaced and changed in such a way that what is passed to TPM is not what is executed later. This means that later stages can be changed (logic, data, anything) without TPM noticing them.

I believe there is a flaw in my logic or I failed to grasp some crucial detail, because AFAIK BIOS (first stage in aforementioned chain) can be overwritten with a new image, which means that an attacker with physical access to the machine could circumvent any security measures taken by the machine owner.

Where is the flaw in my thinking?

EDIT: I read about BBB, uBoot and TPM here. Also this question seems to corroborate my way of thinking

cactus4
  • 13
  • 3
Jędrzej Dudkiewicz
  • 163
  • 6

1 Answers1

3

I understand that during boot, each boot stage passes "something" to TPM

That "something" is the SHA-1 hash of the component being measured. The first thing sent is the hash of the BIOS. Subsequent hashes cause a register to "update" its hash. The TPM only unseals if the final hash matches what it expects. That final hash will only match if all hashes sent to it prior were correct.

This is typically how it goes for a traditional x86 system with a TPM. A BeagleBone is similar.

  1. The CRTM, which is read-only, sends the hash of the BIOS itself to the TPM.

  2. The BIOS sends the hash of the option ROMs, MBR, and bootloader to the TPM.

  3. The bootloader sends a hash of the kernel and boot parameters to the TPM.

If all the hashes were correct, then the final hash will match what the TPM expects. The TPM is then free to unseal, which means decrypt an arbitrary blob of data passed to it. This blob of data, when decrypted, proves to the sysadmin that nothing in the boot chain has been compromised. As long as the attacker does not know the contents of the decrypted blob, they cannot spoof it, even if they have tampered with the BIOS and have full control over how the system is to behave. This decrypted blob can either be used as a disk encryption key, or displayed to the sysadmin, indicating that it is safe to trust the firmware.

I believe there is a flaw in my logic or I failed to grasp some crucial detail, because AFAIK BIOS (first stage in aforementioned chain) can be overwritten with new image, which means that attacker with physical access to the machine could circumvent any security measures taken by machine owner.

There is a part of the BIOS called the boot block, or CRTM (Core Root-of-Trust for Measurement), which is not writable by software. An attacker would need to have physical access to replace the chip which holds the firmware. The CRTM is in charge of sending a hash of the rest of the BIOS to the TPM. This prevents a privileged local (not physical) attacker from bypassing the root of trust by writing the BIOS.

See also How does the TPM perform integrity measurements on a system?.

Glorfindel
  • 2,263
  • 6
  • 19
  • 30
forest
  • 65,613
  • 20
  • 208
  • 262
  • Thank you, I weren't aware of CRTM existence on BeagleBone Black. I'll read about it, but if it is as you say, and I have no reason to doubt it, it answers by question perfectly. Also I am aware of the fact that "something" is SHA-1, it is just that I weren't sure if it is always the same, I supposed that maybe there are other TPMs using different hashes. – Jędrzej Dudkiewicz Aug 05 '19 at 06:28
  • @JędrzejDudkiewicz I don't know if BeagleBone Black has a CRTM. If it doesn't, you can surely replace the firmware chip with one that supports hardware write-blocking to implement one. But generally, if something supports SRTM for a TPM, there will be some protection mechanism in place for the BIOS. – forest Aug 05 '19 at 06:29
  • Oh, okay, that explains why I have problems finding anything about it :) But I just thought that maybe it is named differently on BBB. I don't think I can replace any chips on board as we have few hundred Beagles in the field and there will be couple hundred more before I finish implementing this solution. But maybe our hardware guys will think of something else. Thanks again for your comments, they are more appreciated. – Jędrzej Dudkiewicz Aug 05 '19 at 06:34
  • @JędrzejDudkiewicz Try to find out the precise model of the BIOS chip and look its datasheet up. You'll be able to see if it has the ability to mark a region, like the bootblock, read-only. – forest Aug 05 '19 at 06:38
  • @JędrzejDudkiewicz I think this might be what you want to read: https://casualhacking.io/blog/2013/2/11/embedded-trust-p2-u-boot-secured-boot.html. In a comment, it's explained that the BeagleBone has a writable BIOS (including the would-be CRTM region), so it explains how to implement one yourself. It also describes the caveats. – forest Aug 05 '19 at 07:13
  • This fragment "In the case of the Beagle, since the CRTM starts with normally-RW code (the MLO), we have to be crafty. This is not ideal, nor how a CRTM should be implemented. But, by write protecting the SD card physically then we create a CRTM. Remember our attack surface is software only!" Suggests that I were basically right in my understanding. It also seems that MLO (/SPL?) can't be treated as *real* CRTM. Oh well, maybe it can be implemented by adding some external chip that works in RW mode and basically reinitialises TPM - I don't know, "we have to be crafty" indeed... – Jędrzej Dudkiewicz Aug 05 '19 at 08:36