0

I have spent a lot of time on researching on this topic but I haven't found any working solution for my problem respectively I'm not clear about some points.

My goal is to distribute a encrypted/copy-protected Raspberry Pi LAMP server (for offline/local network use only) to my clients.

It should not be possible to copy the system so the question is, how can I make the project safe against manipulation and copying?

I thought about these options:

  1. LUKS and TPM (and TrustedGrub/secure boot?). Is it possible to copy/clone a TPM chip and the content of the SD card to break the protection? Are there any ready-to-use Pi modules for this method?

  2. LUKS and YubiKey NEO - Is it possible to use the key just to store the decryption key without two factor so the device can start itself?

  3. OpenPGP smartcard? Could this solve my problem to store encryption keys and copy protection? Is it possible to clone the OpenPGP cards, and/or what about the newer USB version?


What about cryptocape for BeagleBone? Is this an example that I would need? If true, does something like this exist for Raspberry?

Any other ideas?

The goal is clearly that no one should be able to access the filesystem of this device to modify or leak content.

Even if I find a working scheme, what about protection against evil maid attack regarding the open/boot on LUKS?

Finally, how to protect the device from people making a RAM dump and capturing the decryption keys? Is any implementation or method available that doesn't store the keys in RAM? Is a good epoxy on the RAM maybe the only solution for this issue?

I will be really happy for help on this.

There is no need to speak about other attack vectors like weak SSH passwords, SQL injection or another other stuff.

1

As a security researcher that normally breaks secure systems that's quite an interesting question. You basically want DRM on a system that someone is in physical possession of. You have to let your client read the data and by the nature of doing so give them a vector to copy it.

For the vast majority of end users you can glue in a Yubikey with a decryption password for the SD card. That gives you an avenue for updates. As for potting or using epoxy on the RAM, if someone of that skill is trying to copy your data you're not going to stop them with a bit of epoxy or glue. You can put it in an armored box completely potted except for heat pipes for the chips and someone will still defeat those measures if they're determined.

So for the practical advice, use the Yubikey to boot that's glued in and have a lawyer draw up a nice NDA with provisions for reverse engineering and removing data outside of it's defined use. There's nothing like legal liability that will stop many companies in their tracks. If someone is going to covertly do it and they have the skill to extract data from chips and data busses, they'll do it anyway. The lowest hanging fruit is just to expose and tap the serial data on the USB bus to snag the key. The other is to just scrape the webserver with scripts.

I'd host the device in my control and use 2 factor authentication with a token I give them to gain access over the net. Then at least you can monitor logs for activity that indicates web scraping.

| improve this answer | |
  • The keys have to be stored in ram to decrypt the drive on the fly. There are high security drives with encryption hardware built in, but they're not cheap and made for DoD/Gov use. The reverse of what you said is true. If the system is off and the data is encrypted at rest it's a much more difficult task to get the contents than when the system is online and has to be decrypting the data. The Yubikey's are quite flexible and you can configure them with software the company has for download. I use them all the time myself. – Brandon Mar 27 '16 at 21:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.