Talking about Cryptodevices... which one?
gniibe at fsij.org
Wed Jan 28 02:46:59 CET 2015
Thank you for your question.
On 01/28/2015 01:24 AM, Felix E. Klee wrote:
> On Sat, Jan 24, 2015 at 4:05 AM, NIIBE Yutaka <gniibe at fsij.org> wrote:
>> gnuk (running on the FST-01)
> How does that store the private key? Password encrypted?
Gnuk stores private keys encrypted by AES. The data encryption key
(DEK) of AES is generated by a TRNG routine named NeuG. This DEK is
then encrypted by another AES KEY generated by S2K (string to key)
function with passphrase. Gnuk's S2K function is taken from OpenPGP
specification (and with SHA256). It's default s2kcount is 192 as the
MCU is slow enough, but you can configure it at compile time (like
65535 for host PC, or more).
>From the viewpoint of getting unencrypted private key, it's like:
On flash ROM: Private key encrypted ------\
On flash ROM: DEK encrypted --\ [AES]--> Private key
[AES]-> DEK --/
It's much like OpenPGP, but Gnuk has additional step, because
OpenPGPcard specification also allows admin to access user's private
key. This would be a weak point of OpenPGPcard specification, so,
Gnuk has its original feature to disable "admin" role.
* * *
When we evaluate possible attacks, I think that it is very important
for us, OpenPGP users, who value the users control of their computing,
to understand the difference between:
the structure of traditional smartcard industry
the specific usage of OpenPGP with smartcard/token
For smartcard industry, "user" is actually the entity who purchases
the smartcard, and most of the cases, it's *not* the end user, but
it's a company who forces using smartcard to its customer/employee.
In this structure, "user" cares about the attacks by its
On the other hand, typical usage of OpenPGPcard is by the end user of
GnuPG. I realized that people tend to talk with the assumption of
smartcard industry, without considering our specific usage.
For Gnuk, serious threat would be software vulnerabilities of itself.
There would be a possible hole to circumvent "three time failures" of
passphrase. Even if we had such a hole, slow enough S2K function
tries to prevent access to raw private key. There would be a possible
hole to access MCU's internal flash directly. In this case,
dictionary attack would be most effective (Gnuk allows passphrase
length up to 127, though). Given the NeuG's randomness is good
enough, breaking encrypted private key directly would be difficult.
There would be a possible hole to get access to raw private key when
it's loaded to MCU's internal RAM, or by its computation side channel.
Well, I do my best not to have such a hole. It's not for Gnuk, but I
fixed some in libgcrypt/GnuPG, you can evaluate those, say, changes in
the RSA implementation.
* * *
The important point of using smartcard/token is to put your private
key under better control (as well as other points like portability,
etc.). I think that it's better to use smartcard/token, than storing
the private key on disk of host PC. Because it could be more simple
>From this point, it is better for smartcard/token, not to have other
"useful features". I'm afraid that something like that simply means
inviting more vulnerabilities or risks.
People might like "powerful" processor. But, "slow enough" is an
important factor in my own threat model. It's interesting that card
readers tend to have more powerful MCU than FST-01, these days.
More information about the Gnupg-users