Barnali
Posts: 2
Joined: Tue Nov 13, 2018 11:07 am

Security

Tue Nov 13, 2018 11:15 am

Is there any way to secure the sd card in the raspberry pi. Suppose I dont want to use keyboard for entering the password, then how can i protect the contents of my sd card

nobbit
Posts: 121
Joined: Sun Sep 25, 2011 5:51 pm

Re: Security

Tue Nov 13, 2018 1:21 pm

Do you mean that your SD card is encrypted and you don't want to type a code when booting? What do you want to protect it *from*? Someone who may access your Pi remotely, or someone with physical access to your Pi?

Barnali
Posts: 2
Joined: Tue Nov 13, 2018 11:07 am

Re: Security

Wed Nov 14, 2018 8:43 am

Actually I am doing one project based on raspberry pi , so i need to take care the person remiving the sd card from raspberry pi cannot access the contents of it.

Heater
Posts: 14453
Joined: Tue Jul 17, 2012 3:02 pm

Re: Security

Wed Nov 14, 2018 1:55 pm

In order to stop the person with your SD card from being able to read it you will need to encrypt the file system or at least the code and data you want to keep secret.

In order for the encrypted code on that SD card to be runnable when the Pi boots up the Pi will need to know the decryption key.

But there is nowhere to store a decryption key on a Pi without SD card or other media attached.

Ergo what you want to do cannot be done.

Potentially you could store the key on a USB stick or other "dongle". But now you have to stop the user getting access to that dongle as well.
Last edited by Heater on Wed Nov 14, 2018 2:26 pm, edited 2 times in total.
Memory in C++ is a leaky abstraction .

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 24971
Joined: Sat Jul 30, 2011 7:41 pm

Re: Security

Wed Nov 14, 2018 2:18 pm

You could glue a encryption dongle in to one of the USB slots. Not fool proof, but perhaps good enough. Although not sure if such a thing exists, so perhaps permanently attach a crypto chip to the GPIO's?

https://www.microchip.com/design-center ... entication
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I own the world’s worst thesaurus. Not only is it awful, it’s awful."

User avatar
Joel_Mckay
Posts: 293
Joined: Mon Nov 12, 2012 10:22 pm
Contact: Website

Re: Security

Wed Nov 14, 2018 3:09 pm

There are ways of securing Broadcom ARM chips with DRM style protected memory/boot, but the version that ships with the pi is not enabled for obvious reasons.

LUKS Encryption also slows down everything, and on a resource limited system will be very noticeable.
You can encrypt the root mount too, but the program contents are already shared by hundreds of thousands of users.... so doesn't really make sense.
There are also trade-offs with using a shared key for allowing access to every user of a system, and so a single user home (and external disk key) per partition mount is usually the way to go. Some users will even mount a local file as a disk for a portable LUKS based system, but that is silly due to various duplicates of a file in cache.
One must use a one-time key system for the swap partition, and be mindful of services that index files for "find" or logs etc.

Recently, ext4 partitions added support for native user-level file encryption, but it is a method that can't be considered stable across the *nix ecosystem.

Some use an NFS to mount a remote resource, have a physical tamper detection circuit in the enclosure, and avoid the local access issues altogether.

And finally, public key systems like gpg by design allow one to compress local files into an encrypted state without knowing the private key. Unfortunately, this usually still leaves bits of the file in swap file memory and on other areas of unencrypted disks where the file was initially created.

So in conclusion:
1. check the signature of your boot area kernel files to detect alteration (not really possible on Pi)
2. check the signatures of fast-access area of unencrypted root application files (any changes to the binaries?)
3. use one-time key encrypted swaps
4. locally decrypt device and user specific disk mounts using external key/resources off an NFS
5. ...
6. login to account to use file level encryption
7. read XKCD to understand why none of this matters: https://www.xkcd.com/538/

