[Gnuk-users] Gnuk and possible hardware vulnerability

NIIBE Yutaka gniibe at fsij.org
Sat Aug 19 02:20:14 UTC 2017


Hello,

Since I would like to continue discussion based on technical facts, I
start new thread here.

I care threat model around hardware.

It is true that in the use cases of Gnuk Token, users somehow depend on
the "protection" mechanism of the MCU.  I recommend enabling this to
prevent reading private key from its flash ROM by SWD/JTAG debugger.  By
enabling the feature, SWD/JTAG access won't work.

This feature is effective to simple attack of connecting SWD/JTAG
debugger.

Speaking about hardware attack against this "protection", there are
possibilities of:

  (1) Semiconductor vendor might have backdoor to read out flash ROM
      content.

  (2) Intrusive physical hardware attack like: opening chip and changing
      of the protection bit by UV light.

  (3) SWD/JTAG access might have hardware vulnerability, which leads
      to bypass of the protection.

So far, I don't have evidence for those things for STM32F103.

For a particular version of STM32F0, I was informed that there is an
effective exploit of 2017 for (3), and possibility of (2).


For myself, I don't rely this feature of the protection, while enabling
it.

With Gnuk, the private key material is not stored in raw data.  It is
encrypted by KDF (Key Derivation Function) by passphrase.  It is just
like the one under .gnupg, when you use host side storage for your
private key.  When it is stolen and flash ROM content is exposed, it is
matter of time, that's true, but still, it requires some time.

The KDF of Gnuk is not that strong, so far.  Now, I am proposing
enhancement to do more repetition of computation also on host side.  For
this enhancement, we have a ticket:

    https://dev.gnupg.org/T3201

... since it requires the change of scdaemon of GnuPG.
-- 



More information about the gnuk-users mailing list