[Gnuk-users] Ed25519 for signing broken?

[Jonathan Schleifer]

Am 08.02.2015 um 03:45 schrieb NIIBE Yutaka <gniibe at fsij.org>:

> Currently, I don't know why Gnuk generates invalid signature, I
> haven't had such a issue.  I'll investigate this next week.  It's good
> if you can show me reproducible concrete scenario.

I just saw that apparently, there was a bug on 64 bit systems with your ECC patch. Since I did this on a 64 bit system, might this be the cause?

I need to find some time to try this out on another box :). Unfortunately, while I can program the Gnuk in a Linux VM on my Mac, I for some reason cannot set it to Ed25519 on my mac - neither in the VM, nor using OS X. I always get a permission denied error from libusb. Apparently, this is caused by some kernel module claiming it, but I already unloaded the only kernel module that was loaded when I plugged in the Gnuk (did kextstat before Gnuk and after and only one new module showed up - that doesn't necessarily mean it's that module, though).

> This is expected.  It is incompatible change of Gnuk 1.1.x.
> 
> With stable version of Gnuk 1.0.x (which is in FST-01 from Seeed
> Studio), you can change PIN without private keys.

Hm, are you sure about that? I think I couldn't set a PIN with the Gnuk like it came from Seeed. OTOH, I noticed that it seems I can set a PIN only when an admin PIN is set, on 1.1.4 at least. Is this expected? The documentation reads to me like if you don't set an admin PIN, your normal PIN will be used for admin operations.

> With experimental version of Gnuk 1.1.x (which is the "master" in the
> repository), you can't change PIN without private keys.  The error you
> encountered, "Conditions of use not satisfied", is expected when you
> try to change PIN with no private keys.

Yes, "Conditions of use not satisfied" is indeed the error I get. But why can't I change the PIN without a private key? I mean, if I can't, I need to upload my key first with an unsafe PIN. This does not sound like a good idea.

> It was explained in Gnuk README somehow, but I failed to explain
> successfully in a way that I could help users.
> 
> ============================= gnuk/README
> This is another experimental release of Gnuk, version 1.1.4, which has
> incompatible changes to Gnuk 1.0.x.  Specifically, it now supports
> overriding key import, but importing keys (or generating keys) results
> password reset.  Please update your documentation for Gnuk Token, so
> that the instruction of importing keys won't cause any confusion.
> =============================
> 
> In the Gnuk implementations (both for 1.0.x and 1.1.x), we don't
> record raw PIN information on the flash at all, but it is used
> indirectly to decrypt private keys.  Gnuk 1.0.x records some PIN
> information (not raw, the result of key derivation function) on the
> flash when there is no private keys.  When all three private keys are
> registered, the PIN information is removed.  And Gnuk 1.0.x doesn't
> support overriding key import, because of this process.
> 
> In 1.0.x, it's (somehow) risky to keep using with one or two private
> keys only if we consider some attacks to access flash directly.  But,
> I realized that it's not everyone who uses three private keys
> installed.
> 
> Thus, I changed the process in Gnuk 1.1.x, so that we never record any
> PIN information on the flash (raw or some).  In this new design, there
> is nothing to be used for authentication when there is no private
> keys.  In other words, it authenticates by decrypting private keys
> with PIN.  The consequence is we can't change PIN with no private
> keys.  This is a incompatible change and it's a kind of strange
> restriction, but it would be OK.  Well, I could support overriding key
> import with this new design, rather easily, that's a bonus point.
> 
> (I think that other OpenPGPcard implementations has some or raw PIN
> information on it's memory.)
> 
> Overriding key import resets PIN.  This restriction is inevitable by
> the OpenPGPcard specification and current Gnuk implementation.  If
> there is some possibility to improve the situation, it's welcome.
> 
> Ideally, it would be good if it's like gpg-agent supporting more
> private keys with possible independent pass phrases.

Ok, so far, I understand. What is unclear to me however is how the keys are encrypted. I thought the PIN is used as a secret to encrypt the key? Since I can't change the PIN when there's no key, it means I have to keep the default PIN of 123456. And when I then upload my key, it's encrypted with the PIN of 123456, right? But that sounds insecure. To make matters worse, when I then change my PIN, the key becomes invalid because it is encrypted with the old PIN, right? And uploading it again will reset the PIN, meaning I have no way to store it with a different pin than 123456?

I'm pretty sure I misunderstood something here :).

--
Jonathan