[Gnuk-users] Upgrading gnuk on a nitrokey start

Thu Aug 18 05:58:27 UTC 2016

Hello,

I think that you went too fast.  Perhaps, I coundn't follow you
correctly if you didn't show me each step of yours.

On 08/18/2016 01:31 PM, Remy van Elst wrote:
>     For (2), I think that it is possible to do so, or it is possible to
>     write such a tool, in theory.  I'm saying because I once implement the
>     removal feature of upgrade RSA public key in Gnuk.  Nobody has tried
>     that.  IIUC, it is somehow likely that this sequence would work:
> 
>     ./tool/gnuk_put_binary_libusb.py -k 0 /dev/null
>     ./tool/gnuk_put_binary_libusb.py -k 1 /dev/null
>     ./tool/gnuk_put_binary_libusb.py -k 2 /dev/null
>     ./tool/gnuk_put_binary_libusb.py -k 3 /dev/null
> 
>     Please note that this is not tested at all.
> 
> I decided to give that a try, but all commands fail with this error message:
> 
> $ python2 ./gnuk_put_binary_libusb.py -k 0 /dev/null
> Device:
> Configuration: 1
> Interface: 0
> Traceback (most recent call last):
>   File "./gnuk_put_binary_libusb.py", line 110, in <module>
>     main(fileid, is_update, data, passwd)
>   File "./gnuk_put_binary_libusb.py", line 61, in main
>     compare(data, data_in_device)
>   File "/home/remy/repo/gnuk/tool/gnuk_token.py", line 568, in compare
>     raise ValueError("verify failed")
> ValueError: verify failed

It is normal to see those errors of "verify failed"; While data from
/dev/null is nothing, data_in_device has something.

> Before and After, I ran this script:
> https://gist.github.com/RaymiiOrg/04e25faf276c594950768fcc82514695
> <https://gist.github.com/RaymiiOrg/04e25faf276c594950768fcc82514695>
> 
> The print of data_in_device gives the same output for the key ID's 0-3.
> 0 is a different key than 1-3, those are the same.

I don't understand this sentence.  It is better to show me the exact
outputs of before and after.  Please.

It is expected to have two-byte of zero after the invocation of
'gnuk_put_binary_libusb.py -k 0 /dev/null' for key 0,
'gnuk_put_binary_libusb.py -k 1 /dev/null' for key 1,
'gnuk_put_binary_libusb.py -k 2 /dev/null' for key 2.  Then, the
invocation 'gnuk_put_binary_libusb.py -k 3 /dev/null' will erase the
page of public keys (all 0xff).

> Could you make a (python) script for the removal of upgrade keys? I'd be
> happy to test it.

It will be same as doing:

 ./tool/gnuk_put_binary_libusb.py -k 0 /dev/null
 ./tool/gnuk_put_binary_libusb.py -k 1 /dev/null
 ./tool/gnuk_put_binary_libusb.py -k 2 /dev/null
 ./tool/gnuk_put_binary_libusb.py -k 3 /dev/null

without verifying the data.

> I think the gpg as the regular user did work, because I found the
> correct keygrip. The following command hosed the nitrokey:
> 
> python2 ./gnuk_upgrade.py -k CB1522E739DD4E26F86EBC732B58AFBDA3059107
> ../regnual/regnual.bin ../src/build/gnuk.bin
> 
> 20001400:20004a00
> Downloading flash upgrade program...
> start 20001400
> end   20002500
> Run flash upgrade program...
> Wait 3 seconds...
> Traceback (most recent call last):
>   File "./gnuk_upgrade.py", line 149, in <module>
>     main(keyno, keygrip, data_regnual, data_upgrade[4096:])
>   File "./gnuk_upgrade.py", line 122, in main
>     mem_info = reg.mem_info()
> AttributeError: 'NoneType' object has no attribute 'mem_info'
> 
> 
> The light on the key was blinking on and off.

Then, reGNUal works somehow.  I don't know if reGNUal's USB worked
well or not.  Do you still run your PC?  What output of dmesg, can you
see before the time of 142898.997643?

If you can't see the USB detection, we would need some fix for
Nitrokey Start to support USB upgrade.

If it is just a timing issue (3 seconds is not enough),
upgrade_by_passwd.py has an improvement to wait the device detection
(while gnuk_upgrade.py has not updated).

> I removed and reinsterted the device since it wans't responding to
> other scripts, now dmesg says this:
> 
> [142898.997643] usb 1-1.1: USB disconnect, device number 7
> [142900.418569] usb 1-1.1: new full-speed USB device number 8 using ehci-pci
> [145925.226816] usb 1-1-port1: disabled by hub (EMI?), re-enabling...
> [145925.226825] usb 1-1.1: USB disconnect, device number 8
> [145925.415819] usb 1-1.1: new low-speed USB device number 9 using ehci-pci
> [145925.482493] usb 1-1.1: device descriptor read/64, error -32
> [145925.652492] usb 1-1.1: device descriptor read/64, error -32
> [145925.822490] usb 1-1.1: new low-speed USB device number 10 using ehci-pci
> [145925.889142] usb 1-1.1: device descriptor read/64, error -32
> [145926.059140] usb 1-1.1: device descriptor read/64, error -32
> [145926.229143] usb 1-1.1: new low-speed USB device number 11 using ehci-pci
> [145926.635801] usb 1-1.1: device not accepting address 11, error -32
> [145926.702460] usb 1-1.1: new low-speed USB device number 12 using ehci-pci
> [145927.109124] usb 1-1.1: device not accepting address 12, error -32
> [145927.109354] usb 1-1-port1: unable to enumerate USB device
> 
> It's also gone from lsusb.

Gnuk erased all pages (other than the first few pages) of MCU before
giving control to reGNUal.

Thank you for your experiment.  You are brave.

Since my brain is not that good, especially in summer, my guesses
above are perhaps partially wrong.
-- 