Doing my job as security consultant, I’m often confronted with secure data transfers and secure data storage for whatever reason. There is always a point where you need to take confidential data with you and access it from different locations. Normally you would create some sort of an encrypted volume or container on an USB storage device. There are USB storage devices that may have a more or less obscure hardware encryption controller encrypting the data; a few even require you to physically enter a PIN code (which is nice).

Now, beside the fact that the hardware implementation is not openly documented, there is no overview on the manufacturing process either. For end-users and the risk of a master PIN code hidden within the controller becomes a real threat. So what’s the matter? Just use a known good encryption procedure and make sure to follow a good implementation process that looks like this:

• use a trusted environment when creating your encrypted container (hardware and OS)
• use a recommended encryption key length and algorithm for your specific use
• use a trusted encryption software (at least something you’re comfortable with)
• use a good passphrase as shared secret for the encryption process

If you follow those rules above, you’re on a good path. Still, there are risks when you need to access the storage on an untrusted environment – Well, how many environments do you really trust? Once the volume is decrypted all your files are accessible by the underlying system without a trustworthy access protocol. The option to mount/dismount and type every time (a probably long) passphrase, is not a very user friendly approach. Yes, I know, it really depends on the implementation of the encryption software and, most of all, on user’s attitude. But, could there be a better way of doing it?

I suppose this is the kind of question that Andrea Barisani of Inverse Path must have asked himself when he started his USB Armory project. The idea is to put a computer on an USB stick and use the (open source) operating system features to secure and access the data. This concept is valid for several usage scenarios, but let’s focus on a secure storage solution. It just happens that Andrea has also created an open-source software project named INTERLOCK that does just what we need to implement a high-secure portable storage solution. I’ll take you through the steps needed to get INTERLOCK securing your sensible data on the Armory.

PC on a Stick: USB Armory

First of all you need to have or get an USB Armory from the project home page. Here is how the USB Armory looks like (just the board):

These are the hardware specifications:

As you can see the specifications are not bad for such a small device, not bad at all! You’ll find more information about the project on the USB Armory presentation by Andrea Barisani.

And if you wonder how this is going to work, let’s put here a brief usage description. To use the Armory we need a system image on a microSD, this will be used to boot the system and start the INTERLOCK application server.

Prerequisites

Below are the components that may be ordered by Inverse Path:

You’ll need the at least the board and a microSD card that should fit your storage needs.

Installation

Step	Description	Picture
Prepare the microSD card	First of all, download the image file with the operating system and already installed Interlock software that you can find here. At the time of writing release 2016.06.09 was the latest one. Be sure to verify the integrity of the downloaded file with the published hash on the site: shasum -a 256 interlock-usbarmory-v2016.06.09.tgz 5ff99b3cc1543b22b0caae531472a4258bf43a90ee16df0c8f8e0e0906c69c69 interlock-usbarmory-v2016.06.09.tgz If the result matches, extract the files from the archive: tar zxf interlock-usbarmory-v2016.06.09.tgz Go inside the created folder and execute following command on MacOS: sudo dd if=interlock-usbarmory-v2016.06.09.raw of=/dev/diskX bs=1024 And on Linux: sudo dd if=interlock-usbarmory-v2016.06.09.raw of=/dev/sdX bs=1M conv=fsync Change __ to the accordingly to the name provided by your system. For windows user I recommend to get the get 7zip and Rufus tools to accomplish the above mentioned tasks, but other zip and imaging tools should work too.
Prepare the hardware	Either you’ll use the enclosure (highly recommended) or (if you’re like me) use some sort of electrical isolating tape and it will work just fine.
Insert the previously prepared microSD	Careful not to cover the slot where the microSD will be placed (it’s not a slot instead you need to lift the small metal cover) and insert your microSD card.
Insert the USB Armory in the USB slot	The system on the chip will load the boot sector on the microSD and boot the Linux kernel. Now, keep in mind that we’ll be not accessing the system like an USB storage stick, but rather via network.
USB Ethernet Emulation Mode (EEM)	First of all, the Armory will declare himself as a network adapter interface to your system using USB CDC Ethernet Emulation Model basically simulating a network over the USB bus. This is how the system protocols the events in his kernel logs: Ethernet [AppleUSBCDCECMData]: Link up on en8, 10-Megabit, Full-duplex, No flow-control, Port 1 And this is the network interface configuration afterwards: en8: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 1e:39:4f:xx:xx:xx inet6 fe80::1c39:xxff:fexx:xxxx%en8 prefixlen 64 scopeid 0×14 inet 10.0.0.2 netmask 0xffffff00 broadcast 10.0.0.255 nd6 options=1<PERFORMNUD> media. autoselect (10baseT/UTP <full-duplex>) status. active
Network configuration	The Armory will start a DHCP server providing the IP address 10.0.0.2 to your interface (otherwise you need to configure it manually) and this is how it looks in a simple schematic representation: [server][Armory][10.0.0.1] <---USB-EEM---> [10.0.0.2][local-system][client]
System is ready	At this point we should be able to access the USB Armory via the USB EEM generated network (10.0.0.0/24) – Let’s test it with a ping to 10.0.0.1: john117$ ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 56 data bytes 64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=1.178 ms 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.728 ms 64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.665 ms ^C The Armory system is up and running.

Next steps

So far we’ve got to know the amazing USB Armory hardware and booted with Linux. In the next part of this article we’ll get to the Interlock configuration and usage.

About the Author

Andrea Covello has been working in information security since the 1990s. His strengths are in engineering, specializing in Windows security, firewalling and advanced virtualization.

Links

• http://7-zip.org
• http://www.usb.org/developers/docs/devclass_docs/CDC_EEM10.pdf
• https://dev.inversepath.com/download/usbarmory/forging_the_usb_armory.pdf
• https://github.com/inversepath/interlock
• https://github.com/inversepath/interlock/releases
• https://github.com/inversepath/interlock/releases/download/v2016.06.09/interlock-usbarmory-v2016.06.09.tgz
• https://inversepath.com
• https://inversepath.com/getusbarmory
• https://inversepath.com/usbarmory#usbarmory_coin-tab
• https://inversepath.com/usbarmory.html
• https://rufus.akeo.ie
• https://www.keylength.com
• https://www.linkedin.com/in/lcars