[Gnuk-users] Did I brick my fst-01?

[NIIBE Yutaka]

Hello, Micah,

Thank you, I understand the cause of this error.  It is likely that
rsa_4096_support doesn't work well.  It's for temporal working branch
before the merge.

On 02/06/2015 12:25 AM, micah wrote:
> I was able to build and load 1.1.4 gnuk.bin via the USB method. Then I
> went to test 4096 support, and I found there was only 2048R support. I
> was confused about this because I thought that 1.1.4 provided 4096
> support.

Gnuk 1.1.4 provides RSA-4096 support (as well as ECC of NIST P-256,
secp256k1, and Ed25519), by changing its algorithm attribute.  But,
the default is RSA-2048.

It would be better for OpenPGPcard specification and the user
interface of GnuPG to show supported algorithm and size of
smartcard/token.  But, currently, it only shows single algorithm and
size.

User can send a private key of RSA-4096 from host PC to Gnuk Token,
even if the attribute says it's RSA-2048, as scdaemon sends a command
changing the algorithm attribute before storing private key.

This way is a bit strange and very unfriendly to its users, but it's
the way of existing OpenPGPcard implementations to follow OpenPGPcard
specification.

> Then I re-read your email and found that there was a 4096 branch, and I
> found that branch on git://git.gniibe.org/gnuk/gnuk.git (called
> rsa_4096).

Well, I tried to reproduce your problem and... got it!

    $ ./configure --vidpid=234b:0000 --enable-keygen
 => Header file is: board-olimex-stm32-h103.h
    Debug option disabled
    Configured for bare system (no-DFU)
    PIN pad option disabled
    CERT.3 Data Object is NOT supported
    Key generation on device is supported
    Card insert/removal by HID device is NOT supported
    $

It's for Olimex STM32 H103.  It's before the change of default target.

> In the meantime, I had entered the wrong pin a few times and was locked
> out, so I waited for the debugger to arrive from China and was planning
> on loading the rsa_4096 branch built gnuk.bin to unbrick it and provide
> 4096 support.

By the way, the firmware upgrade feature (via USB) was originally
designed to recover from the locked state by three-time PIN failures.
You can register up to four public keys for the authentication of
firmware upgrade.  But, the feature is so complicated, it is mostly
used by upgrade_by_passwd.py only.

> When the STLink arrived, I followed the procedure I detailed in my
> previous email and then loaded the gnuk.bin I built from that branch and
> then it stopped working.
> 
> I have a friend who is also playing with this, and he also found that he
> only got 2048R support with 1.1.4, so I told him about the rsa_4096
> branch and after he loaded the gnuk.bin (using USB) his FST-01 also
> became bricked, and now he is getting a debugger to try and solve it.

Now, the reason why it failed in the first place was clear.

Let's figure out next one.  I'll try another connection of ST-Link/V2
today.  And I'll describe my experience with ST-Link/V2.
--