How to fuse LUKS encryption key into the SoC?

[pielgrzym]

I'm struggling to find this in documentation - I'd like to fuse the root partition key into the SoC? I'm thinking about such process:

1. SoC verifies u-boot

2. SoC verifies kernel image

3a. SoC uses internally fused key to unlock rootfs.

3b. SoC uses verity to check rootfs (I assume this either is impossible or possible only after unlocking rootfs?)

4. Boot starts

Now, assuming the rootfs has a small attack surface (ssh only for example) the simple way to attack this setup is to hook into JTAG and somehow read the encryption key from memory? Is there a way to disable JTAG or at least damage the board to make JTAG unusable?

I've read in other thread that one could configure u-boot to launch serial console or TCP/IP stack to obtain the key from the user. Both methods would probably work, but:

a) serial would require to have a special connecting software on each platform from which we want to connect to usb armory (so basicaly this is sensible only on couple of trusted machines)

b) TCP/IP connection also is not setup free - heavily dependable on host system and usually requires administrative access

Ideal way would be to configure u-boot to always launch as usb storage (the easy part), but using an image in RAM (instead of mmc card). Then: user plugs armory, a storage drive appears, the user copies a file to the storage, u-boot checks for filename or some other detail and uses the file as a key to unlock rootfs. The storage image in ram is obliterated and normal boot procedes. Looking at my utter struggle to make u-boot not crash with TrustZone enabled qemu makes me think that coding abovementioned functionality would be a huge project though.

[Chris Kuethe]

You can disable JTAG if you like or you can just lock it with a
challenge-response code. Section 67.7 of the reference manual, for
anyone who's curious about the controls available. The internally
fused, per-SoC key cannot be read out via JTAG or software.

Random thoughts:
- patched u-boot can probably configure trustzone to protect the fuse array.
- patched u-boot can probably virtualize the sdcard and transparently
encrypt it.
- Doesn't verity just present a signed, immutable filesystem? You
could use that to store some trusted luks/dm utilities which are then
used to decrypt and mount the real filesystem.
- You can probably package a kernel, device tree, boot args, and an
initrd into a FIT blob that uboot can verify.

> --
> You received this message because you are subscribed to the Google Groups
> "USB armory" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to usbarmory+...@googlegroups.com.
> To post to this group, send email to usba...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/usbarmory/665566bc-bd7a-40ee-a76c-d3e6c7c70e8c%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
GDB has a 'break' feature; why doesn't it have 'fix' too?

[Andrea Barisani]

Fusing private/secret keys on the SoC is never a good idea, even if JTAG can be disabled and code can be secure booted ideally you would prompt for those keys at boot.

If you really want to use a built-in key the i.MX53 has a built-in unique symmetric encryption key fused in the SCC that can be used for the task, this key cannot be requested and/or extracted and only the SCC can use it.

We prefer to prompt for the key at boot and it is our goal to have TrustZone code doing that in the long term. I disagree on b), so far we can smoothly connect to Linux, Windows and OSX with a dhcp server on the USB armory without too many issues, this is my preferred communication method at this time.

Of course other more elaborate mechanisms can be used, as you describe, for more compatibility, however does requires custom implementation.

Cheers

 

[pielgrzym]

On Sunday, May 10, 2015 at 1:20:40 AM UTC+2, Chris wrote:

You can disable JTAG if you like or you can just lock it with a
challenge-response code. Section 67.7 of the reference manual, for
anyone who's curious about the controls available. The internally
fused, per-SoC key cannot be read out via JTAG or software.

This is great news :)

 

Random thoughts:
- patched u-boot can probably configure trustzone to protect the fuse array.

Fuse array it fuse bank 3 referenced in Chapter 42 of reference manual? One of those arrays contains some settings to prevent JTAG access to keys etc. Could you point me to the right direction if I'm wrong now?

 

- patched u-boot can probably virtualize the sdcard and transparently
encrypt it.
- Doesn't verity just present a signed, immutable filesystem? You
could use that to store some trusted luks/dm utilities which are then
used to decrypt and mount the real filesystem.

This is fine as long as we use the unencrypted system solely as a gateway to encrypted partition. If we are doing other stuff there it might leak some forensics data via the unencrypted part (say, a bitcoin wallet that is caching some stuff outside it's defined settings dir - before each update one should check with lsof or other utility how an app behaves - a pretty error prone stuff).

 

- You can probably package a kernel, device tree, boot args, and an
initrd into a FIT blob that uboot can verify.

Yeah, I thought about this when I saw this tutorial: http://www.denx-cs.de/doku/?q=m28verifiedboot

Unfortunately I'm stuck on u-boot crashing or getting stuck in a loop in my Qemu setup :( 

[pielgrzym]

On Sunday, May 10, 2015 at 9:50:25 AM UTC+2, Andrea Barisani wrote:

Fusing private/secret keys on the SoC is never a good idea, even if JTAG can be disabled and code can be secure booted ideally you would prompt for those keys at boot.

Could you elaborate about attack scenarios? I'm a SoC/Arm noob, totally intimidated by 5000+ pages reference manual ;) 

So I guess there is a relatively easy way do retrieve those keys from the device? Like using the omnipotent SRK to look them up in the internal bootloader?

  

If you really want to use a built-in key the i.MX53 has a built-in unique symmetric encryption key fused in the SCC that can be used for the task, this key cannot be requested and/or extracted and only the SCC can use it.

Is there a ready linux module for doing that? 

 

We prefer to prompt for the key at boot and it is our goal to have TrustZone code doing that in the long term. I disagree on b), so far we can smoothly connect to Linux, Windows and OSX with a dhcp server on the USB armory without too many issues, this is my preferred communication method at this time.

