no the problem zymkey is NOT locked; it worked well until the problem appeared suddenly;
I am afraid I can’t test anything at all: the zkOpen(&ctx) function always fails with the “problem” zymkey and returns -ETIMEDOUT (=-110) … So I can’t work with it.
-Should I try to execute the setup.sh script again to try to bind the “problem zymkey”? I already tried it many times.
-This zymkey was first used on a jessie distrib, could it be the origin of the problem?
I will try with all my others zymkey, but I am not in the good place right now; I will do it in a week…
Hello,
I have successfully installed the zymkey module and used Luks encryption, everything works just fine as expected. Now, how can I use the zykey key store to keep one or more Private keys that I needed for authentication when connecting to external services? Are there APIs that I can use to insert the keys to key store and retrieve them on demand?
Hi, over this past week I installed a Zymkey 4i on a RaspberryPi Zero running the latest Raspian Stretch distro. I successfully got everything running in developer mode and today decided to clip the PCB to move to production before sending it to my customer. I removed the Zymkey form the RPi0 header, and cut the PCB as indicated in the instructions above. After placing the Zymkey back on the RPi0 header, the unit will no longer boot up. See the screen shot of the error below. I have tried everything from bending back header pins to address any weak connection but nothing seems to work. Any ideas what could have gone wrong??
@Phil_S_Zymbit_1 still unresolved… i just bought more zymkeys and olan to just not cut the tab off … im willing to invest effort to fix issue but st $50/ea dont think i should keep paying for zymkeys to get this to work
IMPORTANT: first power down your Pi and Zymkey. Removing the Cut-2-Lock tab can be done in situ, or by removing the Zymkey from the Pi.
When you say “power down zymkey”, does it mean I have to remove the cell coin battery from the zymkey (and of course power down the Pi) before to cut the tab?
No, you don’t need to remove the battery when removing the cut-2-lock tab, but you do need to make sure that the Zymkey perimeter detect is not in self-destruct mode.
Thx for the answer, but I don’t understand.
I know I would not be able to change the perimeter detection action rules after having cut the tab, but tell me: if I read some message on the topic about perimeter detect, you told me I can change the routine to self destruct mode, but it will not work until the tab is cut. Am I right?
So you are just warning me about the fact that when I will cut the tab, the perimeter integrity should be preserved right?
@Tgratier after cutting the lock tab, you have one chance to set the tamper detect actions. In fact, for best practice, after cutting the lock tab, the tamper detect actions should be set.
Let’s take the case of the assembly line: at some point the zymkey is mounted onto the host rpi and power is applied while the lock tab has not been cut. This allows the zymkey to bind to its host. After the binding is complete, power is removed, then the zymkey is removed and the lock tab is cut. Next, the unit can be assembled. Finally, the power is reapplied and the tamper detect actions are set to the appropriate mode for each tamper detect input. For best practice, this should only run the first time after assembly is complete.
One final note: when one is developing code on zymkey and one decides to try the lock tab function, it is very important to set the tamper detect actions to “none” or “notify only” before cutting the lock tab. Otherwise, if one of the tamper detect input actions was set to “self destruct”, the zymkey will destroy its key material while tamper detect inputs are open and the tab is cut.
What would be the consequencies if I run my “main” program function and set the tamper detect actions each time the pi starts?
If I should resume all I understood, the BEST PRACTICES ARE:
-) bind the zymkey and pi
-) cut the tab with pi power down but cell coin still in the zymkey
-) run only ONE time a special script to set the tamper detect actions
-) for example, edit the rc.local file to launch the “main” program at each start; This “main” program must not contains the “zkSetPerimeterEventAction” function.
To finish, is there an export probleme with the 1.8.13 pdf version of the API documentation? I can’t see any prototypes function.
Hi @Tgratier
These are the steps you should follow:
With Zymkey in Developer Mode (Lock Tab in Place)
Do not cut the Lock Tab yet !
Install the battery on Zymkey
Place zymkey onto the Pi (with power down on the pi)
Turn on the Pi
Install and bind the zymkey and pi
Set Perimeter Event Actions to “none” or “notify only”
Create your LUKS encrypted volume
Install your applications into your encrypted volume
Confirm your system and applications work fully as you intend
When you are ready to move Zymkey to Production Mode,
Do not cut the Lock Tab yet !
Turn off the power to the Pi.
Do not remove the battery.
Remove the zymkey from the Pi
Cut the Lock Tab
Replace the zymkey onto the Pi and turn on power to the Pi
Close your perimeter circuit(s) (enclosure lid)
Clear Perimeter Detect Events
Get Perimeter Detect Info to confirm prior events are cleared and the perimeter is closed.
If the Perimeter Detect Event returns clear, then you can ‘arm your system’ as you require by setting Set Perimeter Event Actions to “none”, “notify” or “selfdestruct”
@mikedawson
Thanks for catching that, you are correct. The duplicate step 18 “you can now cut the lock tab” has now been removed and replaced with “your system is now armed”. We’ll post this detail in the getting started guide to clarity.
@grundyoso@Tgratier
We have updated the Getting Started documentation to provide more explicit detail on how to “move Zymkey from Developer Mode to Production Mode”. Let us know if you have any feedback, remaining questions.
Thx
Once the Zymkey is bound to the pi, the Zymkey’s blue LED should blink slowly - once every 3 seconds - to indicate that the binding is complete.
My ZymKey does not do this. After installing the software, it blinks 5 times rapidly, and then it seems like blinks 10 times even more rapidly and then repeats.
What does this indicate, software or hardware issue?
I never thanked you for the update, so thx a lot! This is great to have a “step by step” guide.
One more (important) question: in “Production mode”, does the “clear perimeter event” will still work? Of course, only for the “notify” actions.
I mean, if I set one of the perimeter event action to “notify”, should I be able to detect a breach - clear it (if I can be sure it is not a bad one) by software - and “start” again and detect others next breach?
I am thinking about this:
one action to notify the breach, but I would like to be able to “arm/desarm” (by wireless communication) the result of this breach for maintenance operations. So I would need to “clear” the event detect beform to arm AGAIN the zymkey when the mantenance will be finished.
the other with self destruct instruction to guaranty the full security of my product (even against me);
If the clear event function is not working anymore in production mode I can’t see any useful case to use the “notify flag” because it is a “one shot” use like “self destruct function”…
Thx by advance! I hope you will understand my needs!
You can clear tamper detect notifications even when the lock tab has been cut (production mode). Keep in mind that if a tamper detect that has self destruct mode set, it will not matter because the zymkey destroys itself at that point. Once in production mode, the tamper detect actions cannot be changed.
However, in the scenario you show, you can have one TD configured for the notify action and the other one configured for self destruct. If the self destruct one is tripped, then the key will be destroyed. If only the notify TD trips, you will get a notification event which can be cleared. The self destruct TD can never be cleared.
