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.
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.
Hope this answers your questions; if not please let me know!