Pi Hardware failure with Zymkey in production mode

#2

I understand this as a security feature and important behavior by design. of course it’s not nice to loose the Zymkey together with the Pi, but it also makes sense. Nobody can steal your device, move the Zymkey to another board and try to break some security and encryption. Also no other “productive” Zymkey will work with your device.

May see it in this way: just because your i stopped working the RAM and USB-Ports probably are still functioning. But you will throw it away because the board is dead. By pairing your Zymkey to this board, you virtually “soldered” it on this board.

Not sure if this helps, or makes you feel less sad. It is the way how it was designed and how it should be.

#3

It’s actually a benefit, although it costs $.

Imagine we could reset our home router to factory defaults and the password is printed on the router itself…then a “bad actor” come into our house, reset to factory defaults, then access our network and steal all our crypto currency wallets…oh wait a minute, those devices do that!!! (thinking better go to cold storage asap!!..lol…and I’m scratching my head, "why did I have to give my router a password again?..oh man :frowning: "…)

So agreed that it’s it like “soldering” the zymkey to the PI once the tab is cut.

The software and dev time worth more than the RPi and Zymkey combined I would assume…so better just replace any anomalies like this…

Are you sure the RPi is dead?

If Zymkey dead (or failed), I’m sure the Zymbit team will take care of you.

#4

Many devices with a security feature (e.g. SoCs with a programmable bit that partially or totally prevents reflashing and disables JTAG) also have a “revert-to-factory” feature whereby protections are lifted and all content is erased – for instance, Kinetis SoCs have “mass erase”.

This provides both security – you can prevent sensitive data being extracted from the chip; at worst, they’ll be erased – and reusability. The only new risk of this is possible DoS, whereby an attacker manages to cause a mass erase / reset to factory.

This “reset to factory” could be done in the Zymkey too, I suppose; part of the needed features probably already exist, at least in a bound Zymkey since it can do a “self destruct”, which is close enough and probably a good starting point.

1 Like
#5

Thank you for your reply.

I’m only using the ZymKey to sign data (protecting the private key inside a dedicated secure element is just necessary today)

So, based on my uses, a factory-reset process won’t create any security risk excepted that this process has to be validated by a human action - eg. battery removal detection - to avoid remote reset attack (as described by @aaribaud-fgs) .

Maybe this product is too much advanced for my uses.

All the best

#6

Thanks for your reply

My Pi is really dead…electrical choc from the power plug (too bad quality).
Fortunately, my Zymkey is in dev mode and works well on another Pi.

#7

Thanks @aaribaud-fgs

If i’m not wrong, the prod mode is really activated only when the cut2lock is removed, so I think it’s not possible to create a reset-factory.

#8

@aaribaud-fgs @fmt - great discussion on security & supply chain.
To clarify, Zymkey 4i does not have a factory-reset. Such a feature would have the potential to become an attack vector in certain circumstances.
If your zymkey is in ‘production mode’, then the binding to its host is truely permanent, much like soldering a chip to the board. If your zymkey is in ‘developer mode’, then you can change and replace the host and SD as desired.

#9

With all due respect @werkof and @phil, the analogy of soldering is a poor one. Just because something is soldered to a board doesn’t mean it can’t be unsoldered and reused, even if the rest of the board stops working for some reason. That’s a choice (to unsolder and reuse or just throw away) whereas the Zymkey literally cannot be reused (there is no choice).

It should be suffice to say that the Zymkey has been designed to (Production) bind with a single device, and once it has can never be used anywhere else.

I think some folks (myself included) are looking for a less “nuclear” option, and perhaps that’s not the Zymkey.

#10

You’re right @JRoseman

#11

You either have something that is secure, or it’s not.
You can’t have something secure that lets you punch holes in it’s security when needed. Because just as those holes serve a purpose for you, they serve a purpose to an attacker.

For what I need for example, I absolutely cannot have a Zymkey re-usable. If the devices goes the Zymkey must go with it. My clients would flip if they knew otherwise and i’ve built that into the product pricing.

