Getting Started with ZYMKEY 4i


thx for your quick answer:

  • 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 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…


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?

Thanks in advance


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??


@grundyoso is your problem now resolved ? per your other thread ? Or is this another open issue ?


@phil 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



  1. do you have a battery inserted to Zymkey ?
  2. are you using perimeter detect?
  3. when you remove the Zymkey to “cut the tab”, do you power down your pi first ?


I have a question about something I read:

Manual Cut-2-Lock

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?



Hi again @Tgratier!

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.



We are not sure if you using perimeter detect/battery in your application, but in any case, as a point of clarification, please ensure that

  • BEFORE you cut the lock tab, make sure that the perimeter detect action is NOT in self-destruct mode. (its dis-armed)

  • AFTER your have cut the lock tab, AND closed the perimeter circuit, then you can “re-arm” the perimeter detect action.



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.


Ok thanks (again) for the details.

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.


Could you confirm all the steps I mentioned please? I don’t want to miss something and break my devices :sweat_smile:


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 !

  1. Install the battery on Zymkey
  2. Place zymkey onto the Pi (with power down on the pi)
  3. Turn on the Pi
  4. Install and bind the zymkey and pi
  5. Set Perimeter Event Actions to “none” or “notify only”
  6. Create your LUKS encrypted volume
  7. Install your applications into your encrypted volume
  8. 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 !

  1. Turn off the power to the Pi.
  2. Do not remove the battery.
  3. Remove the zymkey from the Pi
  4. Cut the Lock Tab
  5. Replace the zymkey onto the Pi and turn on power to the Pi
  6. Close your perimeter circuit(s) (enclosure lid)
  7. Clear Perimeter Detect Events
  8. Get Perimeter Detect Info to confirm prior events are cleared and the perimeter is closed.
  9. 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”
  10. Your system is now armed.



In “Production Mode”, see items 12 and 18.

I see a conflict of the order and duplication.

Michael A. Dawson

CONFIDENTIALITY NOTICE: The information in this transmission is intended only for the individual or entity named above. This E-mail (including any attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, Stored Communications Act (18 U.S.C. § 2701 et seq). is confidential and may be legally privileged. If you have received this information in error, please notify us immediately and delete this transmission and any other documents, files and information transmitted herewith. If the reader of this message is not the intended recipient, you are hereby notified that any disclosure, dissemination, distribution or copying of this communication or its contents is strictly prohibited.


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.


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?


Can you post a short video of the blink pattern - either in this community, or email to Thx



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!