2

Background

I have am developing a service which consists in a small headless client device (e.g. OLinuXino) which will contain sensitive data.

The device will be plugged to a remote network (maybe behind a firewall) and its goal is to open a reverse ssh tunnel to a server automatically (i.e. unattended).

The device will contain a key to connect to the ssh server, and that key should not be used in another device.

The device will be distributed to customers so anybody could have a physical access to it.

I do not want that anyone could get the data from a given device and my goal is to slow down the retrievial of sensitive data.

At least, if it happens, I would like the server to detect it and block any further access using the key from that given device. Actually, if someone just tries to do something nasty with the device, I could definitely block its access (and blacklist that person or company).

The device is a small Linux machine (running Debian Wheezy). I do not plan to use a damper-resistant chip for now (as described here)

Notice

I already heard of Mandos, but it seems to work only on local network, although my device and server will be on remote sites.

I also read this question: For remotely unlocking LUKS volumes via SSH, how can I verify integrity before sending passphrase? and I am aware that what I want to achieve may be impossible. But my goal here is to add the most possible security to that device.

My current solution : My first thought is to encrypt the device's rootfs volume to protect the data on it (based upon this solution). When the device is switched on, it connects unattendly to the server (with initramfs) and opens a first reverse ssh tunnel (with a key that is less important for me to loose).

I plan to remove keyboard or screen connectors and/or drivers on the device.

The server then (unattendedly) :

  1. uses the reverse tunnel to connect to the device;
  2. uploads to the device a program that checks that no files were modified;
  3. uploads to the device a small program that checks the hardware of the device (cpuid and mac address) and runs it to get this information;
  4. if one of the above did not work or returned incorrect information, blocks the device access and the customer's account (i.e. the server will never accept them to connect anymore), eventually erase all data on the device;
  5. if the steps 2 and 3 were successful, it then decrypts the rootfs volume and allow the real system service to be launched;

All filesystems on the device are mounted read-only using union filesystem (aufs).

After that, the first reverse tunnel is closed and the device boots.

After boot a new tunnel is opened with the "real" key. At that time, sensitive data is decrypted in the device's RAM.

My goal : My goal is to secure the device's rootfs or a part of the data that is inside it, blocking or slowing down anyone who wants to read it.

My questions

Question 1: what are the harms of my solution ? what are the possible exploits for each step ?

Question 2: are there other possible solutions that would be better to achieve my goal ?

Community
  • 1
lauhub
  • 121
  • 3

1 Answers1

1

To answer your first question: I think the big risk with your set-up would be that you cannot prevent access to your initramfs. This would allow an attacker to gain knowledge on your set-up, which then allows for a full MITM kind of attack, accessing your software (with the private key built-in). From that moment possibilities are endless as you could reverse engineer that package you want to send to your device, gaining access to that ssh keys you do want to keep at highest security. Or maybe modifying some code so you think all is alright, but actually isn't.

Removing some connectors ain't going to help you to a determined attacker which might just re-solder those connectors. And a very determined attacker with time and money might just do a full dump of the flash memories and start working that way.

The fact is, physical security opens a wide range of possibilities to attack a device, which can almost never be prevented from happening (unless booby-trapped or so).

Another risk I see is that your set-up is relative complex, so things could break. For instance, when a simple SSH tunnel cannot be opened because of a firewall rule. Or, what about if the dropbear software you want to use has a critical externally exploitable vulnerability. How would you fix that?

Question 2: Without giving more details on what you actually want to achieve with these headless devices, it is hard to give some advise on what might be a better solution in your case. It sounds like you have absolutely no trust in the places or people you install that device. What makes you still want to do it in the first place if there is no trust at all?

user258572
  • 146
  • 6