<div dir="ltr"><br>
<div class="gmail_extra"><div class="gmail_quote">On Thu, Aug 18, 2016 at 4:30 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"><span>On 08/16/2016 10:25 PM, Remy van Elst wrote:<br>
> Please note that we use reGNUal in teh upgrading process. The setting<br>
> of permission with your USB ID is requires for reGNUal too.<br>
><br>
><br>
> Even if I do it as the root user?<br>
<br>
</span>If it's a simple POSIX sytem, root means full privilege, that's true.<br>
<span><br></span></blockquote><div><br></div><div>I did place the udev rules and are now able to execute the commands as the regular user.<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>
> I didn't see a specific compile option for regnual for a different<br>
> vidpid like in gnuk's configure script.<br>
<br>
</span>ReGNUal shares the configuration of Gnuk proper.<br>
<span><br>
> Is there a way to see which keys are currently in there? And, is it<br>
> possible to remove those keys if they are written? Does the<br>
> 'gnuk_remove_keys_libusb.py' also clean up those keys?<br>
<br>
</span>(1) No. (2) Difficult (nobody has tried). (3) No.<br>
<br>
For (1), it is possible to write such a tool. Nobody has tried that.<br>
By using tool/gnuk_token.py and the method cmd_read_binary, it is<br>
possible to write such a tool.<br>
<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></blockquote><div>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></div><div>Before and After, I ran this script: <a href="https://gist.github.com/RaymiiOrg/04e25faf276c594950768fcc82514695" target="_blank">https://gist.github.com/<wbr>RaymiiOrg/<wbr>04e25faf276c594950768fcc825146<wbr>95</a><br><br></div><div>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. <br><br></div><div>Could you make a (python) script for the removal of upgrade keys? I'd be happy to test 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">
<br>
'gnuk_remove_keys_libusb.py' is a tool to remove the RSA private keys<br>
(not RSA public key for upgrade).<br>
<span><br>
> When trying the upgrade with password script, this happens:<br>
><br>
> $ sudo python2 ./upgrade_by_passwd.py -f -k 4 ../regnual/regnual.bin<br>
> ../src/build/gnuk.bin<br>
> ../regnual/regnual.bin: 4372<br>
> ../src/build/gnuk.bin: 110592<br>
> CRC32: 8d82b2df<br>
><br>
> Device:<br>
> Configuration: 1<br>
> Interface: 0<br>
> Traceback (most recent call last):<br>
> File "./upgrade_by_passwd.py", line 130, in <module><br>
> main(wait_e, keyno, passwd, data_regnual, data_upgrade[4096:])<br>
> File "./upgrade_by_passwd.py", line 48, in main<br>
> gnuk.cmd_write_binary(1+<wbr>keyno, rsa_raw_pubkey, False)<br>
> File "/home/remy/repo/gnuk/tool/gnu<wbr>k_token.py", line 288, in<br>
> cmd_write_binary<br>
> raise ValueError("cmd_write_binary 1", "%02x%02x" % (sw[0], sw[1]))<br>
> ValueError: ('cmd_write_binary 1', '6581')<br>
<br>
</span>-k is only valid with 0 to 3.<br>
<div><div><br>
> $ sudo python2 ./upgrade_by_passwd.py -f -k 3 ../regnual/regnual.bin<br>
> ../src/build/gnuk.bin<br>
> ../regnual/regnual.bin: 4372<br>
> ../src/build/gnuk.bin: 110592<br>
> CRC32: 8d82b2df<br>
><br>
> Device:<br>
> Configuration: 1<br>
> Interface: 0<br>
> Traceback (most recent call last):<br>
> File "./upgrade_by_passwd.py", line 130, in <module><br>
> main(wait_e, keyno, passwd, data_regnual, data_upgrade[4096:])<br>
> File "./upgrade_by_passwd.py", line 48, in main<br>
> gnuk.cmd_write_binary(1+<wbr>keyno, rsa_raw_pubkey, False)<br>
> File "/home/remy/repo/gnuk/tool/gnu<wbr>k_token.py", line 288, in<br>
> cmd_write_binary<br>
> raise ValueError("cmd_write_binary 1", "%02x%02x" % (sw[0], sw[1]))<br>
> ValueError: ('cmd_write_binary 1', '6581')<br>
><br>
> $ sudo python2 ./upgrade_by_passwd.py -f -k 2 ../regnual/regnual.bin<br>
> ../src/build/gnuk.bin<br>
> ../regnual/regnual.bin: 4372<br>
> ../src/build/gnuk.bin: 110592<br>
> CRC32: 8d82b2df<br>
><br>
> Device:<br>
> Configuration: 1<br>
> Interface: 0<br>
> Traceback (most recent call last):<br>
> File "./upgrade_by_passwd.py", line 130, in <module><br>
> main(wait_e, keyno, passwd, data_regnual, data_upgrade[4096:])<br>
> File "./upgrade_by_passwd.py", line 48, in main<br>
> gnuk.cmd_write_binary(1+<wbr>keyno, rsa_raw_pubkey, False)<br>
> File "/home/remy/repo/gnuk/tool/gnu<wbr>k_token.py", line 288, in<br>
> cmd_write_binary<br>
> raise ValueError("cmd_write_binary 1", "%02x%02x" % (sw[0], sw[1]))<br>
> ValueError: ('cmd_write_binary 1', '6581')<br>
><br>
><br>
> $ sudo python2 ./upgrade_by_passwd.py -f -k 1 ../regnual/regnual.bin<br>
> ../src/build/gnuk.bin<br>
> ../regnual/regnual.bin: 4372<br>
> ../src/build/gnuk.bin: 110592<br>
> CRC32: 8d82b2df<br>
><br>
> Device:<br>
> Configuration: 1<br>
> Interface: 0<br>
> Traceback (most recent call last):<br>
> File "./upgrade_by_passwd.py", line 130, in <module><br>
> main(wait_e, keyno, passwd, data_regnual, data_upgrade[4096:])<br>
> File "./upgrade_by_passwd.py", line 48, in main<br>
> gnuk.cmd_write_binary(1+<wbr>keyno, rsa_raw_pubkey, False)<br>
> File "/home/remy/repo/gnuk/tool/gnu<wbr>k_token.py", line 288, in<br>
> cmd_write_binary<br>
> raise ValueError("cmd_write_binary 1", "%02x%02x" % (sw[0], sw[1]))<br>
> ValueError: ('cmd_write_binary 1', '6581')<br>
<br>
</div></div>I think that it's not good to proceed after a failure. Some failure is not<br>
recoverable.<br>
<br>
If those failures are real, there is no way to recover from here,<br>
other than the (2) method I described above, which nobody has tried.<br>
<br>
I don't know the reason why the invocation of upgrade_by_passwd.py<br>
fails in that way. If it had already filled by a public key, it's<br>
possible. If not, it's new failure mode for me.<br>
<span><br></span></blockquote><div><br></div><div>I think because the four slots are filled with a key already.<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>
> When I try the normal upgrade script, this is the output:<br>
><br>
> $ sudo python2 ./gnuk_upgrade.py -k<br>
> CB1522E739DD4E26F86EBC732B58AF<wbr>BDA3059107 ../regnual/regnual.bin<br>
> ../src/build/gnuk.bin<br>
> ../regnual/regnual.bin: 4372<br>
> ../src/build/gnuk.bin: 110592<br>
> CRC32: 8d82b2df<br>
<br>
</span>No, it's not "normal upgrade script" at all. It was a tool for my<br>
experiment, not useful after we have upgrade_by_passwd.py. It is only<br>
useful if you successfully registered a public key to Gnuk Token, and<br>
the private counter part is under control of gpg-agent.<br>
<span><br>
> Device:<br>
> Configuration: 1<br>
> Interface: 0<br>
> Traceback (most recent call last):<br>
> File "./gnuk_upgrade.py", line 148, in <module><br>
> main(keyno, keygrip, data_regnual, data_upgrade[4096:])<br>
> File "./gnuk_upgrade.py", line 95, in main<br>
> signed = gpg_sign(keygrip, binascii.hexlify(challenge))<br>
> File "./gnuk_upgrade.py", line 64, in gpg_sign<br>
> pos = signed.index("D (7:sig-val(3:rsa(1:s256:") + 26<br>
> ValueError: substring not found<br>
<br>
</span>I think that there are two (or more) possibilities for this failure.<br>
<br>
It fails because the key CB1522E739DD4E26F86EBC732B58AF<wbr>BDA3059107 is<br>
not under control of gpg-agent or it fails to sign (because of sudo).<br>
<br>
Have you asked a passphrase for the key?<br>
<br>
Another obvious bug (which I found now) is that it only works 50%.<br>
If the top-bit is 1, the result will be<br>
<br>
D (7:sig-val(3:rsa(1:s257:...<br>
<br>
So, it fails.<br>
<span><br>
> If there is no way to see or wipe the current keys for firmware update<br>
> via USB, is there another way to reset the token fully?<br>
<br>
</span>See (2) for the public key of firmware upgrade. Please note that I<br>
don't know this feature is supported by Nitrokey Start's build of<br>
Gnuk.<br>
<br>
For resetting the token fully, we need SWD debugger.<br>
<span><font color="#888888">--<br></font></span></blockquote><div><br></div><div>I think the gpg as the regular user did work, because I found the correct keygrip. The following command hosed the nitrokey:<br><br>python2 ./gnuk_upgrade.py -k CB1522E739DD4E26F86EBC732B58AFBDA3059107 ../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></div><div>The light on the key was blinking on and off. I removed and reinsterted the device since it wans't responding to 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></div><div>It's also gone from lsusb.<br><br></div><div>I'm going to order an swd device :)<br><br></div><div>Thanks for the help so far, and when I've got the swd device I'll be back with more information.<br></div><div><br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><font color="#888888">
</font></span><div><div><br>
______________________________<wbr>_________________<br>
gnuk-users mailing list<br>
<a href="mailto:gnuk-users@lists.alioth.debian.org" target="_blank">gnuk-users@lists.alioth.debian<wbr>.org</a><br>
<a href="https://lists.alioth.debian.org/mailman/listinfo/gnuk-users" rel="noreferrer" target="_blank">https://lists.alioth.debian.or<wbr>g/mailman/listinfo/gnuk-users</a><br>
</div></div></blockquote></div><br></div></div>