txumino Posted February 16, 2017 Posted February 16, 2017 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.
zador.blood.stained Posted February 17, 2017 Posted February 17, 2017 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.
Marco_ Posted March 22, 2017 Posted March 22, 2017 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
jernej Posted March 22, 2017 Posted March 22, 2017 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.
zador.blood.stained Posted March 22, 2017 Posted March 22, 2017 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.
jernej Posted March 22, 2017 Posted March 22, 2017 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.
Marco_ Posted March 23, 2017 Posted March 23, 2017 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
Recommended Posts