The ethernet connection method is fine (it will definitely work everywhere - and I'm happily using it now), but almost (?) always requires to set up a manual interface address for usbarmory. And it would be an overkill to spawn a dropbear ssh to input the luks key (every machine that hosts usbarmory would have to have an ssh client, it's more likely to get caught by a keylogger - unlike putting inconspicuous jpg file on some usb storage - inconspicuous from malware's perspective that is).

[pielgrzym]

Ah, sorry - missed the dhcp part. Checking dhcp behavior right now :)

[pielgrzym]

This indeed eliminates a lot of hassle and is pretty intuitive :) actually it's much less hassle to type the password then to find the key file you need to put on the storage.

I'm thinking now of such scenario - we have a super-thin, read only distro - started with veritized everything - say a Void Linux (we want to save most space and have least complexity). Rootfs Void Linux starts a modified version of Interlock - by providing a password we unlock the LUKS volume and run a script that chroots inside the volume to start additional services like BTC wallet, some GPG/HSM or password manager.

My main aim here is to create USBarmory password manager:

1. after unlocking the device pass-daemon starts - it uses pass for backend operations (http://www.passwordstore.org/ - gpg based pw manager).

2. the pass-daemon exposes additional web service - the web service is responsible for:

a) receiving the name of the password file we want to retrieve

b) inserting new passwords

3. Chrome/FF extension 1Password-like extension uppon prompting for password completion on given site queries the pass-daemon service

4. pass-daemon service matches the proper password with gpg file

5. pass-daemon is waiting for the GPIO-attached button to be pressed

6. when user presses the GPIO-attached button, the pass-daemon decrypts the credentials

7. pass-daemon initializes a hid keyboard attached to the host and starts typing in the password.

8. the button works for the last used website for a given period of time so we can easily trigger-password retyping just by pressing the button

Other advantage: the chrooted safe-system could have a cronjob that automatically backs up password store, say, to s3 (with additional encryption), etc. And we could implement other fun stuff - a rogue hid device that attacks the host if interlock receives wrong password N times etc ;)

[Andrea Barisani]

On Sunday, May 10, 2015 at 1:05:49 PM UTC+2, pielgrzym wrote:

On Sunday, May 10, 2015 at 9:50:25 AM UTC+2, Andrea Barisani wrote:

Fusing private/secret keys on the SoC is never a good idea, even if JTAG can be disabled and code can be secure booted ideally you would prompt for those keys at boot.

Could you elaborate about attack scenarios? I'm a SoC/Arm noob, totally intimidated by 5000+ pages reference manual ;) 

So I guess there is a relatively easy way do retrieve those keys from the device? Like using the omnipotent SRK to look them up in the internal bootloader?

The SCC key cannot be extracted nor modified, there are some general purpose GPIOs where you could theoretically put your own key there, however those can be trivially read by code unless you are secure booting code that never allows that to happen (and that has no exploitable vulnerabilities for doing that of course). Such code must of course disable any external means of access and/or debugging such as JTAG.

 

  

If you really want to use a built-in key the i.MX53 has a built-in unique symmetric encryption key fused in the SCC that can be used for the task, this key cannot be requested and/or extracted and only the SCC can use it.

Is there a ready linux module for doing that? 

 

The Freescale BSP 2.6 Linux kernel has support for the SCC (linux-2.6.35/drivers/mxc/security/mxc_scc.c), that would need to be ported to modern kernels. We hope to be able to get Genode to use the SCC for microSD encryption within TrustZone later this year. This way we can put Linux in the normal world and avoid having it handling microSD encryption/decryption at all. However we want to supplement the built-in SCC key with a user passphrase. This way not only the microSD can be decrypted only by the owner of a specific armory but that can also happen on that specific armory board only.

 

We prefer to prompt for the key at boot and it is our goal to have TrustZone code doing that in the long term. I disagree on b), so far we can smoothly connect to Linux, Windows and OSX with a dhcp server on the USB armory without too many issues, this is my preferred communication method at this time.

The ethernet connection method is fine (it will definitely work everywhere - and I'm happily using it now), but almost (?) always requires to set up a manual interface address for usbarmory. And it would be an overkill to spawn a dropbear ssh to input the luks key (every machine that hosts usbarmory would have to have an ssh client, it's more likely to get caught by a keylogger - unlike putting inconspicuous jpg file on some usb storage - inconspicuous from malware's perspective that is).

 

Again, dhcp as you figured ;)

Also LUKS keys can be disposable making interception irrelevant (INTERLOCK supports this).

Cheers!

[Andrea Barisani]

FYI we just published a new driver for the SCCv2, which allows AES encryption with the built-in unique secret of the SoC.

https://github.com/inversepath/mxc-scc2  

This will be soon integrated in INTERLOCK.

Cheers

[Jakub Nawalaniec]

Very cool!