Firmware update fails due to "cmd_write_binary 6581"

[ghost]

@szszszsz hi please can you help me?

user@nitrokey:~/nitrokey-start-firmware/tool$ pip3 list | egrep "usb|test"
pytest             5.3.5  
pyusb              1.0.2  

 user@nitrokey:~/nitrokey-start-firmware/tool$ ps -ef | grep -i scd
root      3373     1  0 16:45 ?        00:00:00 /usr/sbin/pcscd --foreground --auto-exit
user      3428  2882  0 16:46 ?        00:00:00 scdaemon --multi-server
user      3553  1004  0 16:47 pts/0    00:00:00 grep -i scd

user@nitrokey:~/nitrokey-start-firmware/tool$ sudo kill -9 3373
user@nitrokey:~/nitrokey-start-firmware/tool$ sudo kill -9 3428

user@nitrokey:~/nitrokey-start-firmware/tool$ ps -ef | grep -i scd
user      3561  1004  0 16:48 pts/0    00:00:00 grep -i scd

user@nitrokey:~/nitrokey-start-firmware/tool$ sudo ./upgrade_by_passwd.py -f ../prebuilt/RTM.7/{regnual.bin,gnuk.bin} 
../prebuilt/RTM.7/regnual.bin: 4504
../prebuilt/RTM.7/gnuk.bin: 115712
Currently connected device strings:
Device: 
    Vendor: Nitrokey
   Product: Nitrokey Start
    Serial: FSIJ-1.2.6-67092242
  Revision: RTM.5-modified
    Config: NITROKEY_START:dfu=no:debug=no:pinpad=no:certdo=yes:factory_reset=yes
       Sys: 3.0
CRC32: ae1cae42

Device: 
Configuration: 1
Interface: 0
*** Could not proceed with the update. Please try again, and make sure the entered password is correct.
*** Found error: ('cmd_write_binary 1', '6581')
*** Could not proceed with the update. Please close other applications, that possibly use it (e.g. scdaemon, pcscd) and try again.

[szszszsz]

Hi!

From the log I see, that the communication has worked (so pcscd was not obstructing it this time), and the device has returned the 6581 error on binary object write command. It seems that error is caused by the already used 0 slot, which is selected by default. These slots are writable only once per factory-reset cycle. Potentially you could try to run the update with -k 1, but please wait until I will test that first on my hardware. I plan to check it this Wednesday.

Quick questions:

• Have you used any other upgrade script? e.g. gnuk_upgrade.py?
• Could you provide the Git revision? (git describe)

References:

• https://alioth-lists-archive.debian.net/pipermail/gnuk-users/2016q3/000371.html
• https://alioth-lists-archive.debian.net/pipermail/gnuk-users/2016q3/000372.html
• https://alioth-lists-archive.debian.net/pipermail/gnuk-users/2016q3/000374.html
• https://support.nitrokey.com/t/failed-to-write-x509-cert-to-nitrokey-start/1127/3
• https://lists.gnupg.org/pipermail/gnuk-users/2018-September.txt
• https://lists.gnupg.org/pipermail/gnuk-users/2018-April.txt

[szszszsz]

• [ ] Make upgrade tool more informative in cases like this one;
• [ ] Propose adding -k 1 parameter for another run; Try it automatically?
• [x] Warn about potential on-device data lost.

[ghost]

@szszszsz I did everything right according to the instructions. straightforward. from here https://github.com/Nitrokey/nitrokey-start-firmware/blob/gnuk1.2-regnual-fix/prebuilt/README.md

[user@qb1 ~]$ git clone -b gnuk1.2-regnual-fix https://github.com/Nitrokey/nitrokey-start-firmware.git
Cloning into 'nitrokey-start-firmware'...
remote: Enumerating objects: 37, done.
remote: Counting objects: 100% (37/37), done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 13115 (delta 18), reused 33 (delta 17), pack-reused 13078
Receiving objects: 100% (13115/13115), 14.05 MiB | 5.01 MiB/s, done.
Resolving deltas: 100% (9624/9624), done.
[user@qb1 ~]$ cd nitrokey-start-firmware/
[user@qb1 nitrokey-start-firmware]$ git describe
RTM.7-15-gf278714
[user@qb1 nitrokey-start-firmware]$

It works great with Heads firmware http://osresearch.net/. But i can store only one gpg key and use 2048 bits encryption. 4096 not working(?) Will the firmware update give me any benefits?

[szszszsz]

I see, thank you. Sorry for the delay in the reproduction, will do so in the near time, as this case has to be solved for the future.

The changes are listed here:

• https://github.com/Nitrokey/nitrokey-start-firmware/blob/gnuk1.2-regnual-fix/NEWS RTM.5 contain Gnuk 1.2.6. RTM.7 is Gnuk 1.2.14.

As far as I am reading it, from the bigger things, the KDF-DO support was added. If you do not plan to use it, and you do not experience any stability issues, you can omit it for now.

For 4096 key, it has to be imported to the device as far as I remember, as its memory does not allow to generate it.

[alt3r-3go]

@szszszsz, did this go anywhere? I'm seeing the same error when trying to update RTM.10 to .13 using pynitrokey and following the official instruction, relevant log part (repeats three times and bails out):

Do you want to continue? [yes/no]: yes
...
Starting bootloader upload procedure
Device: Nitrokey Start FSIJ-1.2.15-<num>
Connected to the device
error while running update
	Exception encountered: ValueError('cmd_write_binary 1', '6581')
...

This token has one identity provisioned, but as far as I understand, resetting to factory defaults is not a prerequisite to an update, right?

I've skipped the rest of the info, but the udev rules are there, potentially competing daemons are killed, FW download and verification is ok. Also tried as root, with the same result.

[szszszsz]

This token has one identity provisioned, but as far as I understand, resetting to factory defaults is not a prerequisite to an update, right?

Hi @alt3r-3go ! AFAIR factory reset is required

[alt3r-3go]

I see, thanks, I'll give it a try.

It would probably be worth it to correct the update instruction I referenced, to mention that and the script to return a more meaningful message for this kind of error. What do you think? I can prepare a PR for the latter (I think those docs aren't in the public repo, are they?), if you're interested.

[alt3r-3go]

After looking one more time at the linked Gnuk mail list threads and some other materials I found, I think I see what the problem is - Gnuk tries to upload a public key to the token as the first step of the update, so that it can later authorize the FW update itself. I was having hard time understanding how the token having provisioned keys can conflict with the FW update, as I'd expect the "user data" to be separated from the FW, but that's how Gnuk works.

So for anyone else observing this issue, the factory reset is the way to go, because it will free the key slot, and indeed @szszszsz, I think a documentation/update script update would be quite helpful for preventing confusion here, as this is very much a mandatory step. I guess that Start is not a priority given all the NK3 development efforts (and I see several old open PRs here and in pynitrokey repo enhancing the update process, sort of confirming this guess), so I'd be glad to help out and my earlier offer for a PR stands.

[szszszsz]

Definitely! Feel free to make PRs whenever you see its worth it. Perhaps first it would be good to make a ticket with the problem you would like to solve, and ask pynitrokey team whether they have time to look into testing this, if the change you need is more complex. I myself got a little busy and can't make promises about checking updates to the Nitrokey Start related routines, but I can imagine that if PR changes are simple (like UI messages corrections), then it should not be kept long before merging.