Hardware Root Of Trust / Full Disk Encryption

[lele]

Hi I could not find a link to this topic but I need to have full disk encryption in my application with an Odroid M1 (Any Linux but preferably Ubuntu or Debian) and the eMMC should be encrypted and unlocked at boot.

ARMv8 supports TrustZone I think. Is this implemented in any of the Linux images for Odroid M1? If not CAN it be implemented?

Again sorry if I this was already asked and I missed it.


Thanks!

[lele]

Alternatively, is there a way to access an EEPROM on the board to store some data there?

[fvolk]

There are small boards with a TPM with a connector that attaches to the SPI pins on a RPi - and they work well.

Maybe one such board can also be attached to an M1(S) (and C4?) - if Odroid helps with the SPI routing from RPi connector to Odroid GPIO and the proper dtb changes....?

[fvolk]

Looks like this.

Maybe Hardkernel's business customers would like to have a similar option for security conscious applications?
Hardkernel could actually patch the bootloader for a hardened boot and then FDE of rootfs?

tpm_pi.jpg (61.08 KiB) Viewed 465 times

[mctom]

Looks like it uses SPI CS1 pin which isn't available on M1 at all.
Otherwise the SPI and power pinout is the same as on RasPis.

[tobetter]

I've tested earlier but not much progress...but technically SPI based TPM can work on top of ODROID-M1.


In case the Linux kernel blob are not required to be encrypted, Netboot Installer from Petitboot can help to encrypt the root file system while installing the OS.
viewtopic.php?p=349824#p349824

[lele]

Hi Thanks a lot for all the answers!

My requirements are a little different though. Full disk encryption is great but it would not work for me if somebody needs to enter a password at each boot, i.e. the disk should unlock itself automatically when connected to the designated Odroid M1 since this server is completely headless.

Imagine this.
- I need to deploy a server that requires root access via SSH but it's well protected with a strong password so brute force attacks via Ethernet will not work.
- Then somebody has physical access to the server, opens it, removes the eMMC and mounts it on a different Odroid M1 for which they have root access. At this point they can modify the ~/.ssh/known_hosts file to add RSA credentials of a different machine and setup password less ssh login.
- Then they re-insert the eMMC, boot the system, connect to the network and they will have root access to the machine which is a huge problem.

While I fully understand that protecting a machine where an attacker has physical access to the hardware is nearly impossible (especially once you start attacking RAM etc) we need to at least make it not as trivial as this.

So what I was thinking is:
1. The root drive should be encrypted and I should be able to store a hashed password somewhere on the board (SPI storage, EEPROM etc). This way if someone removes the eMMC drive they won’t be able to mount it anywhere.
2. The boot process should retrieve this key and unlock the drive at boot automatically

This is still not completely “secure” since somebody could in principle download the boot partition, reverse engineer it, see where it gets the key and use that key to unlock the drive on a different machine but it's miles better than the original case and certainly not trivial. That level of security would be enough for me at this moment.



Any ideas on how to achieve this without reinventing the wheel?

Thanks a lot

[mad_ady]

This is a sensitive subject because there are many ways it could go wrong. Basically you want encryption, but want to ship it with the key hidden in the flower pot, next to the front door. Sure, it's better than leaving the front door open, but it keeps only honest people out.

