Using Perimeter Detect


Ok, that’s what I guessed. Thx!


Another question before my “final” test: is it possible to change the action flag of the zkSetPerimeterEventAction function even after has cut the lock tab?

My goal is to call the SELF_DESTRUCT flag in production mode, and be able to open the box for a “maintenance” mode in calling the ACTION_NOTIFY flag, and to not “loose” (= destruct) the key stored in my zymkey :sweat_smile:


Once the lock tab has been cut, no further changes to the action flags are permitted.

One possible way around this limitation would be to configure one tamper detect for notify and the other one for self destruct.


Ok, and how it happen in “practice”: when I cut the lock tab, does the zymkey simply keep the last flags set previously by software?


Concerning the Zymkey 4i product I understand that the perimeter detect feature recognizes an event when the wire between P1A and P1B is disconnected. Is there a way to modify the feature so that it recognizes an event, and say erases the keys, when the wire becomes connected ?

Thank you for your help


@Tgratier that’s correct. When the lock tab is cut, Zymkey keeps that last flags and prevents any further modifications to those flags.


Zymkey 4i only registers a perimeter breach event when the loop is broken.



Thank you very much


@Scott_of_Zymbit, Hi. I tried to gcc your code example, but I get these errors:

pi:/usr/local/share/zymkey/examples $ gcc test.c -o

perdet/tmp/ccG49G68.o: In function main': test.c:(.text+0x24): undefined reference tozkOpen’
test.c:(.text+0x54): undefined reference to zkSetPerimeterEventAction' test.c:(.text+0x68): undefined reference tozkSetPerimeterEventAction’
test.c:(.text+0x78): undefined reference to zkWaitForPerimeterEvent' test.c:(.text+0x9c): undefined reference tozkGetPerimeterDetectInfo’
test.c:(.text+0x118): undefined reference to zkLEDFlash' test.c:(.text+0x124): undefined reference tozkClearPerimeterDetectEvents’
collect2: error: ld returned 1 exit status

  • Your .h files (zk_app_utils.h, zkAppUtilsClass.h and zk_b64.h) are in the same directory of my .c file.

  • I replaced the instruction:
    #include <zymkey/zk_app_utils.h>
    #include “zk_app_utils.h”

  • libzk libzymkeyssl zkbootrtc zkifc zkapputilslib are updated.

I am new to C programming in Linux, so it’s possible that the solution is trivial; can you help me?


You need to include the library for zk_app_utils in your gcc statement:
gcc test.c -o test -lzk_app_utils

Also, why did you have to copy the include files locally? #include <zymkey/zk_app_utils.h> should be found by gcc with no problems.


Thank you,
in the end I solved by compiling with this command:

gcc -I /usr/include/zymkey -lzk_app_utils file-name.c -o program-name

Now I’m trying to encrypt the file system following the instructions described in “Convert existing SD Card to LUKS”.

At the end of the procedure, however, something strange happens: in the console appear some messages “…order ignored: not executable”. The system reboots, but the Zymkey starts blinking quickly (binding not valid).

If I shut down and reboot the system, NOOBS doesn’t start (the system freezes on “Welcome to the Raspberry…” message).

I get the same result if I restart the system after disconnecting the zymkey.

Do you have any suggestion?



We don’t support NOOBS directly and if you use call script with no parameters it will probably fail. If you can figure out what partition the root file system lives on, then you can feed that as a parameter into to SD card conversion script.

By default, the script works with the 2 partition layout from a normal Raspbian installation:


Hi Scott,
I understood what the problem was.

In the official procedure it is not written that after the first restart it is necessary to wait a long time for the completion of the second phase. Unfortunately, since no warning appeared on the screen, after a while I manually rebooted, so the procedure was badly interrupted making the device unusable.

(It may be useful to add a note to the documentation in so that other users do not make my mistake).
During the last attempt I used the commands “top” and “df” and I realized that something was still running in the background. So I waited until it was restarted. At the end, the system restarted, but freezed (see the attachment).

I turned off the power and on again, and the system seems to work.

The command

ls /dev/mapper/cryptrfs -la

returns "lrwxrwxrwx 1 root root 7 May 9 11:04 /dev/mapper/cryptrfs -> …/dm-0


Hello Scott.
Does the “self destruct” mode work(destroy all of its key material) even when the lock tab hasn’t been cut?
Thanks in advance.


Self destruct mode only works after the lock tab has been cut.


Hi again,

I have read this in [Power Quality] topic:

In the event of poor power quality the Zymkey instantaneosly shuts down access to the security API and communication channels and retreats into sleep mode (no sleep mode on Zymkey 4i lite). In sleep mode the Zymkey continues to monitor the quality of the 5V power rail and when conditions have stabilized it reactivates the security API and communicaiton channels.

I have many questions about this:

  • is the power quality you are talking about is ONLY the 5V from the Raspberry, or does it include the coin cell of the zymkey?
  • what happens, in locked mode, if we remove the cell coin: is the zymkey will interpret this like a potential attack and will delete all these keys (if the good flag was set before to cut the PCB) during the next starting ? I mean, is the zymkey able to know when he boots than the coin cell was removed before, or it will juste start normally after.



do you have any answer to give me for my last question?
Thx by advance!

  • Power quality monitors only +5V from the Raspberry Pi.
  • With Zymkey 4, the coin cell removal is not interpretted as an attack, so keys will not be deleted.
  • With Zymkey 5, the coin cell removal can be interpretted as an attack, and the response policy is set by the user prior to locking. Zymkey 5 is available on pre-order here:


ok thx! How the zymkey 5 will “work” to detect a coin cell removal during the next boot?


We do not disclose the details of “how” it works, but it will work :wink: