From jeremydrake+gnuk at eacceleration.com Thu Jan 3 02:29:32 2019 From: jeremydrake+gnuk at eacceleration.com (Jeremy Drake) Date: Wed, 2 Jan 2019 17:29:32 -0800 (PST) Subject: Distribution of binary In-Reply-To: References: <87zhtcdc7k.fsf@iwagami.gniibe.org> <8ed318e1-6048-7f1e-b2f1-fae1e30188c4@digitalbrains.com> <871s6cpfzr.fsf@wheatstone.g10code.de> Message-ID: On Thu, 20 Dec 2018, Peter Lebbing wrote: > On 20/12/2018 12:58, Werner Koch wrote: >> May I suggest to use 1209:2440 for such uses? > > Oh, that's a good solution, thanks! That way there's no way the FSIJ > will get sullied by people not observing their conditions. Also, with as long as this discussion of how to properly exercise freedom 2 of the essential freedoms [1] has gone on, I was beginning to wonder if this truly qualified as "free software" ;) > So what should be the strings for vendor and product? > > Suggestions for vendor string: > pid.codes > GnuPG e.V. > Private > None > > (I mean the literal string "None") I would suggest something generic here, like "Open Source Developer" > Suggestions for product string: > GnuK Token > An OpenPGP Token > > With the first product string, Niibe's udev match on product string[1] > will catch this device. I would vote for the more specific option here, namely "GnuK Token", given that the string is stored in the device itself. If we were talking about adding to usb.ids, I would swap which should be generic and which should be specific, and vote for "GnuPG e.V."/"An OpenPGP Token" as these strings are given to any device with that VID:PID. > Note that the current code of GnuK will choose these strings based on a > user-supplied VID:PID. So the strings will always be the same for the > supplied VID:PID. It would require code changes to implement "If the > GnuPG e.V. is spreading them, choose that as vendor, otherwise choose > 'Private'". Anyone who wants to distribute binaries (or by extension hardware) with different strings need only modify GNUK_USB_DEVICE_ID text file at the root of the source tree, IIRC. I believe that some software "knows" the 234b:0001 VID:PID, and should be taught that 1209:2440 should be treated the same. Off the top of my head, the udev rules which have already been mentioned, plus libccid [2] and OpenKeychain [3]. [1] https://www.gnu.org/philosophy/free-sw.en.html [2] https://salsa.debian.org/rousseau/CCID/tree/master/readers [3] https://github.com/open-keychain/open-keychain/blob/894bac6c8df2e651369afc8e0aef4e17779c4de6/OpenKeychain/src/main/java/org/sufficientlysecure/keychain/securitytoken/usb/UsbTransport.java#L70 From jeremydrake+gnuk at eacceleration.com Thu Jan 3 02:31:44 2019 From: jeremydrake+gnuk at eacceleration.com (Jeremy Drake) Date: Wed, 2 Jan 2019 17:31:44 -0800 (PST) Subject: U2F and nRF52840 In-Reply-To: <87k1jwzsi4.fsf@iwagami.gniibe.org> References: <87k1jwzsi4.fsf@iwagami.gniibe.org> Message-ID: >> If not, how (in)compatible is the current code with a possible U2F/UAF >> implementation? > > Crypto routines can be reused. The USB protocol, CCID, is same. (CCID > protocol is the protocol of card reader.) Application layer is > different. Is it? I haven't looked too closely, but I was under the impression that U2F was implemented as a HID device rather than CCID/"smartcard". From peter at digitalbrains.com Thu Jan 3 12:25:52 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 3 Jan 2019 12:25:52 +0100 Subject: Distribution of binary In-Reply-To: References: <87zhtcdc7k.fsf@iwagami.gniibe.org> <8ed318e1-6048-7f1e-b2f1-fae1e30188c4@digitalbrains.com> <871s6cpfzr.fsf@wheatstone.g10code.de> Message-ID: <25f2a63f-4830-ec28-2c24-d462536ff6e4@digitalbrains.com> Hello Jeremy, On 03/01/2019 02:29, Jeremy Drake wrote: > Also, with as long as this discussion of how to properly exercise > freedom 2 of the essential freedoms [1] has gone on, I was beginning > to wonder if this truly qualified as "free software" ;) I'm happy with the outcome that there is an easier to use VID:PID for the GnuK, but I feel this misrepresents the situation. Or in two words: I disagree. I see the smiley there, but I'd still like to present a differing view. First of all, it's the USB-IF that is causing problems here, not the FSIJ or GnuK. The USB-IF has these unfree requirements on use of "their" identifiers. I think I misphrased when I wrote "sullying the FSIJ", it should have been "getting the FSIJ into trouble". The GPL uses copyright law as the framework to shape the licence. I think there are many jurisdictions where copyright law doesn't cover one or two 16-bit identifiers, so I suspect you need to be well acquainted with the law to exactly say how GPL interacts with identifiers. Interoperability however /is/ partly about identifiers, and in several jurisdictions you are allowed to make an interoperable implementation. But if you want to go down that road, you need to sue the USB-IF over their "licence" on the identifiers, because I'm sure in the current situation they will not agree unless forced to do so by a court. I don't think many people would be willing to spend the money and effort required to go to court over this, so that's not likely to happen. I also doubt a court would even be willing to rule against the USB-IF anyway. But free software is also about intent and practical consequences and spirit and not just the law. That same page[1] also mentions: | Thus, it is acceptable for the license to require that you change the | name of the modified version, remove a logo, or identify your | modifications as yours. Now this gets more into trademark than copyright, and we see that they do allow you to limit redistribution of this type of data. It does however continue | As long as these requirements are not so burdensome that they | effectively hamper you from releasing your changes, they are | acceptable; [...] and without an alternative to the FSIJ VID:PID, it indeed gets slightly murky (but this unwelcome situation is forced by the USB-IF, not the FSIJ or GnuK). There are two conflicting rulesets here: on the one hand the contract with USB-IF and on the other hand free software. If you believe free software licences should extend to usage of VID:PID pairs, this quickly leads to the stalemate that it becomes impossible to have a free USB device when it is using the identifiers of a company still under contract with the USB-IF. Note that the USB-IF doesn't condone the use of the pid.codes range; they simply can't do much about it either. The contract under which they were allocated is with a company that doesn't exist anymore. In an ideal world, the whole industry would have agreed on a different identification mechanism that uses identifiers that are not so tightly controlled by an organization selling them. Either randomly generated UUIDs or DNS labels (so you can create identifiers within the domain you own) or something like that[2]. Microsoft has done this for themselves with the Microsoft OS Descriptor. As I mentioned before, in an ideal world, this would have been the case from the onset. But I think UUID's weren't that commonly used when USB was originally developed, even though they already existed. > Anyone who wants to distribute binaries (or by extension hardware) > with different strings need only modify GNUK_USB_DEVICE_ID text file > at the root of the source tree, IIRC. Yes. Changing to a supported VID:PID is simply an argument to ./configure, this is checked for sanity (it's limited to the listed IDs), and is part of the regular build process. But also changing the associated strings requires editing GNUK_USB_DEVICE_ID in the source. This requires providing access to this modified source when you distribute. Other device strings would change as well: the revision string (USB string descriptor 4 currently) changes to "release/1.2.13-modified" or ""release/1.2.13-1-gabcdef0" (git commit object) instead of "release/1.2.13". And just like this change is not immediately evident, there might be more I'm not realizing. The actual change to the file is small. But it has implications. So that's why I think the better way to solve this if we were to suggest using different strings for a VID:PID, would be to change the code such that alternatives can be selected through ./configure. > I believe that some software "knows" the 234b:0001 VID:PID, and should > be taught that 1209:2440 should be treated the same. Off the top of > my head, the udev rules which have already been mentioned, plus > libccid [2] and OpenKeychain [3]. (234b:0001 is NeuG, you mean 234b:0000) I agree, good point. I get the sense the 1209:2440 VID:PID hasn't actually been used yet, it was still in the "we plan to do this" phase. I could be wrong though. It would be good if consumers of these ID's get to know about them by default. But the udev rule could also just match on "An OpenPGP Token" without considering the VID:PID. Regards, Peter. [1] https://www.gnu.org/philosophy/free-sw.en.html [2] Note that you can actually generate UUID's from DNS labels. They're just not that human-readable anymore. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From lists at georgweiss.de Thu Jan 3 13:22:53 2019 From: lists at georgweiss.de (lists at georgweiss.de) Date: Thu, 3 Jan 2019 13:22:53 +0100 Subject: neug on ST-link V2: usb errors Message-ID: Hi, I own multiple (also different hw versions) ST-Link V2 dongles and can flash/run gnuk on them. However if i try to run them with different versions of neug it will not be recognized as usb-device (most of the time). Occassionally if i try hard re-plugging the dongle it will be detected (also when i reset the STM32F103 chip via shortcut-ing NRST and VSSA as described in [1]) I tried 5 different dongles (which are running gnuk just fine) so i do not believe that it's a hardware issue. I would appreciate any suggestions. Compiling/Flashing was done in a debian (stretch) docker container: -- root at gnuk-13997:/test# cat VERSION release/1.0.9 root at gnuk-13997:/test/src# ./configure --vidpid=234b:0001 --target=ST_DONGLE --with-dfu root at gnuk-13997:/test# gcc --version gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 --- --flash-log--- root at gnuk-13997:/out# telnet localhost 4444 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Open On-Chip Debugger > reset halt target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x08000258 msp: 0x20005000 > stm32f1x unlock 0 device id = 0x20036410 flash size = 128kbytes target state: halted target halted due to breakpoint, current mode: Thread xPSR: 0x61000000 pc: 0x2000003a msp: 0x20005000 stm32x unlocked. INFO: a reset or power cycle is required for the new settings to take effect. > reset halt target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x08000258 msp: 0x20005000 > stm32f1x mass_erase 0 stm32x mass erase complete > flash write_bank 0 /out/neug.bin 0 target state: halted target halted due to breakpoint, current mode: Thread xPSR: 0x61000000 pc: 0x2000003a msp: 0x20005000 wrote 24612 bytes from file /out/neug.bin to flash bank 0 at offset 0x00000000 in 1.090145s (22.048 KiB/s) > reset run --- --dmesg--[st-link v2 dongle with neug]--- [ 5171.461872] usb 4-2: new full-speed USB device number 6 using ohci-pci [ 5171.602877] usb 4-2: device descriptor read/64, error -62 [ 5171.848884] usb 4-2: device descriptor read/64, error -62 [ 5172.091901] usb 4-2: new full-speed USB device number 7 using ohci-pci [ 5172.232905] usb 4-2: device descriptor read/64, error -62 [ 5172.480913] usb 4-2: device descriptor read/64, error -62 [ 5172.587958] usb usb4-port2: attempt power cycle [ 5173.035949] usb 4-2: new full-speed USB device number 8 using ohci-pci [ 5173.451957] usb 4-2: device not accepting address 8, error -62 [ 5173.587964] usb 4-2: new full-speed USB device number 9 using ohci-pci [ 5174.003990] usb 4-2: device not accepting address 9, error -62 [ 5174.004038] usb usb4-port2: unable to enumerate USB device [ 5178.264172] usb 4-2: new full-speed USB device number 10 using ohci-pci [ 5178.404185] usb 4-2: device descriptor read/64, error -62 [ 5178.648188] usb 4-2: device descriptor read/64, error -62 [ 5178.892201] usb 4-2: new full-speed USB device number 11 using ohci-pci [ 5179.032205] usb 4-2: device descriptor read/64, error -62 [ 5179.280217] usb 4-2: device descriptor read/64, error -62 [ 5179.388244] usb usb4-port2: attempt power cycle [ 5179.836243] usb 4-2: new full-speed USB device number 12 using ohci-pci [ 5180.252260] usb 4-2: device not accepting address 12, error -62 [ 5180.388246] usb 4-2: new full-speed USB device number 13 using ohci-pci [ 5180.804260] usb 4-2: device not accepting address 13, error -62 [ 5180.804275] usb usb4-port2: unable to enumerate USB device [ 5182.630367] usb 4-2: new full-speed USB device number 14 using ohci-pci [ 5182.792923] usb 4-2: New USB device found, idVendor=234b, idProduct=0001, bcdDevice= 2.00 [ 5182.792926] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 5182.792927] usb 4-2: Product: NeuG True RNG [ 5182.792929] usb 4-2: Manufacturer: Free Software Initiative of Japan [ 5182.792929] usb 4-2: SerialNumber: FSIJ-1.0.8-67105349 [ 5184.254048] usb 4-2: USB disconnect, device number 14 [ 5185.822486] usb 4-2: new full-speed USB device number 15 using ohci-pci [ 5185.962513] usb 4-2: device descriptor read/64, error -62 [ 5186.208523] usb 4-2: device descriptor read/64, error -62 [ 5186.452535] usb 4-2: new full-speed USB device number 16 using ohci-pci [ 5186.592546] usb 4-2: device descriptor read/64, error -62 [ 5186.840558] usb 4-2: device descriptor read/64, error -62 [ 5186.948573] usb usb4-port2: attempt power cycle --- --dmesg--[same st-link v2 dongle with gnuk]--- [ 8522.378992] usb 7-4: new full-speed USB device number 118 using ohci-pci [ 8522.550000] usb 7-4: New USB device found, idVendor=234b, idProduct=0000, bcdDevice= 2.00 [ 8522.550002] usb 7-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 8522.550003] usb 7-4: Product: Gnuk Token [ 8522.550005] usb 7-4: Manufacturer: Free Software Initiative of Japan [ 8522.550005] usb 7-4: SerialNumber: FSIJ-1.2.13-87201725 --- 1 - https://nx3d.org/gnuk-st-link-v2/ From peter at digitalbrains.com Thu Jan 3 15:58:27 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 3 Jan 2019 15:58:27 +0100 Subject: neug on ST-link V2: usb errors In-Reply-To: References: Message-ID: <0ef25a96-76fb-c1ed-6445-d9254d1c5fd2@digitalbrains.com> On 03/01/2019 13:22, lists at georgweiss.de wrote: > root at gnuk-13997:/test/src# ./configure --vidpid=234b:0001 > --target=ST_DONGLE --with-dfu It seems like you're using SWD to upload the binary, so --with-dfu will do the wrong thing: it will build an image to flash at an offset of 12 KiB from the start rather than one that begins right at the start. But for some reason, when I built NeuG for the Maple Mini, it also didn't come up. I might have done something trivial wrong, though, I stopped looking immediately. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From jeremydrake+gnuk at eacceleration.com Thu Jan 3 20:08:57 2019 From: jeremydrake+gnuk at eacceleration.com (Jeremy Drake) Date: Thu, 3 Jan 2019 11:08:57 -0800 (PST) Subject: Distribution of binary In-Reply-To: <87r2dt8tij.fsf@ponder.i-did-not-set--mail-host-address--so-tickle-me> References: <87zhtcdc7k.fsf@iwagami.gniibe.org> <8ed318e1-6048-7f1e-b2f1-fae1e30188c4@digitalbrains.com> <871s6cpfzr.fsf@wheatstone.g10code.de> <25f2a63f-4830-ec28-2c24-d462536ff6e4@digitalbrains.com> <87r2dt8tij.fsf@ponder.i-did-not-set--mail-host-address--so-tickle-me> Message-ID: > I'd also like to put out a wishlist request that it be possible to build > with a NULL/default VID:PID and other configurable strings > (GNUK_USB_DEVICE_ID) of a generated GnuK binary, so that distributions > such as Debian could ship a built GnuK image that user's can then > install on their device, injecting the appropriate VID:PID and perhaps > other settings while flashing to the device with a script of some kind. This has already been done for the VID:PID. * Major changes in Gnuk 1.2.8 Released 2018-01-23, by NIIBE Yutaka ** No inclusion of VID:PID in gnuk.elf Distribution of binary image with VID:PID would violate vendor ID agreement to USB Forum. Now, we have new file named gnuk-vidpid.elf for flashing. The file gnuk.elf can be used to generate gnuk-vidpid.elf and we can check if it is reproducible or not. * Major changes in Gnuk 1.2.10 Released 2018-05-10, by NIIBE Yutaka ** No inclusion of VID:PID in gnuk-no-vidpid.elf Now, we have new file named gnuk-no-vidpid.elf with no VID:PID. The file gnuk.elf has the VID:PID, like version 1.2.7 or older. From jeremydrake+gnuk at eacceleration.com Thu Jan 3 21:00:25 2019 From: jeremydrake+gnuk at eacceleration.com (Jeremy Drake) Date: Thu, 3 Jan 2019 12:00:25 -0800 (PST) Subject: Distribution of binary In-Reply-To: <87o98x8ql3.fsf@ponder.i-did-not-set--mail-host-address--so-tickle-me> References: <87zhtcdc7k.fsf@iwagami.gniibe.org> <8ed318e1-6048-7f1e-b2f1-fae1e30188c4@digitalbrains.com> <871s6cpfzr.fsf@wheatstone.g10code.de> <25f2a63f-4830-ec28-2c24-d462536ff6e4@digitalbrains.com> <87r2dt8tij.fsf@ponder.i-did-not-set--mail-host-address--so-tickle-me> <87o98x8ql3.fsf@ponder.i-did-not-set--mail-host-address--so-tickle-me> Message-ID: On Thu, 3 Jan 2019, Vagrant Cascadian wrote: > How do you take gnuk-no-vidpid.elf and turn it into something usable > with a VID:PID? Is there a script you can use to inject the VID:PID? Are > you expected to take a hex editor to it? ./configure generates a script which performs the modifications. > As far as I can tell, the way to produce an image with VID:PID included > still requires the GnuK source to build the flashable image? Maybe it's > just my lack of understanding (admittedly very rough), or a > documentation issue... I believe the way it currently stands you would need the GnuK source, but I don't think it would be difficult to isolate. From vagrant at debian.org Thu Jan 3 19:51:00 2019 From: vagrant at debian.org (Vagrant Cascadian) Date: Thu, 03 Jan 2019 10:51:00 -0800 Subject: Distribution of binary In-Reply-To: <25f2a63f-4830-ec28-2c24-d462536ff6e4@digitalbrains.com> References: <87zhtcdc7k.fsf@iwagami.gniibe.org> <8ed318e1-6048-7f1e-b2f1-fae1e30188c4@digitalbrains.com> <871s6cpfzr.fsf@wheatstone.g10code.de> <25f2a63f-4830-ec28-2c24-d462536ff6e4@digitalbrains.com> Message-ID: <87r2dt8tij.fsf@ponder.i-did-not-set--mail-host-address--so-tickle-me> On 2019-01-03, Peter Lebbing wrote: > On 03/01/2019 02:29, Jeremy Drake wrote: >> Anyone who wants to distribute binaries (or by extension hardware) >> with different strings need only modify GNUK_USB_DEVICE_ID text file >> at the root of the source tree, IIRC. > > Yes. Changing to a supported VID:PID is simply an argument to > ./configure, this is checked for sanity (it's limited to the listed > IDs), and is part of the regular build process. But also changing the > associated strings requires editing GNUK_USB_DEVICE_ID in the source. > This requires providing access to this modified source when you > distribute. Other device strings would change as well: the revision > string (USB string descriptor 4 currently) changes to > "release/1.2.13-modified" or ""release/1.2.13-1-gabcdef0" (git commit > object) instead of "release/1.2.13". And just like this change is not > immediately evident, there might be more I'm not realizing. > > The actual change to the file is small. But it has implications. > > So that's why I think the better way to solve this if we were to suggest > using different strings for a VID:PID, would be to change the code such > that alternatives can be selected through ./configure. I'd also like to put out a wishlist request that it be possible to build with a NULL/default VID:PID and other configurable strings (GNUK_USB_DEVICE_ID) of a generated GnuK binary, so that distributions such as Debian could ship a built GnuK image that user's can then install on their device, injecting the appropriate VID:PID and perhaps other settings while flashing to the device with a script of some kind. A few benefits of this approach off the top of my head: - Users uncomfortable with compiling software wouldn't have to - Reproducibile Builds testing could demonstrate integrity of the source to binary - Packages in Debian can have various QA tests done automatically live well, vagrant -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From vagrant at debian.org Thu Jan 3 20:54:16 2019 From: vagrant at debian.org (Vagrant Cascadian) Date: Thu, 03 Jan 2019 11:54:16 -0800 Subject: Distribution of binary In-Reply-To: References: <87zhtcdc7k.fsf@iwagami.gniibe.org> <8ed318e1-6048-7f1e-b2f1-fae1e30188c4@digitalbrains.com> <871s6cpfzr.fsf@wheatstone.g10code.de> <25f2a63f-4830-ec28-2c24-d462536ff6e4@digitalbrains.com> <87r2dt8tij.fsf@ponder.i-did-not-set--mail-host-address--so-tickle-me> Message-ID: <87o98x8ql3.fsf@ponder.i-did-not-set--mail-host-address--so-tickle-me> On 2019-01-03, Jeremy Drake wrote: >> I'd also like to put out a wishlist request that it be possible to build >> with a NULL/default VID:PID and other configurable strings >> (GNUK_USB_DEVICE_ID) of a generated GnuK binary, so that distributions >> such as Debian could ship a built GnuK image that user's can then >> install on their device, injecting the appropriate VID:PID and perhaps >> other settings while flashing to the device with a script of some kind. > > This has already been done for the VID:PID. > > * Major changes in Gnuk 1.2.8 > > Released 2018-01-23, by NIIBE Yutaka > > ** No inclusion of VID:PID in gnuk.elf > > Distribution of binary image with VID:PID would violate vendor ID > agreement to USB Forum. Now, we have new file named gnuk-vidpid.elf > for flashing. The file gnuk.elf can be used to generate > gnuk-vidpid.elf and we can check if it is reproducible or not. > > > * Major changes in Gnuk 1.2.10 > > Released 2018-05-10, by NIIBE Yutaka > > ** No inclusion of VID:PID in gnuk-no-vidpid.elf > Now, we have new file named gnuk-no-vidpid.elf with no VID:PID. The > file gnuk.elf has the VID:PID, like version 1.2.7 or older. Yes, at least that appears to be partly done... How do you take gnuk-no-vidpid.elf and turn it into something usable with a VID:PID? Is there a script you can use to inject the VID:PID? Are you expected to take a hex editor to it? As far as I can tell, the way to produce an image with VID:PID included still requires the GnuK source to build the flashable image? Maybe it's just my lack of understanding (admittedly very rough), or a documentation issue... live well, vagrant -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From ndk.clanbo at gmail.com Thu Jan 3 22:09:15 2019 From: ndk.clanbo at gmail.com (NdK) Date: Thu, 3 Jan 2019 22:09:15 +0100 Subject: U2F and nRF52840 In-Reply-To: References: <87k1jwzsi4.fsf@iwagami.gniibe.org> Message-ID: <1cf228cc-9b7b-21e5-f8ad-502ba0bc9742@gmail.com> On 03/01/19 02:31, Jeremy Drake via Gnuk-users wrote: > Is it?? I haven't looked too closely, but I was under the impression > that U2F was implemented as a HID device rather than CCID/"smartcard". You're right. U2F uses HID, not CCID. BYtE, Diego From gniibe at fsij.org Fri Jan 4 02:12:08 2019 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 04 Jan 2019 10:12:08 +0900 Subject: U2F and nRF52840 In-Reply-To: References: <87k1jwzsi4.fsf@iwagami.gniibe.org> Message-ID: <87a7kh445z.fsf@iwagami.gniibe.org> Jeremy Drake wrote: > Is it? I haven't looked too closely, but I was under the impression that > U2F was implemented as a HID device rather than CCID/"smartcard". Right. I was wrong. U2F defines three protocols (for Bluetooth, NFC and USB), and USB one is HID. Well, in Gnuk, there is an experimental implementation for HID protocol. The HID implementation in Gnuk is not general one, but very specific use. It was old experiment. I was considering using it to control (virtual) card of Gnuk, so that Gnuk can support multiple cards and a user can send command of "insert" / "remove" of card. -- From jeremydrake+gnuk at eacceleration.com Fri Jan 4 03:02:18 2019 From: jeremydrake+gnuk at eacceleration.com (Jeremy Drake) Date: Thu, 3 Jan 2019 18:02:18 -0800 (PST) Subject: U2F and nRF52840 In-Reply-To: <87k1jwzsi4.fsf@iwagami.gniibe.org> References: <87k1jwzsi4.fsf@iwagami.gniibe.org> Message-ID: On Wed, 26 Dec 2018, NIIBE Yutaka wrote: > If I will need to use U2F, I will implement another firmware software > using some parts of Gnuk (USB, CCID, and Crypto). > I think somebody else may have beaten you to it: https://github.com/gl-sergei/u2f-token From pablo1 at mailbox.org Thu Jan 10 07:50:06 2019 From: pablo1 at mailbox.org (Pablo Ovelleiro Corral) Date: Thu, 10 Jan 2019 07:50:06 +0100 Subject: Run Gnuk on NUCLEO F103RB Message-ID: <20190110065006.7wdxkhonbkcny5rs@kartoffel.localdomain> Hello, quick question regarding supported hardware: I saw the hardware requirement for Gnuk is the micro controller STM32F103. (https://wiki.debian.org/GNUK#Gnuk_Hardware). Will it run on one of this boards?: https://www.reichelt.de/nucleo-64-arm-cortex-m3-stm32-f1-serie-nucleo-f103rb-p154270.html?&trstct=pos_7 It is not listed explicitely in the hardware list, but I might get my hands on one of those for cheap and would like to know if I can use it for gnuk. The hardware list is pretty small in general, maybe it would be nice to expand it. Cheers, Pablo -- Pablo Ovelleiro Corral Web: http://pablo.tools XMPP: pablo1 at mailbox.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From gniibe at fsij.org Thu Jan 10 09:32:10 2019 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 10 Jan 2019 17:32:10 +0900 Subject: Run Gnuk on NUCLEO F103RB In-Reply-To: <20190110065006.7wdxkhonbkcny5rs@kartoffel.localdomain> References: <20190110065006.7wdxkhonbkcny5rs@kartoffel.localdomain> Message-ID: <87o98o9alx.fsf@fsij.org> Hello, This week, I did hand-soldering for STM32 Nucleo. I tested Gnuk 1.2.13 on that board (in order to check if my hand-soldering is good). All worked fine for me. Pablo Ovelleiro Corral wrote: > quick question regarding supported hardware: I saw the hardware > requirement for Gnuk is the micro controller STM32F103. > (https://wiki.debian.org/GNUK#Gnuk_Hardware). > > Will it run on one of this boards?: > https://www.reichelt.de/nucleo-64-arm-cortex-m3-stm32-f1-serie-nucleo-f103rb-p154270.html?&trstct=pos_7 Please see: https://www.fsij.org/gnuk/neug-on-stm32-nucleo-f103.html The purpose for my Nucleo board is not Gnuk, in fact. I'm considering to make poorman's card reader with this board. My frustration testing OpenPGPcard has been: there is no good card reader with free firmware. In this year, I plan to have a solution. And this is the first step. -- From email at kmkcl.de Fri Jan 11 00:10:47 2019 From: email at kmkcl.de (=?UTF-8?Q?Karsten_M=c3=bcller?=) Date: Fri, 11 Jan 2019 00:10:47 +0100 Subject: gnuk with GD32F103 Message-ID: Hello, I am going to build my own gnuk device (schematic based on german nitrokey version) and after first success with original STM32F103 microcontroller, I want to try a GD32F103 microcontroller. (as used in fst-01sz version) Unfortunately it does not work out of the box. My first attempt was to flash same binarys... Then, for a quick and dirty test, I adapt FST-01SZ board file with pin configuration of nitrokey... so clock settings and gd32 specific settings stay the same. (For latter, I only found a compile decision in adc functions - is that correct?) But that did not work either. For compiling I use arm toolchain and for programming texane/stlink with a stlinkv2 programmer. Programming gives no errors. I am wondering, because I thought that both microcontrollers nearly the same from an outer point of view. Is there anything else to consider, if using GD32F103 instead of STM32F103? best regards, Karsten From mike at sowbug.com Fri Jan 11 06:20:39 2019 From: mike at sowbug.com (Mike Tsao) Date: Thu, 10 Jan 2019 21:20:39 -0800 Subject: PSA: building chopstx on Ubuntu is very broken Message-ID: Background: https://github.com/im-tomu/tomu-quickstart/issues/13 https://bugs.launchpad.net/ubuntu/+source/newlib/+bug/1767223 If you try building anything using chopstx, including gnuk and neug, using the Ubuntu 18.04 "gcc-arm-none-eabi" compiler, or the libnewlib-arm-none-eabi library, the resulting binaries won't work. You'll get as far as flashing the image to your device and plugging it into USB, and then you'll get all sorts of errors in dmesg like these: [80745.158745] usb 1-4.4: new full-speed USB device number 46 using xhci_hcd [80745.158892] usb 1-4.4: Device not responding to setup address. [80745.366901] usb 1-4.4: Device not responding to setup address. [80745.574730] usb 1-4.4: device not accepting address 46, error -71 [80745.575119] usb 1-4-port4: unable to enumerate USB device Use the arm-provided toolchain instead ( https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads) and you'll have a better outcome. This has been broken in the Ubuntu distribution for more than 6 months (maybe upstream Debian as well). I'm sure it would be very frustrating for someone who was following this project's build instructions carefully, yet still ended up with nothing working. I hope this PSA saves you from that frustration. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Fri Jan 11 07:37:47 2019 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 11 Jan 2019 15:37:47 +0900 Subject: gnuk with GD32F103 In-Reply-To: References: Message-ID: <871s5jbsxw.fsf@fsij.org> Hello, Karsten M?ller wrote: > I am going to build my own gnuk device (schematic based on german > nitrokey version) and after first success with original STM32F103 > microcontroller, I want to try a GD32F103 microcontroller. (as used in > fst-01sz version) > Unfortunately it does not work out of the box. I think that your writing of "schematic based on german nitrokey version" may be not accurate expression, if it's for Gnuk, well, from the author of FST-01* design. IIUC, at least some of Nitrokey board designs are based on my FST-01 design, including the one which is almost same circuit. Do you know the FST-01 design (no suffix version), or the design of FST-01G? It's good if you can show your schematics and how it's different to FST-01. > My first attempt was to flash same binarys... Then, for a quick and > dirty test, I adapt FST-01SZ board file with pin configuration of > nitrokey... so clock settings and gd32 specific settings stay the same. > (For latter, I only found a compile decision in adc functions - is that > correct?) But that did not work either. Please elaborate your configuration of Gnuk. For Gnuk with GD32F103 (examples are BLUE_PILL_G and FST_01SZ with board-blue-pill-g.h and board-fst-01sz.h respectively), you can find MHZ=96 in src/configure. This is important for GD32F103. -- From gniibe at fsij.org Fri Jan 11 07:58:57 2019 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 11 Jan 2019 15:58:57 +0900 Subject: PSA: building chopstx on Ubuntu is very broken In-Reply-To: References: Message-ID: <87y37rade6.fsf@fsij.org> Hello, Mike Tsao wrote: > https://github.com/im-tomu/tomu-quickstart/issues/13 > https://bugs.launchpad.net/ubuntu/+source/newlib/+bug/1767223 > > If you try building anything using chopstx, including gnuk and neug, using > the Ubuntu 18.04 "gcc-arm-none-eabi" compiler, or > the libnewlib-arm-none-eabi library, the resulting binaries won't work. Thanks for sharing information. It's unfortunate that Ubuntu 18.04 has wrong version of newlib binary package. As written in Gnuk/README, I use: ========================== Excerpt from README You need GNU toolchain and newlib for 'arm-none-eabi' target. On Debian we can install the packages of gcc-arm-none-eabi, gdb-arm-none-eabi and its friends. I'm using: binutils-arm-none-eabi 2.31.1-2+10 gcc-arm-none-eabi 15:7-2018-q2-4 gdb-arm-none-eabi 7.12-6+9+b2 libnewlib-arm-none-eabi 3.0.0.20180802-2 ========================== In Debian, libnewlib-arm-none-eabi is build with new version of gcc-arm-none-eabi, thus, no problem. I'm going to update to newer newlib in Debian testing, and we don't need gdb-arm-none-eabi (because normal gdb supports arm-none-eabi binaries) now. -- From mike at sowbug.com Wed Jan 30 05:21:23 2019 From: mike at sowbug.com (Mike Tsao) Date: Tue, 29 Jan 2019 20:21:23 -0800 Subject: Possible bug or opportunity for user error with admin/user password Message-ID: This is on FSIJ-1.2.13 running on an ST_DONGLE. 1. Flash using standard method. 2. gpg --card-edit 3. factory-reset, y, yes 4. rm -rf .gnupg, kill gpg-connect-agent, etc. so GnuPG is fresh 5. gpg --import my-secret-subkeys.gpg 6. gpg --edit-key myname 7. key 1 8. keytocard 9. (answer menu for encryption key) 10. when asked for admin PIN, enter 12345678 11. when asked again for admin PIN, enter 12345678 12. exit 13. gpg --card-edit 14. admin 15. passwd 16. enter 1 for user PIN 17. *enter 12345678* 18. when asked for new password, enter thisismypassword 19. when asked again for new password, enter thisismypassword 20. exit 21. gpg --card-status to confirm that the gnuk device is now loaded with the key 22. gpg -d something-encrypted-with-this-key.asc 23. when prompted, enter thisismypassword 24. get "no decryption key" 25. try again 26. try again 27. device is locked Do you see what I did wrong? At step 17 I entered 12345678 instead of 123456. I forgot that the default admin PIN is different from the default user PIN. But the messages that GnuPG printed suggested that the password change succeeded! (See transcript below.) Moreover, I went back to step 25 and tried entering 123456. Nope -- the password is indeed changed, but it's changed to neither 123456, 12345678, or thisismypassword. The bug I'm reporting is that I don't understand why GnuPG accepted the wrong initial user PIN. Why didn't it report that the password change failed? Aside from it being obviously frustrating because the only way to fix it is to factory-reset and do the whole process over again. But it could be a serious issue if a user believes the device is correctly set up, and then (foolishly) discards other copies of the secret subkey. I hope this is something within gnuk's control. If it's just GnuPG being silly, then there isn't much this team can do about it. (transcript of session follows) > admin Admin commands are allowed gpg/card> passwd gpg: OpenPGP card no. D2760001xxxxxxxx detected 1 - change PIN 2 - unblock PIN 3 - change Admin PIN 4 - set the Reset Code Q - quit Your selection? 1 [entered 12345678, then thisismypassword twice] *PIN changed. <===== NOTE REPORT OF SUCCESS* 1 - change PIN 2 - unblock PIN 3 - change Admin PIN 4 - set the Reset Code Q - quit Your selection? q gpg/card> verify [entered thisismypassword] Reader ...........: 234B:0000:FSIJ-1.2.13-xxxxx Application ID ...: D2760001xxxxxxx Version ..........: 2.0 Manufacturer .....: unmanaged S/N range Serial number ....: xxxxxx Name of cardholder: [not set] Language prefs ...: [not set] Sex ..............: unspecified URL of public key : [not set] Login data .......: [not set] Signature PIN ....: forced Key attributes ...: ed25519 rsa2048 rsa2048 Max. PIN lengths .: 127 127 127 *PIN retry counter : 2 3 3 <===== NOTE DECREMENT* (end transcript) -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Wed Jan 30 12:07:20 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 30 Jan 2019 12:07:20 +0100 Subject: Possible bug or opportunity for user error with admin/user password In-Reply-To: References: Message-ID: Hi, I think your new password is now "78thisismypassword". There's an annoying design deficiency in the OpenPGP Card specification. It says this: > The length of the existing password is known in the card, so that > neither a delimiter nor padding for filling up fixed formats is > necessary for UTF-8. The length of the new UTF-8 password therefore > computes L new = Lc ? L old. Do you see the problem? :-) The data field for changing OLDPIN to NEWPIN is formatted as: OLDPINNEWPIN The data field that is sent when you specify the old PIN as OLDPINBAD and the new PIN as NEWPIN is: OLDPINBADNEWPIN So the pin is changed to BADNEWPIN. So any suffix you accidentally add to the old PIN becomes a prefix to the new PIN. This is in the specification, not the GnuK implementation :-(. And the mistake in the reasoning of the specification is that even though the card might be completely certain of the length of the old PIN, the user might not be. Add default PINs that only differ in suffix, and we get a trap sprung for the unsuspecting user. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From mike at sowbug.com Wed Jan 30 16:22:58 2019 From: mike at sowbug.com (Mike Tsao) Date: Wed, 30 Jan 2019 07:22:58 -0800 Subject: Possible bug or opportunity for user error with admin/user password In-Reply-To: References: Message-ID: Peter, that's a pretty wacky design decision. Thanks for spelling it out for me. Next time I set up a new key, I'll verify that this was in fact the issue. Meanwhile, I hope that our record of this discussion rescues another person from an exasperating experience in the future! On Wed, Jan 30, 2019 at 3:07 AM Peter Lebbing wrote: > Hi, > > I think your new password is now "78thisismypassword". > > There's an annoying design deficiency in the OpenPGP Card > specification. It says this: > > > The length of the existing password is known in the card, so that > > neither a delimiter nor padding for filling up fixed formats is > > necessary for UTF-8. The length of the new UTF-8 password therefore > > computes L new = Lc ? L old. > > Do you see the problem? :-) > > The data field for changing OLDPIN to NEWPIN is formatted as: > > OLDPINNEWPIN > > The data field that is sent when you specify the old PIN as OLDPINBAD > and the new PIN as NEWPIN is: > > OLDPINBADNEWPIN > > So the pin is changed to BADNEWPIN. > > So any suffix you accidentally add to the old PIN becomes a prefix to > the new PIN. > > This is in the specification, not the GnuK implementation :-(. > > And the mistake in the reasoning of the specification is that even > though the card might be completely certain of the length of the old > PIN, the user might not be. Add default PINs that only differ in suffix, > and we get a trap sprung for the unsuspecting user. > > HTH, > > Peter. > > -- > I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. > You can send me encrypted mail if you want some privacy. > My key is available at > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Wed Jan 30 18:38:54 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Jan 2019 18:38:54 +0100 Subject: Possible bug or opportunity for user error with admin/user password In-Reply-To: (Mike Tsao's message of "Wed, 30 Jan 2019 07:22:58 -0800") References: Message-ID: <87ef8ucafl.fsf@wheatstone.g10code.de> Hi! On Wed, 30 Jan 2019 07:22, mike at sowbug.com said: > Peter, that's a pretty wacky design decision. Thanks for spelling it out Actually this is not OpenPGP card specific but demanded by ISO-7816. The practice of having a longer Admin PIN with the same prefix as the User PIN is also common. Indeed, it is an ugly API but you should consider that it has been standardized about 25 years ago and back then the chips needed to spare as much memory as possible. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From peter at digitalbrains.com Wed Jan 30 20:17:32 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 30 Jan 2019 20:17:32 +0100 Subject: Possible bug or opportunity for user error with admin/user password In-Reply-To: <87ef8ucafl.fsf@wheatstone.g10code.de> References: <87ef8ucafl.fsf@wheatstone.g10code.de> Message-ID: <0da0187b-4a5f-3f92-f4e3-8457668cbd9c@digitalbrains.com> Hi all! On 30/01/2019 18:38, Werner Koch wrote: > Actually this is not OpenPGP card specific but demanded by ISO-7816. ISO 7816-4:2013, section 11.5.7 CHANGE REFERENCE DATA command, states: Verification data followed without delimitation by new reference data While I knew it is a standardized command, I misremembered the details, my mistake. Anyway, can't we work around this? If we do a VERIFY first to check if the old PIN is accepted, we can then do a CHANGE REFERENCE DATA only when the VERIFY worked out okay. That way, entering the old PIN with a suffix will fail on VERIFY. Unfortunately, this is not fool-proof with smartcard readers with a PIN-pad, since they require you to re-enter the PIN for CHANGE REFERENCE DATA. Still, as long as the user doesn't mistype in such a way as to create such a suffix, it will catch the mistake. It does mean that with a PIN-pad, the user needs to enter the old PIN twice. I think that's preferable to the confusion we have now. For PINs entered through pinentry, we can just repeat it programmatically, the user doesn't have to retype. Or if you don't like that, you could just implement the check for cases where pinentry is used, not for the PIN-pad case. > Indeed, it is an ugly API but you should consider that it has been > standardized about 25 years ago and back then the chips needed to > spare as much memory as possible. Hmmmm, even then I think it's overzealous optimization, given the problem at hand. You'd need one byte more in your packet buffer, but will CHANGE REFERENCE DATA often be the largest packet in your card application (and hence determine the size of your buffer)? Even if that were the case, they should have thought of a clever solution :-). I suspect they simply forgot this special case, thinking "the length is known", without asking themselves "to whom?". Cheers, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From jeremydrake+gnuk at eacceleration.com Wed Jan 30 20:40:34 2019 From: jeremydrake+gnuk at eacceleration.com (Jeremy Drake) Date: Wed, 30 Jan 2019 11:40:34 -0800 (PST) Subject: Possible bug or opportunity for user error with admin/user password In-Reply-To: References: Message-ID: On a related note, I have found that the process of setting PINs and loading keys (whether importing or generating) is highly order dependent, and if I do not do things in exactly the right order, unexpected things happen and I wind up having to start over. It looks like the order followed here is almost the same as the order I wrote down to follow that works for me, except I would have changed the admin pin before importing the key. On Tue, 29 Jan 2019, Mike Tsao wrote: > This is on FSIJ-1.2.13 running on an ST_DONGLE. > > 1. Flash using standard method. > 2. gpg --card-edit > 3. factory-reset, y, yes > 4. rm -rf .gnupg, kill gpg-connect-agent, etc. so GnuPG is fresh > 5. gpg --import my-secret-subkeys.gpg > 6. gpg --edit-key myname > 7. key 1 > 8. keytocard > 9. (answer menu for encryption key) > 10. when asked for admin PIN, enter 12345678 > 11. when asked again for admin PIN, enter 12345678 > 12. exit > 13. gpg --card-edit > 14. admin > 15. passwd > 16. enter 1 for user PIN > 17. *enter 12345678* > 18. when asked for new password, enter thisismypassword > 19. when asked again for new password, enter thisismypassword > 20. exit > 21. gpg --card-status to confirm that the gnuk device is now loaded with > the key > 22. gpg -d something-encrypted-with-this-key.asc > 23. when prompted, enter thisismypassword > 24. get "no decryption key" > 25. try again > 26. try again > 27. device is locked > > Do you see what I did wrong? At step 17 I entered 12345678 instead of > 123456. I forgot that the default admin PIN is different from the default > user PIN. But the messages that GnuPG printed suggested that the password > change succeeded! (See transcript below.) > > Moreover, I went back to step 25 and tried entering 123456. Nope -- the > password is indeed changed, but it's changed to neither 123456, 12345678, > or thisismypassword. > > The bug I'm reporting is that I don't understand why GnuPG accepted the > wrong initial user PIN. Why didn't it report that the password change > failed? Aside from it being obviously frustrating because the only way to > fix it is to factory-reset and do the whole process over again. But it > could be a serious issue if a user believes the device is correctly set up, > and then (foolishly) discards other copies of the secret subkey. > > I hope this is something within gnuk's control. If it's just GnuPG being > silly, then there isn't much this team can do about it. > > (transcript of session follows) >> admin > Admin commands are allowed > > gpg/card> passwd > gpg: OpenPGP card no. D2760001xxxxxxxx detected > > 1 - change PIN > 2 - unblock PIN > 3 - change Admin PIN > 4 - set the Reset Code > Q - quit > > Your selection? 1 [entered 12345678, then thisismypassword twice] > > *PIN changed. <===== NOTE REPORT OF SUCCESS* > > 1 - change PIN > 2 - unblock PIN > 3 - change Admin PIN > 4 - set the Reset Code > Q - quit > > Your selection? q > > gpg/card> verify [entered thisismypassword] > > Reader ...........: 234B:0000:FSIJ-1.2.13-xxxxx > Application ID ...: D2760001xxxxxxx > Version ..........: 2.0 > Manufacturer .....: unmanaged S/N range > Serial number ....: xxxxxx > Name of cardholder: [not set] > Language prefs ...: [not set] > Sex ..............: unspecified > URL of public key : [not set] > Login data .......: [not set] > Signature PIN ....: forced > Key attributes ...: ed25519 rsa2048 rsa2048 > Max. PIN lengths .: 127 127 127 > *PIN retry counter : 2 3 3 <===== NOTE DECREMENT* > > (end transcript) > From mike at sowbug.com Wed Jan 30 21:00:38 2019 From: mike at sowbug.com (Mike Tsao) Date: Wed, 30 Jan 2019 12:00:38 -0800 Subject: Possible bug or opportunity for user error with admin/user password In-Reply-To: References: Message-ID: Jeremy, I believe you're running into a common issue that adding a PIN to an empty device is not supported, or at least is a no-op. The reason, I think, is that the PIN is implemented as symmetric encryption of the secrets it's protecting, so if no keys have been added, then there's nothing to encrypt, so the PIN effectively vanishes into thin air. Since everyone appreciates armchair quarterbacking, I wonder whether it could have been done as a tagged structure of some sort that contains the keys, but also is > 0 bytes in length when empty. Then the PIN would have something to encrypt, and a way for the system to know whether an asserted PIN is valid. On Wed, Jan 30, 2019 at 11:41 AM Jeremy Drake < jeremydrake+gnuk at eacceleration.com> wrote: > On a related note, I have found that the process of setting PINs and > loading keys (whether importing or generating) is highly order dependent, > and if I do not do things in exactly the right order, unexpected things > happen and I wind up having to start over. It looks like the order > followed here is almost the same as the order I wrote down to follow that > works for me, except I would have changed the admin pin before importing > the key. > > > > On Tue, 29 Jan 2019, Mike Tsao wrote: > > > This is on FSIJ-1.2.13 running on an ST_DONGLE. > > > > 1. Flash using standard method. > > 2. gpg --card-edit > > 3. factory-reset, y, yes > > 4. rm -rf .gnupg, kill gpg-connect-agent, etc. so GnuPG is fresh > > 5. gpg --import my-secret-subkeys.gpg > > 6. gpg --edit-key myname > > 7. key 1 > > 8. keytocard > > 9. (answer menu for encryption key) > > 10. when asked for admin PIN, enter 12345678 > > 11. when asked again for admin PIN, enter 12345678 > > 12. exit > > 13. gpg --card-edit > > 14. admin > > 15. passwd > > 16. enter 1 for user PIN > > 17. *enter 12345678* > > 18. when asked for new password, enter thisismypassword > > 19. when asked again for new password, enter thisismypassword > > 20. exit > > 21. gpg --card-status to confirm that the gnuk device is now loaded > with > > the key > > 22. gpg -d something-encrypted-with-this-key.asc > > 23. when prompted, enter thisismypassword > > 24. get "no decryption key" > > 25. try again > > 26. try again > > 27. device is locked > > > > Do you see what I did wrong? At step 17 I entered 12345678 instead of > > 123456. I forgot that the default admin PIN is different from the default > > user PIN. But the messages that GnuPG printed suggested that the password > > change succeeded! (See transcript below.) > > > > Moreover, I went back to step 25 and tried entering 123456. Nope -- the > > password is indeed changed, but it's changed to neither 123456, 12345678, > > or thisismypassword. > > > > The bug I'm reporting is that I don't understand why GnuPG accepted the > > wrong initial user PIN. Why didn't it report that the password change > > failed? Aside from it being obviously frustrating because the only way to > > fix it is to factory-reset and do the whole process over again. But it > > could be a serious issue if a user believes the device is correctly set > up, > > and then (foolishly) discards other copies of the secret subkey. > > > > I hope this is something within gnuk's control. If it's just GnuPG being > > silly, then there isn't much this team can do about it. > > > > (transcript of session follows) > >> admin > > Admin commands are allowed > > > > gpg/card> passwd > > gpg: OpenPGP card no. D2760001xxxxxxxx detected > > > > 1 - change PIN > > 2 - unblock PIN > > 3 - change Admin PIN > > 4 - set the Reset Code > > Q - quit > > > > Your selection? 1 [entered 12345678, then thisismypassword twice] > > > > *PIN changed. <===== NOTE REPORT OF SUCCESS* > > > > 1 - change PIN > > 2 - unblock PIN > > 3 - change Admin PIN > > 4 - set the Reset Code > > Q - quit > > > > Your selection? q > > > > gpg/card> verify [entered thisismypassword] > > > > Reader ...........: 234B:0000:FSIJ-1.2.13-xxxxx > > Application ID ...: D2760001xxxxxxx > > Version ..........: 2.0 > > Manufacturer .....: unmanaged S/N range > > Serial number ....: xxxxxx > > Name of cardholder: [not set] > > Language prefs ...: [not set] > > Sex ..............: unspecified > > URL of public key : [not set] > > Login data .......: [not set] > > Signature PIN ....: forced > > Key attributes ...: ed25519 rsa2048 rsa2048 > > Max. PIN lengths .: 127 127 127 > > *PIN retry counter : 2 3 3 <===== NOTE DECREMENT* > > > > (end transcript) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Thu Jan 31 08:19:25 2019 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 31 Jan 2019 16:19:25 +0900 Subject: Possible bug or opportunity for user error with admin/user password In-Reply-To: <0da0187b-4a5f-3f92-f4e3-8457668cbd9c@digitalbrains.com> References: <87ef8ucafl.fsf@wheatstone.g10code.de> <0da0187b-4a5f-3f92-f4e3-8457668cbd9c@digitalbrains.com> Message-ID: <877eele1ky.fsf@c720> Hello, BTW, I'm glad to see Gnuk on ST_DONGLE is running. It might confuse a border official effectively, when there is such an opportunity. No, I don't have any experience, though. I know the issue in question. I reported in 2011 to GnuPG mailing list, and had a note: https://www.gniibe.org/log/bugreport/gnupg/openpgp-card-spec-2.0-chenge-reference-data.html Peter Lebbing wrote: > Hmmmm, even then I think it's overzealous optimization, given the > problem at hand. You'd need one byte more in your packet buffer, but > will CHANGE REFERENCE DATA often be the largest packet in your card > application (and hence determine the size of your buffer)? Even if that > were the case, they should have thought of a clever solution :-). > > I suspect they simply forgot this special case, thinking "the length is > known", without asking themselves "to whom?". I have same suspect. Anyway, my "solution" is using KDF feature. With KDF feature, the length is fixed, so, no such problem. I think that KDF feature is mature, now. Having GnuPG 2.2 in Debian backports, I can promote the use this year. I will write a short howto. -- From gniibe at fsij.org Thu Jan 31 08:34:05 2019 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 31 Jan 2019 16:34:05 +0900 Subject: FOSDEM and FST-01SZ Message-ID: <874l9pe0wi.fsf@c720> Hello, I'm now in Brussels, after visiting Hong Kong. I now have FST-01SZ! Last year, when I sent a talk proposal to FOSDEM, I was not sure if the product would be available or not. Happily, here is the one. FST-01SZ consists of two parts: * Board with GD32F103TB * Metal shell The board is in the shell, but a user can examine the board by pulling the board from the shell. And he can put his own firmware through SWD port. It is a user who put the board and bend two nails. Next, he can put the board in the shell into another enclosure (it's an option). In the photo, you can find a metal enclosure with a little hole. The hole is for LED light. There are many type of enclosures (plastic, metal, wood, etc.) in China, since the form factor of the metal shell is a kind of de-facto standard. When we can buy many (like >= 1000), we can ask customization like putting logo. Putting the metal shell to this metal case is one-way procedure. It is not (easily) possible to pull the board out again. This can be considered "feature", in terms of tamper resistance. I wish you happy forthcoming FOSDEM and Chinese New Year. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_20190128_130220_IMGP.jpg Type: image/jpeg Size: 80505 bytes Desc: FST-01SZ with a metal case URL: From frederic.suel at free.fr Thu Jan 31 10:56:51 2019 From: frederic.suel at free.fr (=?UTF-8?B?RnLDqWTDqXJpYyBTVUVM?=) Date: Thu, 31 Jan 2019 10:56:51 +0100 Subject: Possible bug or opportunity for user error with admin/user password In-Reply-To: <877eele1ky.fsf@c720> References: <87ef8ucafl.fsf@wheatstone.g10code.de> <0da0187b-4a5f-3f92-f4e3-8457668cbd9c@digitalbrains.com> <877eele1ky.fsf@c720> Message-ID: <014af178-8c33-a77b-37ed-a8889ffc7b11@free.fr> Hello, I confirm that chinese ST-DONGLE V2 clone is running too. I find a clone call "MX-LINK V2 of 2018-02-18" which has two leds and a STM32F103CBU6 (72 Mhz) processor instead of STM32F101CB1b (36 Mhz) as usual in this type of clone. For the usual clone, you have to change in configure MHZ from 72 to 36 before to compile. I confirm too that MX-LINK V2 clone run fine as NEUG TRNG on Debian. It can be find in some Chinese vendors, the picture on the clone is a big M instead of noting or a big ST. Fr?d?ric Le 31/01/2019 ? 08:19, NIIBE Yutaka a ?crit?: > Hello, > > BTW, I'm glad to see Gnuk on ST_DONGLE is running. It might confuse a > border official effectively, when there is such an opportunity. No, I > don't have any experience, though. > > I know the issue in question. I reported in 2011 to GnuPG mailing list, > and had a note: > > https://www.gniibe.org/log/bugreport/gnupg/openpgp-card-spec-2.0-chenge-reference-data.html > > Peter Lebbing wrote: >> Hmmmm, even then I think it's overzealous optimization, given the >> problem at hand. You'd need one byte more in your packet buffer, but >> will CHANGE REFERENCE DATA often be the largest packet in your card >> application (and hence determine the size of your buffer)? Even if that >> were the case, they should have thought of a clever solution :-). >> >> I suspect they simply forgot this special case, thinking "the length is >> known", without asking themselves "to whom?". > I have same suspect. > > Anyway, my "solution" is using KDF feature. With KDF feature, the > length is fixed, so, no such problem. > > I think that KDF feature is mature, now. Having GnuPG 2.2 in Debian > backports, I can promote the use this year. I will write a short howto. From noodles at earth.li Thu Jan 31 13:23:25 2019 From: noodles at earth.li (Jonathan McDowell) Date: Thu, 31 Jan 2019 12:23:25 +0000 Subject: FOSDEM and FST-01SZ In-Reply-To: <874l9pe0wi.fsf@c720> References: <874l9pe0wi.fsf@c720> Message-ID: <20190131122325.zt53hpf72b6uldgo@earth.li> On Thu, Jan 31, 2019 at 04:34:05PM +0900, NIIBE Yutaka wrote: > I'm now in Brussels, after visiting Hong Kong. I now have FST-01SZ! > > Last year, when I sent a talk proposal to FOSDEM, I was not sure if the > product would be available or not. Happily, here is the one. > > FST-01SZ consists of two parts: > > * Board with GD32F103TB > * Metal shell > > The board is in the shell, but a user can examine the board by pulling > the board from the shell. And he can put his own firmware through SWD > port. It is a user who put the board and bend two nails. Very nice! Now my only wishlist item missing is a button to confirm signing. ;) Do you have any idea what pricing for the new device + case is likely to be? J. -- Are you out of my mind?