search

Nitrokey / nitrokey-start-firmware

A mirror of Gnuk's 1.0.x and 1.2.x branches.
56 stars 15 forks source link

Firmware update fails due to "cmd_write_binary 6581" #23

Open ghost opened 4 years ago

ghost commented 4 years ago

@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 commented 4 years ago

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:

References:

szszszsz commented 4 years ago
ghost commented 4 years ago

@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 commented 4 years ago

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:

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 commented 9 months ago

@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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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.