Hi,

 

I am using Nano Pi Duo2 (Allwinner H3) with latest Armbian OS.

 

My goal is to have all the OS and Data on SD Card Encrypted. It should be secure from hacks.

 

In Developer Guide, LUKS encrypted rootfs needs a key to unlock. In our case we want the device to unlock itself so key has to be stored on the Allwinner H3 securely.

Has anybody implemented it on Allwinner H3 ?

Is there alternative solution to secure the data on the device.

I hate to be the pedantic one here, but full SD card encryption is not generally possible. There's typically a boot partition that contains at least the kernel, initramfs, and DTB that's typically unencrypted.

 

I've seen ARM CPUs that have signing keys used to authenticate these files so they are resistant to modification. Perhaps that is what you're referring to? They are generally asymmetric keys, which are burned to the CPU, but work substantially differently than the symmetric keys used in LUKS. They verify authenticity, rather than provide confidentiality. (Light Reading)

 

You would then need to verify if your root filesystem has been modified, before passing the chain of trust to secure boot. All your kernel modules would also need to be signed. You'd probably be rolling your own kernel rather than using the Armbian provided one.

 

Note that encrypted data is only secure when the data and key are separated. The second it's keyed, you're one OpenSSH zero-day vulnerability away from losing everything that's on it. If it boots by itself, or its online all the time, you've bought yourself exactly zero security for all that work.

 

Cryptography is an interesting, but rather deep and detail oriented subject. If you're indeed looking to do this, you'll need to do some more reading on how best to set your system up. It may be easiest to make an encrypted folder with EncFS or eCryptFS to keep your important files, and only open those when needed. A LUKS encrypted root filesystem is helpful for other use cases (eg - theft), but not when it boots by itself.

@tparys

Regarding LUKS encryption, Wouldn't it be possible to store the encryption key in ROM which will unlock the Boot which again unlocks the RootFS ?

If it is possible, it's a little like taping the key to your house in the lock of your front door.

 

It will do nothing to prevent you from being hacked.

Not totally true, you can secure the key store inside the chip by burning access to it (via fuses / physical burning of USB OTG), ROM code will be unreadable, Boot code will be encrypted on SD Card. 

 

What do you think ? 

If I know your username/password, if doesn't matter what the encryption key is or where it's stored.

 

Your data is unprotected the second it boots.

@tparys not totally true.

 

Fuses inside the Arm chip are the key to unlock everything.

It is costly effort to hack fuse content. So unless somebody spends > 100K$ + time to unlock the fuse content, your os and code is secure from theft.

On the allwinner you have still a backdoor over fel mode, you can enter in it secure mode from it.

So depends how secure you would like it to have, you can not route this usb if you create your own pcb (still someone could solder it out) or you could burn the fel usb in production like i heard some other do here ( i am still amused by this insane method)

 

Except from the fel backdoor you can burn some keys in the fuses and provide it via u-boot to the kernel (will require own kernel modul for that)

and don't forget to decrypt your u-boot environment and disable u-boot console otherwise its still easy to get into it or boot something else

 

Hi @xeniter

 

Yes! I've been following this thread keenly - 

 

I've chosen burning the USB0 so that FEL mode will never be accessed after initial programming.

Can you tell how were you able to do secure boot of U-BOOT ? 

I was able to do secure boot of SPL as per above thread. The pre toc0 SPL has 24KB size limit. 32KB SPL does not boot. Since only 24KB is available, how did u manage to do secure boot of U-Boot using RSA key verification ? I checked the BROM code has size of 64KB. This is enough to add all the libraries like openssl required for RSA verification of SPL. But that is not the case with SPL. You cannot fit openssl library inside 24KB size.

The plan now is to create multiple hashes of U-BOOT which are cryptographically secure but computed using non cryptographic algorithms like - Murmurhash3,  Siphash and Checksum of U-BOOT. 24KB SPL can do this. SPL then verifies if UBoot is tempered or not. The security of tempering relies that the hash of tempered UBOOT will be different.

What are your thoughts on this ?

security is a fight which most likely always lost, depending on your enemy

you can only increase the effort so its not worth for the opponent to reverse or break into your data.

And the effort you put into that depends how much money/effort you will loose if your opponent made it.

 

So depending on that you have to decide how secure you would like to make your system.

One Example is hash u-boot and verify its hash. This could be sha1 for example if you trust it now (afak first collision atacks were already made)  and long enough in the future to get not cracked soon.

(Depending you assume its not already cracked or can be easily calculated with a new quantum computer... as i said always lost... depends only who is your opponent and how much effort/money they are willing to spend on it)

 

if you don't trust a hash enough i have at least no other idea for now how to protect or verify u-boot from spl

In that case its better to switch the processor where you get more insights or documentation and a better chain of trust support.