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)
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) :
- uses the reverse tunnel to connect to the device;
- uploads to the device a program that checks that no files were modified;
- 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;
- 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;
- 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.
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 ?