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:
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.
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:
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.
ls /dev/mapper/cryptrfs -la
returns "lrwxrwxrwx 1 root root 7 May 9 11:04 /dev/mapper/cryptrfs -> …/dm-0
Does the “self destruct” mode work(destroy all of its key material) even when the lock tab hasn’t been cut?
Thanks in advance.
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
On the top of this guide it mentions Application Examples & Available Dev Kits as “Coming soon”. In a post on Oct '17 it was also said that a general use case app would be provided the next week. Are these items publicly available anywhere and if not, is there any plan to add them for the community? I’m looking for a step by step guide for taking a Zymkey 4i and Protokit4 and showing how to put them together with an example circuit using the perimeter-detect features.
Also it would be useful if someone answered the questions on this post:
Jason, thanks for pointing out that it would be helpful to have a a step-by-step guide explaining how to use perimter detect with protokit. We will take a look at this and get something posted by 2/11, and also repond to your specific questions. Thx
Thank you for the quick reply! I look forward to the post!
Here are answers to Sept '18 questions you referenced:
Greetings! Were you able to look at it?