[Gnuk-users] Upgrading gnuk on a nitrokey start

Thu Aug 18 16:55:47 UTC 2016

On Thu, Aug 18, 2016 at 7:58 AM, NIIBE Yutaka <gniibe at fsij.org> wrote:

> 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.
>

I think I messed up some steps as well, for example, uploading the wrong
keys in three of the four slots. I did also boot up a live CD with Ubuntu
because I suspected my libusb and python versions were too new on Arch. In
the end it all worked on Arch after I added the dbus permissions and used
the regular user account. Except for some times when pcscd restarted itself
and took control of the token.

>
> 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.
>

The output of:

data_in_device = gnuk.cmd_read_binary(fileid)
print(data_in_device)

before and after the commands for key 0 was:

array('B', [212, 53, 156, 129, 194, 146, 131, 155, 213, 187, 122, 61, 104,
171, 143, 147, 16, 220, 77, 157, 194, 19, 118, 111, 110, 10, 113, 67, 245,
50, 97, 156, 89, 9, 71, 182, 98, 18, 60, 28, 199, 114, 209, 23, 72, 73,
158, 108, 229, 146, 180, 206, 0, 53, 4, 192, 200, 129, 98, 41, 154, 241,
183, 211, 51, 217, 89, 183, 158, 81, 117, 141, 108, 78, 60, 205, 217, 186,
81, 181, 50, 46, 147, 246, 17, 220, 53, 156, 8, 229, 174, 162, 55, 231, 88,
52, 155, 234, 4, 120, 26, 5, 61, 221, 33, 163, 46, 124, 5, 182, 132, 44,
21, 86, 137, 100, 86, 37, 35, 128, 23, 211, 81, 143, 213, 159, 37, 189,
188, 155, 32, 142, 175, 169, 115, 40, 128, 140, 205, 178, 24, 170, 177, 28,
242, 104, 223, 220, 224, 221, 100, 51, 100, 232, 221, 152, 18, 237, 145,
14, 132, 165, 188, 199, 36, 98, 253, 11, 157, 164, 102, 58, 106, 92, 58,
17, 88, 166, 166, 118, 202, 114, 102, 132, 248, 105, 60, 10, 218, 66, 133,
137, 110, 6, 45, 24, 170, 14, 132, 149, 244, 81, 0, 87, 228, 180, 30, 92,
149, 134, 92, 160, 154, 182, 7, 240, 193, 114, 159, 4, 9, 225, 92, 246,
177, 58, 108, 188, 53, 124, 88, 22, 122, 0, 155, 48, 61, 7, 134, 141, 40,
121, 104, 206, 159, 151, 229, 227, 241, 253, 227, 139, 110, 109, 12, 191])

For key 1-3 I don't have the output in my scrollback anymore.

>
> 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?
>

This:

[10978.547877] wlp3s0: authentication with fa:8f:ca:54:8d:12 timed out
[10986.526488] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[11011.497347] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[11014.721191] wlp3s0: authenticate with 34:31:c4:8e:d9:4c
[11014.723742] wlp3s0: send auth to 34:31:c4:8e:d9:4c (try 1/3)
[11014.809521] wlp3s0: authenticated
[11014.810153] wlp3s0: associate with 34:31:c4:8e:d9:4c (try 1/3)
[11014.829753] wlp3s0: RX AssocResp from 34:31:c4:8e:d9:4c (capab=0x411
status=0 aid=1)
[11014.849389] wlp3s0: associated
[11014.849513] IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes ready
[11014.909665] wlp3s0: Limiting TX power to 20 (23 - 3) dBm as advertised
by 34:31:c4:8e:d9:4c
[34439.950737] perf: interrupt took too long (5281 > 5185), lowering
kernel.perf_event_max_sample_rate to 37800
[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...

but I;m not sure if that's related.

>
> 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 did find a thread somewhere where it was advised to change the sleep in
this script to 10 seconds. Would that have helped?

> > 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.
>

So that part worked at least :). Now on to make the rest also work, and
after that test the 1.2.1 release!

>
> 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.
>

I do really appriciate the help and support, so thank you for that. I did
order the swd device (two actually) from aliexpress, so that will take at
least two weeks to get here. I also ordered two more nitrokey devices,
which will hopefully arrive sooner.

I'll document the process there and will use the password upgrade script at
first, before hosing it :)

> --
>
> _______________________________________________
> gnuk-users mailing list
> gnuk-users at lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/gnuk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/gnuk-users/attachments/20160818/a386aca5/attachment.html>