I was about to suggest using a yubi-key to store the secret (https://www.endpointdev.com/blog/2022/0 ... n-yubikey/), but if you leave it in, an attacker can use it to unlock the disk.
An alternative would be to use some unique board-specific information, like eth0 mac address, or /etc/machine-id. The attacker would need to extract it from the hardware, once they understand where it is stored (it buys you 30 min/1 hour). Maybe obfuscate the script that extracts the secret, so it takes longer (e.g. big C program that opens lots of stuff, reads from random parts of the disk, does some key based crypto, is stripped, obfuscated, run through upx, but in the end uses up just one tiny bit of information).

But what's stopping the attacker from modifying the initramfs (where this code would run) and mounting an external storage to pipe/tee the calculated secret into a file?

Now we're getting paranoid! The big C program should validate the boot chain before outputting the key - Run md5sums on all files in initramfs and comparing them to known values. If check fails, output a wrong key. But what prevents the attacker from bind-mounting the original files on top of the modified ones?

See? Rabbit holes within rabbit holes...

There's one more thing. In theory you could store the key inside the SPI flash memory at some offset, but SPI flash shares some data lines with EMMC snd both can't be run at the same time. Once kernel/initrd are loaded into memory, you'd need to do the same trick petitboot does and disable emmc, enable spi, read the secret, disable spi, enable emmc.

[mctom]

Yeah, that's the point of the saying that when the attacker gets access to hardware there's no way stopping them.

One thing I could come up with is some sort of self-destructing thing once the case is opened. If you can afford replacing M1 on unsuccessful attack.
Personally I think that stealing the whole M1 is more likely than stealing mass storage from it. Especially if you crazy glue it.

Other than that, is to rethink your system so you don't need root access to M1 in the first place.

[fvolk]

How its done on PC:
BIOS firmware is signed (e.g. https://en.wikipedia.org/wiki/Intel_vPro#IBG), meaning manufacturer/BIOS vendor has to be trusted.
This initial firmware (=root of trust) is the anchor for a chain of trust, meaning a measurement chain that hashes up all boot components as they are executed.
(roughly: BIOS -> extension cards firmware -> bootloader -> kernel image -> kernel config -> initrams -> rootfs)
The same, unmodified software, measured/hashed in the same order, therefore accumulates into the same hash value.
So this hash value can be used as a passcode.
You have a key that is used for full-disk encryption of the rootfs.
Bind the key to a TPM, set hash value as key secret, TPM is soldered to the platform.
Only with the correct passcode the TPM releases then the rootfs key,
and the passcode cannot be brute forced from the TPM - either you know it or you don't.
See further: UEFI Secure Boot plus TPM requirement introduced with Windows 11 and a TPM key used for Bitlocker FDE.

For a SBC scenario:
TPM can be attached via SPI, rootfs FDE key can be bound to TPM.
Tricky thing is how to build a measurements chain of software involved in boot on ARM due to the many different vendors.
People have already added TPM support to u-boot: https://bootlin.com/blog/measured-boot- ... in-u-boot/
What needs to be provided by the vendor is a robust root of trust and measurements chain before u-boot:
BL1 -> BL2 -> BL31 -> BL33/U-Boot ... as described in the article.
Hardkernel would have to ask Rockchip/Amlogic how to do that...
(but some business customers would surely like that if an Odroid is deployed into the field,
rootfs is encrypted and if boot software is tampered with it no longer boots)

Not perfect, but good enough for many scenarios.

HTH

[lele]

Thanks for all the answers!

Yes definitely understand it's not properly secure but it's still miles better than now, i.e. no encryption at all. Right now somebody with access to the disk can just remove the eMMC, mount it and modify whatever they want, which is not acceptable.

My question is if I need to recompile the M1 boot from source or if I can use existing tools. I have never recompiled boot/kernel so considering how sensitive that is I would rather a simpler option if it exists.

In case I need to recompile the kernel/boot can anybody point me to the right direction?

Thanks again!

[mad_ady]

If you go with my initrd unlock trick you don't need to compile kernel/uboot, only repackage initrd and add your unlock logic to decrypt and mount the rootfs.

If I were you, I'd install one of tobetter's builds, enable full disk encryption in the installer, create a separate boot partition to hold kernel/initrd (unencrypted), test that it works with manual unlocking, then start poking the initrd and adding custom unlock code. Note that various updates will want to overwrite your initrd!

[lele]

Thanks a lot @mad_ady, I'll need to look more into this.

I think this should go into the default Odroid image eventually. Most of us are using these modules for embedded products (e.g. commercial, advertising, monitoring, etc) and need to deploy something that reliably boots on its own and it's reasonably protected against somebody taking it apart and looking inside. Won't be bulletproof of course but should be enough to discourage people with an average knowledge in computers.

thanks!

[mad_ady]

The difficulty in releasing such a solution by the community is that it exposes wide open the way the keys are stored/validated, so it doesn't offer the one thing a custom solution built by you would - security by obscurity (which we all know is bad).
But doing something behind closed doors gives you some chances of success, and may reduce the visibility of attack vectors.

Anyway, to tinker, I suggest you use a serial console, and start by adding "echo" messages to existing scripts, to understand what they do.

If you'll go with a compiled/compressed/obfuscated binary, make sure you strip it, and also run it through strace, to see if "spills the beans" on what it does...

Perhaps the community could release instructions on how to insert a hardcoded/static key in the boot scripts, and allow you to unlock rootfs...

Good luck!

Edit: this should get you started: https://www.baeldung.com/linux/bash-obfuscate-script