Actual real practical use/implementation of "Perimeter Detect" pre- and post- cut/lock/binding - Advice/answers Please!

ZYMKEY4
1

Basically I just need some clarifications as I cannot find the answers to the scenarios that I am suggesting here. I have a good idea how it should work but as there are several alternative ways of doing it I need to know the way that you, as designers of this really useful board, have implemented and expect it to be used!
I have presented these as a numbered list so that you can easily address each point, so, here we go …

  1. Please confirm that when the “cut” has not been done there is no way that the unit can automatically, or programatically (via the api), destroy the internal keys and thus render a LUKS filesystem inaccessible.
  2. Please confirm that if I make the “cut” the unit will automatically and immediately irrevocably adopt the behaviours that have most recently been configured for each perimeter circuit.
  3. When I actually perform the “cut” must I have both the perimeter circuits connected and complete (i.e. shorted). The case I’m designing has a micro-switch and a wire glued to the case body for tamper. I cannot, of course, physically get a pair of cutters inside the box when it is closed! I have to perform the “cut” with the lid off (the Pi powered off) and the tamper circuits both open. I’m assuming that there must be a way of initially setting the system in such a situation? My only “workaround” is that I could insert a parallel “shorting loop” for each circuit which I physically remove when the lid is screwed on and so the system is never triggered. Obviously I can mechanically design this, but the shorting loops must not be able to be re-inserted otherwise “bad-actors” could compromise the security. Especially if they can work out where the wire or the switch is located.
  4. Once the “cut” has been made if I later upgrade, update or add software on the Pi (including but not limited to: the O.S., or any application, or any dependencies) could this cause the “binding” to fail? (I know that I cannot update the software on the Zmykey once it has been “cut” and that is precisely not what I’m concerned with!)

I have an upcoming security project which needs about four Pi based units, which I’ll be using your Zymkey 4i on.
I will also be asking some software questions in another topic!

2

@Rob @jason

How Perimeter Detect and Lock Work Together

Q1. Please confirm that when the “cut” has not been done there is no way that the unit can automatically, or programatically (via the api), destroy the internal keys and thus render a LUKS filesystem inaccessible.

A1. Confirmed. When in developer mode (the lock tab not cut) the internal keys will not be destroyed by a perimeter event.

Q2. Please confirm that if I make the “cut” the unit will automatically and immediately irrevocably adopt the behaviours that have most recently been configured for each perimeter circuit.

A2. Confirmed. When in production mode (the lock tab is cut) and the event action policy is set to self_destruct, then the internal keys will be irrevocably destroyed by a perimeter event. No recovery is possible in this scenario.

Q3. When I actually perform the “cut” must I have both the perimeter circuits connected and complete (i.e. shorted). The case I’m designing has a micro-switch and a wire glued to the case body for tamper. I cannot, of course, physically get a pair of cutters inside the box when it is closed! I have to perform the “cut” with the lid off (the Pi powered off) and the tamper circuits both open. I’m assuming that there must be a way of initially setting the system in such a situation? My only “workaround” is that I could insert a parallel “shorting loop” for each circuit which I physically remove when the lid is screwed on and so the system is never triggered. Obviously I can mechanically design this, but the shorting loops must not be able to be re-inserted otherwise “bad-actors” could compromise the security. Especially if they can work out where the wire or the switch is located.

A3. The logic works as follows: when you cut the tab, you are “arming” the device to recogize a close+open event on one or two of the perimeter circuits. This gives you one opportunity to cut the tab, then to close your perimeter circuit(s) around your Pi. The perimeter detection system is now armed. If you have set the zymkey_perimeter_event_action to self_destruct, then in the event the perimeter circuit(s) is opened the internal keys will be irrevocably destroyed. This method of “cutting and arming”, applies independently to each of the two perimeter circuits.

Q4. Once the “cut” has been made if I later upgrade, update or add software on the Pi (including but not limited to: the O.S., or any application, or any dependencies) could this cause the “binding” to fail? (I know that I cannot update the software on the Zmykey once it has been “cut” and that is precisely not what I’m concerned with!)

A4. The binding should remain in tact when you update you software or OS. However we always recommend you proceed with caution when upgrading any software, as sometimes an OS update can introduce unwanted artifacts that might impact parts of the kernel.