I’m considering securing a system with a Zymkey 4i (or HSM4 depending about the capabilities). However as far as I understood there is devolopment mode and production mode. In production mode you can configure to destroy keys on an event like accelorometer detection. As far as I know there is no way to generate a new key, so in this state you would have to buy a new Zymkey. Is this correct?
Then there is development mode. There the key and thus the module don’t get completely destroyed, but binding is done on every boot. So if you plug that module on another Raspberry PI 4 it still reveals the keys. Is this also correct?
So is there some kind of locked mode? So accelerometer detects event, Zymkey gets into locked mode and won’t reveal the key until you manually unlock it? Or Zymkey destroys keys but you can generate new ones and thus reuse it.
As far as I know there is no way to generate a new key, so in this state you would have to buy a new Zymkey. Is this correct?
The zymkey4i/hsm4 have a self-destruct action(if you choose to set it in production mode) linked to perimeter detect events, not accelerometer actions. Once the zymkey has been self-destructed it can’t be recovered.
Then there is development mode. … So if you plug that module on another Raspberry PI 4 it still reveals the keys. Is this also correct?
This is correct. This can not be done in production mode.
So is there some kind of locked mode? … Zymkey gets into locked mode and won’t reveal the key until you manually unlock it? Or Zymkey destroys keys but you can generate new ones and thus reuse it.
We do not have a temporary locked mode currently. We also do not support removing and generating keys on the zymkey4i/hsm4.
We have a new product coming soon, that does perform removing and generating keys.
Here if you want to learn more: HSM6 - Hardware Wallet Module for Web3 Devices - ZYMBIT
Thanks for your detailed answer.
So accelerometer actions are only active / can be progressed when Raspberry PI is powered on? I mean if it doesn’t destroy key on accelerometer actions then the’re only reported via API?
Suppose you have enabled self-destruct mode on perimeter breach, can you disable this mode, open your case / breach perimeter to do maintenance on the PI and then reconnect perimeter and then enable self destruction mode again? Or once enabled self destruction mode, there is no way back?
Once enabled production mode there is no chance to insert a new SD-Card with higher capacity, because Zymkey won’t reveal the key, correct?
I think I’ve read: When you do a dist upgrade it can happen that checksum doesn’t match, so Zymkey won’t unlock key and since you can’t change anything via API or generate new keys you would have to buy a new Zymkey in this case? Or is there another way?
So accelerometer actions are only active / can be progressed when Raspberry PI is powered on? I mean if it doesn’t destroy key on accelerometer actions then they’re only reported via API?
This is correct, accelerometer is only active on power on. You can only get diagnostics of the accelerometer from the API calls. Destroying keys via self destruct policy is only linked to tamper detection.
Suppose you have enabled self-destruct mode on perimeter breach, can you disable this mode, open your case / breach perimeter to do maintenance on the PI… Or once enabled self destruction mode, there is no way back?
Once enabled production mode there is no chance to insert a new SD-Card with higher capacity, because Zymkey won’t reveal the key, correct?
Once the Zymkey is switched to production mode and primed for self-destruct, there is no way back. In production mode, the Zymkey is bound to that specific SD card. It cannot be swapped out.
When you do a dist upgrade it can happen that checksum doesn’t match, so Zymkey won’t unlock key and since you can’t change anything via API or generate new keys you would have to buy a new Zymkey in this case? Or is there another way?
We believe it is not a issue to perform dist upgrades, however we always recommend a cautious approach towards upgrades. Make sure to investigate and test out the upgrade version thoroughly. If the upgrade is volatile, it will indeed self-destruct the zymkey, if it was set to self-destruct.