Re-reading “one time after the lock tab has been cut”: does it mean one single time? Do you mean that after the tab has been cut if I set destruct=false, it will remain so forever?
@Iker The Zymkey 4i does not have key deletion or revocation features. Also, as I stated above, after the lock tab has been cut, each perimeter detect has one chance to set its perimeter detect action. This is meant as a security measure. Any attempts to set the action after the one chance will result in an error return from the call.
Ok, now I know for the next time.
In the case the tab has been cut is there any software command I can use to delete key to brick the device?
We do not current have an API for deleting or revoking keys. Mostly, this is by design because we don’t want to take a chance on a bad actor penetrating the device and bricking LUKS encrypted units by deleting keys.
Another question (again 
), because I cannot test it.
If I am using this flag
ZK_PERIMETER_EVENT_ACTION_SELF_DESTRUCT
Can you confirm me that the zymkey will destruct its keys, even if the Pi is powered off?
It could seem obvious, I know, but I just want to have your confirmation.
Thanks for your question, @Tgratier.
If a tamper detect input is configured for “self destruct” mode and a detection event is triggered, the zymkey will destroy all of its key material even if the Pi is powered off as long as the battery has sufficient charge.
Also, this feature only works when the Zymkey has its lock tab cut.
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 
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.
1 Like
Zymkey 4i only registers a perimeter breach event when the loop is broken.
OK.
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 to zkOpen’
test.c:(.text+0x54): undefined reference to zkSetPerimeterEventAction' test.c:(.text+0x68): undefined reference to zkSetPerimeterEventAction’
test.c:(.text+0x78): undefined reference to zkWaitForPerimeterEvent' test.c:(.text+0x9c): undefined reference to zkGetPerimeterDetectInfo’
test.c:(.text+0x118): undefined reference to zkLEDFlash' test.c:(.text+0x124): undefined reference to zkClearPerimeterDetectEvents’
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>
with:
#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:
https://www.raspberrypi.org/documentation/installation/installing-images/
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 https://community.zymbit.com/t/luks-encrypt-your-root-file-system-on-raspberry-pi/150 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.