Hi Phil, thank you for your help. Now it works! But I don’t know why. Maybe I made a fault during the installation several times? I’ve performed the getting started guide again and after bindig the key to the pi I made a backup image. Then I encrypted the PIs root partition and it works as expected. The system booted with the encrypted root partition.
Is it possible that the installation skript has made only a partial installation and zymkey is nevertheless bound to the pi? Or maybe the encrytion process run only partly? I’ve made the first installations with a gsm modem and the last one via lan.
@mmuehle
Good to read that you now have your encrypted volume working.
Using a LAN connection is always preferred for a data intensive process like encryption. GSM should work, but could introduce some small errors if drop out happens.
(FYI, we have recently upgraded the script to make the process more robust for situations like this.)
@Gtewksbury we have noticed a few other customers having similar problems when encrypting on a Raspberry Pi model 3B+.
We have made a a few changes to the encryption script to deal with possible edge conditions. I suggest you try the process one more time, as these changes may also address your problem too. We suggest you restart from getting started, then following the encryption process.
I have not seen this specific error. Having said that, we just fixed an edge case in our encryption script in the last couple of days that may have caused something like this to happen. It may be worth it to try again. Make sure to wipe out your external drive before proceeding.
I also had interest (and still interested) in Kali for the purpose of an Edge Device. Primarily for LUKS Nuke functionality. (To work along side Zymkey)
Ran into some issues out of the box with Kali as by design, Kali wants to be left untraceable (you’ll need to tweak settings, etc which in the end makes Kali not Kali anymore). Controlling “over the wire/air” updates provides some other challenges as well. So depending on the purpose of your device, and experience with Kali, it may or may not be easy to get it working. The list is long to get it to work.
If you’re like me and the only intention for Kali was it’s Nuke functionality, there are other means of destroying Zymkey key storage when a breech is detected.
In the end, I reminded myself what my intent was, and then soon realized “I have a device that really isn’t Kali anymore.”
Out of curiosity, are you planning a fleet for Kali devices? Or single device? And for what intent do you want to run Kali?
@doxo - this is exactly the purpose of Zymkey; it provides a “password” (named UKz - UserKeyZymbit) to LUKS, allowing for unattended operation. The “password” is based upon a measured system fingerprint (and other materials), and is automatically managed and protected by Zymkey.
This post explains how to installed Zymkey into your application. Top >
Hi Zymbit Community, @Scott_of_Zymbit , @Phil_of_Zymbit
So I bought zymkey 4i, which is working perfectly and ran the examples code as well in it.
I am a newbie in coding and raspberry pi so please bear with me and please ignore if I ask something stupid.
I want to encrypt the images and video files present in the SD card of raspberry pi and then send it over the wifi to another device (encrypted as well). please tell me how we can do that and as well as check, i.e if we don’t authenticate the receiving device it may get encrypted data, not the original one.
Thanks.
Good to hear you found it easy to integrate zymkey into your system.
Regarding your specific application, there are many ways to tackle this and we can only advise in broad strokes what a potential solution might look like:
When you have completed this step, then you can direct your recorded video into this volume, which means your video will be encrypted at rest (on the SD card).
ii) Set up a peer to peer TLS link between you two RPis, with mutual authentication. (check out the RPI community on how to tackle this). The TLS link can be configured to achieve mutual authentication of end devices, and will ensure that all “data in flight” is encrypted.
iii) You can read your video from the encrypted volume on RPi_1, transmit if over TLS (encrypted) connection to RPi_2 and into the encrypted volume on RPi_2.
This method should achieve your required objectives in broad terms. Please note that if your RPI’s are physically exposed, then there is a potential attack vector as your data is read out of encrypted_RPI_1, and transferred to the TLS connection, and similarly at the other end. If you use the perimeter tamper detect feature of Zymkey, then you should be able to make your system resilient to such physical attacks.
Good luck, let us know how you get on with your project.
Thanks, @Phil_of_Zymbit very informative, I have started to work on it.
Also, there is another follow-up question, does the Zymkey also detects the new input connections to the ports of the raspberry pi. I mean Ras_pi has 4 USB port, HDMI port etc. If I use a flash drive/mouse/keyboard etc. on the ras_pi, will the Zymkey be able to detect them and work according to the user specification (disable, delete etc the data or file).
Hi all, I’m using a CM3 module and encrypted the root file system. The zymkey blinked normaly before the encryption because it was bound to the pi. After the encrytion the blinking pattern becomes strange. It blinks 8 times slowly and after that 1-2 seconds very fast. The pi starts with the encrypted rfs. What does this mean? I have not found any description for that in the documentation. The zymkey is in developer mode. Many thanks in advance for your help. Best regards!
The blinking pattern you describe (1 second very rapid flash - 1 second off - 8 slow blinks) is the error code for interrupted communications. This typically happens if something interferes with the communications process such as interrupt line not being seen by host, i2c communications interruption or host not able to respond to zymkey interrupt within 2 seconds.
Could you please give us a couple of details:
OS distribution
What pins is your CM3 design using for Zymkey? Is the interrupt line (GPIO4) remapped?
Do you have any other i2c devices on the i2c bus?
Are you using a different device tree that might be somehow interfering?