If you are designing a product, than you should focus on DRM systems like the one Nintendo chose:
https://www.nvidia.com/object/tegra-superchip.html

Personally, I buy things that don't have these DRM features for obvious reasons, as it is essentially a factory deployed root-kit with zero accountability (see Intel management engine for details).

Best of luck, ;-)
~J~

User avatar
sakaki
Posts: 466
Joined: Sun Jul 16, 2017 1:11 pm

Re: Security

Wed Nov 14, 2018 3:28 pm

Barnali,

it's not completely clear what your threat model is here, but without an integrated hardware root of trust, nor any secure non-volatile storage for keys, a baseline RPi3 won't let you do what you (probably) want.

If you search on these forums you can find many posts about ways to at least partially encrypt microSD cards. Problem is that you will generally be relying on an unauthenticated kernel + initramfs booted from the non-encrypted first partition to unlock the remainder. If you don't want to enter the (LUKS or similar) passphrase via keyboard, this too will then have to be stored on the non-encrypted part of the drive. Tricks like pulling an encrypted key across the net at boot time still fail transitively to this issue.

If you were willing to add hardware to address this, then Zymbit have a plug-in root-of-trust module. Not one I have tried (breaking into ^-^) personally, but for completeness here is a link about setting up an encrypted root:
https://community.zymbit.com/t/encrypt- ... -crypt/150

Note thought that this isn't (I think) a full verified boot solution - the module doesn't validate the original kernel + initramfs, which are stored (necessarily) in unencrypted form, but it does provide encrypted key storage that is tied to the underlying (RPi3) hardware instance. Why is that an issue? Well, once the system is booted, a compromised kernel has access to the underlying LUKS master key and could exfiltrate it, on a network etc. But, this approach may still be useful, depending on your threat model:

Image
Image

Another option, if you were willing to boot from USB rather than microSD card, would be one of those 'USB with integrated keypad' drives. Example:
Image

The particular device above (ref on Amazon) requires you to type in the passcode before inserting the drive, which makes things easier.

However, if you need to use (and possibly hard power cycle) in an unattended context, the above integrated-keypad-USB idea will not be useful.

The advantage of it though is that even the boot partition would stay encrypted until you enter the passcode and plugged it in. Therefore, the boot partition would remain protected (at rest).

Good luck,

sakaki

ejolson
Posts: 4273
Joined: Tue Mar 18, 2014 11:47 am

Re: Security

Wed Nov 14, 2018 3:54 pm

Barnali wrote:
Tue Nov 13, 2018 11:15 am
Is there any way to secure the sd card in the raspberry pi. Suppose I dont want to use keyboard for entering the password, then how can i protect the contents of my sd card
Put the Pi in a lockbox or a safe (depending on the security needed) and drill holes for the wires. This will prevent unauthorized physical access. Thus, no performance slowing encryption would be necessary.

User avatar
sakaki
Posts: 466
Joined: Sun Jul 16, 2017 1:11 pm

Re: Security

Wed Nov 14, 2018 5:27 pm

ejolson wrote:
Wed Nov 14, 2018 3:54 pm
Barnali wrote:
Tue Nov 13, 2018 11:15 am
Is there any way to secure the sd card in the raspberry pi. Suppose I dont want to use keyboard for entering the password, then how can i protect the contents of my sd card
Put the Pi in a lockbox or a safe (depending on the security needed) and drill holes for the wires. This will prevent unauthorized physical access. Thus, no performance slowing encryption would be necessary.
This makes very good sense actually, unless the OP's comment:
Barnali wrote:
Wed Nov 14, 2018 8:43 am
[...] i need to take care the person remiving the sd card from raspberry pi cannot access the contents of it.
was meant to imply e.g. that the microSD card in question needs to be transferred by an untrusted third party between locations etc.

At this stage we're all just guessing ^-^ The OP needs to clarify the threat model, or give some further details about the intended use case.

best, sakaki

Return to “General discussion”