<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Aug 18, 2016 at 7:58 AM, NIIBE Yutaka <span dir="ltr"><<a href="mailto:gniibe@fsij.org" target="_blank">gniibe@fsij.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
I think that you went too fast.  Perhaps, I coundn't follow you<br>
correctly if you didn't show me each step of yours.<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><br>
On 08/18/2016 01:31 PM, Remy van Elst wrote:<br>
>     For (2), I think that it is possible to do so, or it is possible to<br>
>     write such a tool, in theory.  I'm saying because I once implement the<br>
>     removal feature of upgrade RSA public key in Gnuk.  Nobody has tried<br>
>     that.  IIUC, it is somehow likely that this sequence would work:<br>
><br>
>     ./tool/gnuk_put_binary_libusb.<wbr>py -k 0 /dev/null<br>
>     ./tool/gnuk_put_binary_libusb.<wbr>py -k 1 /dev/null<br>
>     ./tool/gnuk_put_binary_libusb.<wbr>py -k 2 /dev/null<br>
>     ./tool/gnuk_put_binary_libusb.<wbr>py -k 3 /dev/null<br>
><br>
>     Please note that this is not tested at all.<br>
><br>
> I decided to give that a try, but all commands fail with this error message:<br>
><br>
> $ python2 ./gnuk_put_binary_libusb.py -k 0 /dev/null<br>
> Device:<br>
> Configuration: 1<br>
> Interface: 0<br>
> Traceback (most recent call last):<br>
>   File "./gnuk_put_binary_libusb.py", line 110, in <module><br>
>     main(fileid, is_update, data, passwd)<br>
>   File "./gnuk_put_binary_libusb.py", line 61, in main<br>
>     compare(data, data_in_device)<br>
>   File "/home/remy/repo/gnuk/tool/<wbr>gnuk_token.py", line 568, in compare<br>
>     raise ValueError("verify failed")<br>
> ValueError: verify failed<br>
<br>
</span>It is normal to see those errors of "verify failed"; While data from<br>
/dev/null is nothing, data_in_device has something.<br>
<span class=""><br>
> Before and After, I ran this script:<br>
> <a href="https://gist.github.com/RaymiiOrg/04e25faf276c594950768fcc82514695" rel="noreferrer" target="_blank">https://gist.github.com/<wbr>RaymiiOrg/<wbr>04e25faf276c594950768fcc825146<wbr>95</a><br>
> <<a href="https://gist.github.com/RaymiiOrg/04e25faf276c594950768fcc82514695" rel="noreferrer" target="_blank">https://gist.github.com/<wbr>RaymiiOrg/<wbr>04e25faf276c594950768fcc825146<wbr>95</a>><br>
><br>
> The print of data_in_device gives the same output for the key ID's 0-3.<br>
> 0 is a different key than 1-3, those are the same.<br>
<br>
</span>I don't understand this sentence.  It is better to show me the exact<br>
outputs of before and after.  Please.<br></blockquote><div><br></div><div>The output of:<br><br></div><div>data_in_device = gnuk.cmd_read_binary(fileid)<br>print(data_in_device)<br><br></div><div>before and after the commands for key 0 was:<br><br>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])<br><br></div><div>For key 1-3 I don't have the output in my scrollback anymore.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
It is expected to have two-byte of zero after the invocation of<br>
'gnuk_put_binary_libusb.py -k 0 /dev/null' for key 0,<br>
'gnuk_put_binary_libusb.py -k 1 /dev/null' for key 1,<br>
'gnuk_put_binary_libusb.py -k 2 /dev/null' for key 2.  Then, the<br>
invocation 'gnuk_put_binary_libusb.py -k 3 /dev/null' will erase the<br>
page of public keys (all 0xff).<br>
<span class=""><br>
> Could you make a (python) script for the removal of upgrade keys? I'd be<br>
> happy to test it.<br>
<br>
</span>It will be same as doing:<br>
<span class=""><br>
 ./tool/gnuk_put_binary_libusb.<wbr>py -k 0 /dev/null<br>
 ./tool/gnuk_put_binary_libusb.<wbr>py -k 1 /dev/null<br>
 ./tool/gnuk_put_binary_libusb.<wbr>py -k 2 /dev/null<br>
 ./tool/gnuk_put_binary_libusb.<wbr>py -k 3 /dev/null<br>