As mentioned, that may not be what you want - in which case the level of security you’re requiring is probably not high enough to warrant the Zymkey.

#12

Am I missing something here…

Just don’t cut the tab if you plan to move it to different Pi’s (unsecure method of course), but there are still some things you may want from Zymkey like rtc and the random number generator for example

@Scott_of_Zymbit all the crypto functionality is still there even when not bound to the pi right?

#13

Correct, there is this difference.
That’s why I wrote “in some way”

From an economic point of view it’s not worth unsoldering the ram chip. And I see it similar with the paired zymkey.

It depends on your use case:
A) security requirements
B) economic aspects

Some require the zymkey as it is defined and made (no compromise, no doubts, no reset)
Others can accept and use the “yes safe, but maybe not definitely” way.

#14

@hbmaddog correct, with the exception of the tamper detect action “self-destruct” will not work when the unit is in development mode.

#15

@phil I understand the risk – that’s the DoS scenario I was mentioning.

Still, you could provide a protection against this DoS:

  • For the factory reset feature to work, the user needs to have recorded a public key to the Zymkey;
  • if the user requests a factory reset and there is no recorded public key, the Zymkey rejects the request;
  • when the user requests a factory reset and there is a recorded public key, the Zymkey uses it to challenge the requester, making cryptographically sure they own the private key, and only if the challenge succeeds does the Zymkey execute the factory reset.

This should prevent an attacker from DoS’ing a Zymkey (as long as the private key is kept secure).

The public key could be used for other situations where the Zymkey would need to authenticate a request(er); in fact, it could possibly be made mandatory to record such a key to get the Zymkey to work at all; otherwise, an attacker could record a rogue Zymkey.

#16

Totally agree with you @aaribaud-fgs. Using a challenge-response or a mecanism like that is enough, maybe in a future hardware release a small button to push during boot.

Zymkey is a really nice product, it can cover several security layers from simple crypto func to perimeter protection but the level of security depends of each use case. An intermediate state between DEV & PROD with factory reset could be really usefull for someone that do not need a too hight security level.

#17

Thinking this maybe true if the Zykmey purpose was “standalone”, but it’s not.

Zymkey really takes a “fingerprint” of the system during the init binding process mapping a few things so we truly have a Hardware Root of Trust, not just the Zymkey itself.

So if we are asking for an API to hit Zymkey to “rebind itself”, I can think of quite a few attack vectors that would make it super easy to grab the source code…

So to accomplish the original post, you could ways make your own API along side Zymkey for crypto functions, CSRs, etc and then use any Software driven HSM to accomplish something less secure and transferrable.

For me and my team, we’re sticking with “cut tab”, and “self destruct” mode. Cost of replacement hardware is still far less expensive than the software.

#18

The problem with this approach is that you’d have to have a secret key to generate the challenge exposed on your file system. If a bad actor gets a hold of that key, they could take the Zymkey off of the host pi along with the challenge auth secret key and transport that zymkey to any other host and potentially masquerade as the original target.

The whole point of Zymkey is to keep the secret keys in a dedicated piece of hardware where it’s very difficult if not impossible to pull them out. The strategy then becomes one of coupling key storage and signature generation with physical tamper detection to make it even more difficult to alter system behavior.

#19

After all, one of the Zymkey’s features is to hold secret keys, and it has cryptographic capabilities, so it could keep its own private key along with the proposed user public key, and handle the challenge with the user itself, with the RPi being just a man in the middle (pun half intended).

#20

hi all, i cant understand what happened to my zymkey.

my situation is:

  1. perimeter detect is enable with self destruct.
  2. LUKS encryption is turn on.
  3. perimeter circuit is wrong so always get the timestamp of breach every time run.

after cut the lock, LUKS can boot like usual but all the API to zymbit is fail.

do now know what actually happened. i thought self desctruct mode will also disable the booting into LUKS disk.

i need help in understand this

thanks

saufy

#21

If the lock tab has not been cut, this is expected behavior.