0

I have a kind-of-raspberries park, all connected via VPN to a single one server. I'd like to encrypt each rasp', in order to avoid intrusions, if one is stolen.

Each rasp' has already a system installed (Mint, debian-based).

What would be the best encryption tool to use ?

The rasp is connected by VPN to the server. Each rasp store some data, got through VPN from the server. Once these data are on the rasp disk, there are encrypted. Once a user connect the rasp - wifi - , s/he can download decrypted media. But such media are unreadable if you steal and read the HDD. Oh, and the wifi is password free -- yes I know it's weird!

Little schema:

http://www.developpez.net/forums/attachments/p180700d1434444153/systemes/linux/securite/crypter-disque-meilleure-solution/aka.png/

Jeff Schaller
  • 66,199
  • 35
  • 114
  • 250
ArchiT3K
  • 576
  • 1
  • 8
  • 34
  • Will there be someone at the keyboard of each rasp' to enter the decryption passphrase when it boots? – Celada Jun 16 '15 at 07:34
  • Hi Celada, there wont, unless the rasp' is stolen and the box/container broken (the rasp' is inside) in order to access Usb & VGA inputs. It should boot without entering anything. We plan to create a Usb dongle for it. Only one Usb (or SD card - better - ) input for the dongle. – ArchiT3K Jun 16 '15 at 07:39
  • In that case, can you elaborate on how encrypting each rasp' would avoid "intrusions"? What exactly would be encrypted and how will it get decrypted? – Celada Jun 16 '15 at 07:51
  • Thank you. The whole disk would be encrypted. That's my idea. As a very noob, I dont even know how/if it is possible, and what it involves in term of performances. – ArchiT3K Jun 16 '15 at 08:02
  • 2
    Sure, it's possible to encrypt the disk but the important question is who's gonna decrypt it. – Celada Jun 16 '15 at 08:03
  • Thanks Celada. The rasp is used as a hotspot wifi, the local audience can connect to the rasp (wifi, captive portal). The audience has access to : 1. local website ; 2. local media for download. I guess these 2 need decrpytion before delivery. – ArchiT3K Jun 16 '15 at 08:07
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/24862/discussion-between-celada-and-archit3k). – Celada Jun 16 '15 at 08:08
  • Oh yes thks. but i can't. Not enough reputation... :/ Be sure I dont aim to crypt network trafic. The rasp is connected by VPN to the server. Each rasp store some data, got through VPN from the server. Once these data are on the rasp disk, there are encrypted. Once a user connect the rasp - wifi - , s/he can download decrypted media. But such media are unreadable if you steal and read the HDD. Oh, and the wifi is password free... yes I know it's weird. A kind of secret proj // Thank you for your replies. – ArchiT3K Jun 16 '15 at 08:09
  • Please update your question to reflect that information. It seems like you will not want to encrypt the whole disk, but only the media that comes from the server. The problem is that it sounds like, while you could prevent someone from getting the data with an encrypted disk, it would be difficult to prevent an intruder from simply obtaining the data through the VPN from the server, the same way that the rasp' did in the first place. – Celada Jun 16 '15 at 08:17
  • Thanks. You're right. One can mimic a rasp for getting file from the central server. Ab-so-lu-tly. And that's why I'd like to encrypt the whole disk. To hide, also, the VPN conf and keys, stored into the rasp ;) . Have a great day. – ArchiT3K Jun 16 '15 at 08:31
  • We're getting somewhere. What you said sounds good so far. But how will you prevent a thief from obtaining the VPN conf and keys stores in the rasp? It's a rhetorical question. The answer is that you can't. Basically, if the rasp' can boot up by itself and get access to its own VPN conf and keys, then the thief can do it too! – Celada Jun 16 '15 at 08:36
  • ...unless you need the decrypt pass. And if it is stored into a SD-Card dongle (physically separated from the rasp... I m brainstorming...). – ArchiT3K Jun 16 '15 at 09:02
  • Ouais, c'est un bon compromis. In fact I've recently created an embedded system for deployment in untrusted locations that uses a similar compromise: encryption key in flash storage that is difficult to access, encrypted data on hard disk. – Celada Jun 16 '15 at 12:39

1 Answers1

1

In your application, you want to protect at least:

  • The actual media files obtained from the server
  • The VPN keys that allow the Raspberry to connect to the VPN (otherwise an intruder need only extract that key, connect to the VPN themselves, and get the files)

You can encrypt only those things, or you can encrypt the entire root filesystem. Perhaps you might as well do the latter while you are at it.

You can use luks to encrypt the Raspberry's root filesystem. You can find instructions for setting up a Debian (and presumably Mint) system with encrypted root from many sources. Basically, you can do it from the installer before the system is installed. Converting a system after the fact is much more trouble because you have to:

  1. boot an alternate system
  2. mount the target root filesystem and copy its contents elsewhere (implies having spare storage)
  3. reformat the target root filesystem with luks
  4. copy everything back
  5. Add the new encrypted partition to /etc/crypttab, adjust /etc/fstab
  6. With chroot or similar, regenerate the target's initramfs so that it will have the ability to decrypt the root at boot.

A separate root filesystem and /boot filesystem is a must, so you should start with a system that already has that if you go with the conversion option. Converting an existing system to encrypted root is a bit of an expert procedure. I quickly found a tutorial but I haven't read it so I cannot vouch for it.

If the Raspberry must boot unattended on its own, then you are faced with the problem that whatever you do is insecure: the unit must be able to unlock its own decryption, which means that the keys will be accessible to a thief. Still, the mitigation you propose in your comment, which is to physically separate the key on different media, is not a bad compromise if you must go that route.

This other question covers how to make the system access its own decryption key at boot time in an automated fashion. Instead of a keyscript that just echos the passphase as proposed in that solution, you would create a short script that:

  1. mounts the physically separate media
  2. loads and outputs the passphrase from a file over there
  3. unmounts the separate media

That script would run from inside the initramfs. Untested: such a script could look something like this:

mkdir -p /mnt/key
mount /dev/disk/by-id/sd-card-whatever-the-device-name-is-part1 /mnt/key
cat /mnt/key/root-filesystem-key
umount /mnt/key

...and add a keyscript option in /etc/crypttab that names that script.

Community
  • 1
Celada
  • 43,173
  • 5
  • 96
  • 105