Question about a stolen Raspy with a Zymkey


#1

Hi all!

I was thinking about doing my own version of this: nextcloud.com/box/
That is a Raspberry Pi 3 running Ubuntu Core, with a hard drive attached and with Nextcloud installed.

While at it, I thought that one of the risks of doing it that way was that if somebody broke into my home, stole the “box” (with the Raspi and the hard drive) she then would be able to access all of my data.

After reading about some solutions to avoid it (like this one) and that they didn’t really fit into Ubuntu Core concept I found out about your Zymkey, read the documentation in this forum and it really looks like a promising solution to the problem!

I still got some questions though:

  1. In the case of loosing access to the Raspy (with the Zymkey attached) I could unbind the Zymkey so nobody could access my data from that moment on, right?
  2. With the Zymkey correctly binded the OS can unlock a secret key at boot-up without user interaction, right?
  3. Is the code for the console open? If not, do you plan to release it? I’m asking because without the API service the devices would become useless, am I right?

Thanks a lot!


#2

Hi @pachulo!

Great questions; answers to each below.:

1. Remote unbind

We do not have this feature, though it sounds like a great feature request; I will pitch it to the team.

We designed the Zymkey so that it can operate even if the device is off the network, or on a network without Internet access. Because of this we only require access to the console for the binding process. Once bound, Internet access is optional. This is a good thing; imagine not being able to access your files because your device is offline…

2. Non-interactive secret unlock at boot

You are correct; this is exactly how it would work. As you point out, a common use for this is filesystem encryption. We have made this super-easy, please take a look at our post on creating a LUKS-encrypted disk volume. After following that post, you can create an encrypted filesystem that mounts to the location Nextcloud stores its data.

We are in design discussions around full-disk encryption, but have no official roadmap at the moment.

3. Console source code

The console code is currently closed. However, once bound, the device will continue to work. And, there is no plan for the API service to go away. :wink:

Additional physical security measures

There is no one silver bullet for security, and our approach with Zymkey is multiple parts working together. The next I2C Zymkey features perimeter detection, which disables the Zymkey when activated. Let’s take your question from above, “In the case of losing access to the RPi, unbind the Zymkey so nobody could access my data.” Here’s my take on the scenario:

Once your Nextcloud box is off the network there are no guarantees it will come back online to issue an unbind request. Furthermore, there are no guarantees that the system will ever be booted up again Perhaps the drive is extracted and plugged in elsewhere. This is why filesystem encryption is absolutely necessary and works out of the box with zymkey.

There is no secure boot on the RPi, which means you can alter the system by simply accessing the SD card. Enter perimeter detection.

Given a physical enclosure with a perimeter circuit, the Zymkey will be disabled when the perimeter circuit is breached. In other words: open the box and zymkey will not decrypt the filesystem. Perhaps stating the obvious here, but the physical enclosure should physically block access to all unnecessary ports, especially access to the SD Card!

Additional software security measures

With the above physical security measures in place, you also need to make sure you have good software security measures in place. A good start would be:

  • a “default deny” firewall configuration with only required inbound and outbound ports opened
  • disable remote root login
  • only permit remote login to specific users
  • only permit key-based ssh access with 2 factor auth

With this setup, it would be really, really hard for someone without credentials to login to the machine over the network, and if the box is opened, the filesystem is from then on unreadable. :thumbsup:

Hope this answers your questions; if not please let me know!


#3

Hi @roberto!

That makes a lot of sense: I wasn’t thinking clearly :confounded:, as in my scenario the burglar won’t be connecting the stolen Raspy to the Internet anyway

Great!

That sounds great!
For what I can read in your page the perimeter integrity is an OEM feature: What does it really mean?

And the last questions:

  1. Where could I get a physical enclosure with a perimeter circuit?
  2. Once disabled, can a Zymkey be “reset”? For example, in the case of a SD corruption in the perimeter detection scenario, what should you do?

Thanks a lot for your prompt and informative response!


#4

Hey @pachulo,

While we have been developing perimeter detection for general release, some customers have approached us to perform integration into their existing products, which is what OEM means on our site. We are planning full release of the feature with the next version of our Zymkey 3i, expected around mid march 2017.

To answer question 1. above, in addition to releasing the next version of Zymkey with perimeter detection fully integrated, we are also releasing an enclosure with perimeter detection designed in. :slight_smile:

Zymkey will also have a reset mechanism, which will also be ready when perimeter detection is released.

Thanks!
-Roberto.