<br>
</span>without verifying the data.<br>
<span class=""><br>
> I think the gpg as the regular user did work, because I found the<br>
> correct keygrip. The following command hosed the nitrokey:<br>
><br>
> python2 ./gnuk_upgrade.py -k CB1522E739DD4E26F86EBC732B58AF<wbr>BDA3059107<br>
> ../regnual/regnual.bin ../src/build/gnuk.bin<br>
><br>
> 20001400:20004a00<br>
> Downloading flash upgrade program...<br>
> start 20001400<br>
> end   20002500<br>
> Run flash upgrade program...<br>
> Wait 3 seconds...<br>
> Traceback (most recent call last):<br>
>   File "./gnuk_upgrade.py", line 149, in <module><br>
>     main(keyno, keygrip, data_regnual, data_upgrade[4096:])<br>
>   File "./gnuk_upgrade.py", line 122, in main<br>
>     mem_info = reg.mem_info()<br>
> AttributeError: 'NoneType' object has no attribute 'mem_info'<br>
><br>
><br>
> The light on the key was blinking on and off.<br>
<br>
</span>Then, reGNUal works somehow.  I don't know if reGNUal's USB worked<br>
well or not.  Do you still run your PC?  What output of dmesg, can you<br>
see before the time of 142898.997643?<br></blockquote><div><br></div><div>This:<br><br>[10978.547877] wlp3s0: authentication with fa:8f:ca:54:8d:12 timed out<br>[10986.526488] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready<br>[11011.497347] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready<br>[11014.721191] wlp3s0: authenticate with 34:31:c4:8e:d9:4c<br>[11014.723742] wlp3s0: send auth to 34:31:c4:8e:d9:4c (try 1/3)<br>[11014.809521] wlp3s0: authenticated<br>[11014.810153] wlp3s0: associate with 34:31:c4:8e:d9:4c (try 1/3)<br>[11014.829753] wlp3s0: RX AssocResp from 34:31:c4:8e:d9:4c (capab=0x411 status=0 aid=1)<br>[11014.849389] wlp3s0: associated<br>[11014.849513] IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes ready<br>[11014.909665] wlp3s0: Limiting TX power to 20 (23 - 3) dBm as advertised by 34:31:c4:8e:d9:4c<br>[34439.950737] perf: interrupt took too long (5281 > 5185), lowering kernel.perf_event_max_sample_rate to 37800<br>[142898.997643] usb 1-1.1: USB disconnect, device number 7<br>[142900.418569] usb 1-1.1: new full-speed USB device number 8 using ehci-pci<br>[145925.226816] usb 1-1-port1: disabled by hub (EMI?), re-enabling...<br><br><br></div><div>but I;m not sure if that's related. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If you can't see the USB detection, we would need some fix for<br>
Nitrokey Start to support USB upgrade.<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If it is just a timing issue (3 seconds is not enough),<br>
upgrade_by_passwd.py has an improvement to wait the device detection<br>
(while gnuk_upgrade.py has not updated).<br>
<span class=""><br></span></blockquote><div><br></div><div>I did find a thread somewhere where it was advised to change the sleep in this script to 10 seconds. Would that have helped?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
> I removed and reinsterted the device since it wans't responding to<br>
> other scripts, now dmesg says this:<br>
><br>
> [142898.997643] usb 1-1.1: USB disconnect, device number 7<br>
> [142900.418569] usb 1-1.1: new full-speed USB device number 8 using ehci-pci<br>
> [145925.226816] usb 1-1-port1: disabled by hub (EMI?), re-enabling...<br>
> [145925.226825] usb 1-1.1: USB disconnect, device number 8<br>
> [145925.415819] usb 1-1.1: new low-speed USB device number 9 using ehci-pci<br>
> [145925.482493] usb 1-1.1: device descriptor read/64, error -32<br>
> [145925.652492] usb 1-1.1: device descriptor read/64, error -32<br>
> [145925.822490] usb 1-1.1: new low-speed USB device number 10 using ehci-pci<br>
> [145925.889142] usb 1-1.1: device descriptor read/64, error -32<br>
> [145926.059140] usb 1-1.1: device descriptor read/64, error -32<br>
> [145926.229143] usb 1-1.1: new low-speed USB device number 11 using ehci-pci<br>
> [145926.635801] usb 1-1.1: device not accepting address 11, error -32<br>
> [145926.702460] usb 1-1.1: new low-speed USB device number 12 using ehci-pci<br>
> [145927.109124] usb 1-1.1: device not accepting address 12, error -32<br>
> [145927.109354] usb 1-1-port1: unable to enumerate USB device<br>
><br>
> It's also gone from lsusb.<br>
<br>
</span>Gnuk erased all pages (other than the first few pages) of MCU before<br>
giving control to reGNUal.<br></blockquote><div><br>So that part worked at least :). Now on to make the rest also work, and after that test the 1.2.1 release! <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thank you for your experiment.  You are brave.<br>
<br>
Since my brain is not that good, especially in summer, my guesses<br>
above are perhaps partially wrong.<br></blockquote><div><br></div><div>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.<br><br></div><div>I'll document the process there and will use the password upgrade script at first, before hosing it :)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><font color="#888888">--<br>
</font></span><div class=""><div class="h5"><br>
______________________________<wbr>_________________<br>
gnuk-users mailing list<br>
<a href="mailto:gnuk-users@lists.alioth.debian.org">gnuk-users@lists.alioth.<wbr>debian.org</a><br>
<a href="https://lists.alioth.debian.org/mailman/listinfo/gnuk-users" rel="noreferrer" target="_blank">https://lists.alioth.debian.<wbr>org/mailman/listinfo/gnuk-<wbr>users</a><br>
</div></div></blockquote></div><br></div></div>