Is there a way to call wait_for_perimeter_event() asynchronously?
Also, when I call wait_for_perimeter_event(timeout_ms=0), I get AssertionError. Why is that?
Wanted to confirm if the zymkey babbling behavior is expected on making a zkunlockifs call on /var/lib/zymbit/key.bin.lock ?
What happens in self-destruct mode if this call is made from the pi?
I would suggest that you create a thread which calls wait_for_perimeter_event with a non-zero timeout.
The timeout of 0 makes no sense for a blocking wait since nothing is returned from wait_for_perimeter_event. If you want to query the status of the perimeter event continuously, you could just call get_perimeter_detect_info.
Are you calling zkunlockifs manually? This utility should never be called during normal operation. It is only intended to be called as part of the pi boot sequence for encrypted root file system in initrd.img.
Sure! Mentioned about timeout value of 0 because it was mentioned in the documentation and I was wondering how it can be used. Documention - " This function blocks the calling thread unless called with a timeout of zero"
Yes, calling it manually only for testing. I see that the zymkey blabbles, but it can still detect a perimeter breach. How can I detect zymkey blabble programmatically? This can give insight if someone tried to do an intrusive operation with zymkey.
Looks like we have a documentation issue. Thanks for pointing that out.
I assume you’re seeing the ‘babble’ message in the systemd journal. This message is essentially pointing out potential issues on the i2c bus. As you have observed, on of the of the ways to force this to happen outside of hardware issues is to run one of our “standalone” utilities. These utilities (zkbootrtc, zkunlockifs, zklockifs) are not meant to be arbitrarily called by the user and do not fit into an intended use case, which is why we have no documentation on them.
If you’d like to encrypt and decrypt data, you could use our ‘lock’ and ‘unlock’ APIs. For example, in Python:
import zymkey
data = b"Hello, world!"
edata = zymkey.client.lock(data)
ddata = zymkey.client.unlock(edata)
if data != ddata:
print("Decrypted data does not match original data")
else:
print("PASS")
Cool. Thanks for that! I saw the zymkey blabble because I saw the LED flashing very rapidly after making the call.
I am not sure what exactly caused the behavior, but I am finding 2 issues with my zymkey.
- The timestamp is not synced, and it is showing something like [0, 504]. I was expecting the second channel timestamp to be equivalent to the current epoch time. How can I reset the clock to current timestamp ?
- A few days back I tested that my coin battery was working. I would basically poweroff the pi, break the circuit, turn on pi and call get_perimeter_info(), and it would show me the timestamp when the circuit was broken when the power was off. But, now the perimeter detect event is not detected once I have turned off the pi. Do you know what can cause the coin batteries to not work?
Environment - zymkey tab not cut. Notify mode. I probably changed the mode to self-destruct at some point, and I noticed that it detects perimeter breach but gives [0,0], I believe thats expected.
I also took out the zymkey from the pi once, removed the batteries, restarted zkifc, zkbootrc, set ntp to true, restarted systemd-timesyncd.service and restarted system multiple times.
I am also sometimes seeing the error -
“zkifc: NTP not ready”
Why is that? How can I fix it?
Have you measured the voltage across your coin cell battery? We have encountered a lot of problems with the cheaper coin cells reporting marginal voltages out of the package. Zymbit recommends using Panasonic cells. Outside of that, do make sure that the coin cell is inserted with the positive side up.
This message is informational in nature, not necessarily an error. zkifc synchronizes the zymkey time if the Pi has achieved NTP sync. It periodically checks the NTP sync status and emits that message if the host has not sync’ed NTP.
There could be a few causes for this message being emitted:
- Internet connectivity has not been achieved
- NTP has been disabled via
timedatectl - NTP servers are not reachable from the host, e.g. they have been firewalled
I am using these batteries - https://www.amazon.com/gp/product/B07WQX6Z8W/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
I am suspecting the issue was with the RTC clock not getting synced, because I waited for like 12 hours, and next day after rebooting the timestamp became fine. But, I do not understand what caused it to go out of sync in the first place.
Yeah, you are right. Looks like the NTP unit file but I had to manually reload the systemd daemon. Saw this message -
"
sudo systemctl status systemd-timesyncd
Warning: The unit file, source configuration file or drop-ins of systemd-timesyncd.service changed on disk. Run ‘systemctl daemon-reload’
"
Looks like NTP service has a watchdog timer of 3 minutes, which is why that message comes and goes away.
Can you also respond to the question about self-destruct mode behavior.
With tab not cut, in self-destruct mode, if I call wait_for_perimeter_detect(), it detects the event but get_perimeter_info() gives timestamp [0,0]. Is this expected?
If you set the policy to self-destruct only (e.g. zymkey.client.set_perimeter_event_actions(0, action_notify=False, action_self_destruct=True), no notifications will be logged and, consequently, when calling get_perimeter_detect_info, the timestamp will be 0.
Also please note, self-destruct mode only works in production mode (when lock tab is cut).
Thank you! That worked.
So, if we set one channel with self-destruct, but not the other, and the tabs are cut. Does zymkey destroy slots in that case?
I am trying to understand when we would choose to set one mode in notify and other in self-destruct? What advantage do we get from it ?
The main reason we did this was for flexibility for the user. However, one use case that might be interesting would involve a form of early warning. Imagine an “outer” perimeter and an “inner” perimeter. If the bad actor crossed the outer perimeter, you might want to send a notification or activate an alarm system to scare the intruder off. If the bad actor went further and crossed the inner perimeter, the unit would be sent into self destruct mode.
Hello team,
I sometimes see issues that zymkey clock takes a couple of hours before the perimeter detect info starts showing the correct time. For example, immediately after the setup, I would see timestamps like [4,4] or [19041, 19041] etc. And if I leave the zymkey running for a couple of hours (~3 hours based on my observation), the perimeter detect starts showing the right time. Why does it take so long? Is there anything we can do to make the zymkey rtc clock to sync faster?
I also checked systemd-timesyncd.service logs, and that service seems to be syncing with ntp fine. I would see messages like - “Synchronized to time server for the first time” for an earlier timestamp, but zymkey would still show the incorrect time.