Good morning, first of all sorry for my English, I'm not native and I use a translator.

 

 

I'm working on a project with the orange pi plus 2e and I need to protect the internal memory emmc, I installed in emmc "ARMBIAN 5.25 stable Debian GNU / Linux 8 (jessie) 3.4.113-sun8i" and I ask myself the following:
 

How can I protect the internal memory so that it is not accessible by inserting an SD card and mounting the emmc partition?


That is, I give my client the orange pi configured and no sd card inserted, starts with emmc, but if someone inserts an sd card with any image for this card can mount the internal partition and access the contents.


I've looked at encryption options but I do not really know how to encrypt emmc and start it automatically, I think this is the best option, but I've seen this post and I do not know if I could fix it with something like this: https://forum.armbian.com/index.php/topic/1702-orange-pi-plus-2e-where-is-16ghz-and-sd/?p=13163

 

 

Thanks.

Any ideas?

You won't be able to protect eMMC reliably enough without physically disabling / limiting access to the SD slot, FEL button and microUSB port. Encryption won't help against an experienced user since you need to store encryption keys on the same media as encrypted filesystem.

I have a similar problem, i need to encrypt eMMC on Orange PI PC+ for preventing copying/reverse engineering of my software. I have read a bunch of docs about LUKS and keyfile-based encrypting,a but I have no idea about how to implement it in the PI. The keyfile must possibly be written in the eMMC, and the boot must be automatic at each power cycle, without user intervention. Does anyone have suggestions?

 

many thanks in advance,

Marco

Nothing readily available. Fortunatelly for you, there was some advancement in understanding secure boot last month (discussed on IRC and described on linux-sunxi wiki), but IIRC only for running signed images as opposed to encrpyted, which means that with proper knowledge eMMC can be resoldered to different board and dumped.

 

As zador already said, saving key on same media as encrypted data is never a good idea. In this case, it would be best to save key in one time programmable memory located inside H3 (SID) and use secure boot at the same time, so only properly signed image can read decryption key. But there might be HW bug which makes bypass possible. Most knowledgeable people about this topic can be found on IRC #linux-sunxi at freenode.net. Please ask them for any definitive answers.

1 hour ago, jernej said:

As zador already said, saving key on same media as encrypted data is never a good idea. In this case, it would be best to save key in one time programmable memory located inside H3 (SID) and use secure boot at the same time, so only properly signed image can read decryption key. But there might be HW bug which makes bypass possible. Most knowledgeable people about this topic can be found on IRC #linux-sunxi at freenode.net. Please ask them for any definitive answers.

Again, it's too early to say that it (secure mode) is ready for the end users. Programming efuses is a non-reversible operation (at least with currently available info) so it may brick the device if not done properly (i.e. if wrong hash was flashed). If I understand it correctly, current bypassing technique was tested with secure bit set but with certificate hash not programmed, so it may still be a feature and not a bug.

5 minutes ago, zador.blood.stained said:

Again, it's too early to say that it (secure mode) is ready for the end users.

 

Yes, it is in very early stage. I will be more clear next time.

Thank you guys, actually i'm working on luks encryption method + dracut-gmcrypt, i trying to use a key generated from mac address of pi, but actually the biggest problem is to luks a existing image system on pi...i have found this  for luks in place conversion, but i give a segmentation fault during the encryption progress and nothing works