From peter at digitalbrains.com Mon Dec 10 16:29:53 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 10 Dec 2018 16:29:53 +0100 Subject: Distribution of binary Message-ID: Hello Gniibe and list, TL;DR: Is it okay to give people gnuk-no-vidpid.elf along with the script to insert a VID:PID? In Debian bug #903163, Guilhem Moulin mentioned he cannot test code for multi-card-reader GnuPG setups since he has only one reader. Chris Lamb offered to get him a reader, but I also replied[1] since I know how to put GnuK on a 3 dollar Maple Mini clone and both Guilhem and I will be at the 35C3 in two weeks. In fact, I thought, why not bring ten, for anyone interested. They're cheap as dirt, might as well hand them out. The Maple Mini loses a lot of the desirable properties of the FST-01, in regard to form factor, supply chain trustworthiness etcetera. Guilhem would not be using it to keep secrets, but just for development. And of course people only have my word that I myself didn't do bad stuff. I could write paragraph after paragraph about all the tradeoffs possible, with ideally people building their own binary and using an SWD- or JTAG-programmer to flash the Maple Mini. But let's not write that mail now. I quickly realized I had for a moment forgotten about the stipulations regarding the FSIJ VID:PID of 234b:0000. I cannot just hand out GnuK's fully programmed and functional. One of the tradeoffs possible is that I put a GnuK with the illegal VID:PID 0000:0000 on the Maple Mini, and give that to someone. I also give them a pre-built gnuk-no-vidpid.elf and the shell scripts to put the proper FSIJ VID:PID in it, and they use reGNUal to flash the Maple Mini. This works since you can actually upload reGNUal to a Maple Mini that has GnuK with VID:PID 0000:0000 on Linux, I tested it. GnuPG was less willing to work with such a GnuK; it reports: > ccid-driver: usb_open failed: LIBUSB_ERROR_IO Is it legally OK if I give people gnuk-no-vidpid.elf and the shell scripts to change the VID:PID? This for people who, after hearing me explain the pros and cons, decides they want to have that to avoid having to build the firmware themselves. Cheers, Peter. PS: Before you reply "you need arm-none-eabi-objdump for binary-edit.sh", let me point out that 1) x86_64-linux-gnu-objdump works as well for this purpose and 2) I could edit the script to directly refer to a binary offset specific to the .elf I hand out. [1] -- 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 peter at digitalbrains.com Mon Dec 10 20:21:07 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 10 Dec 2018 20:21:07 +0100 Subject: Distribution of binary In-Reply-To: References: Message-ID: <0c4affce-3973-9a56-3234-5fbe2744eba7@digitalbrains.com> On 10/12/2018 16:29, Peter Lebbing wrote: > PS: Before you reply "you need arm-none-eabi-objdump for > binary-edit.sh", let me point out that 1) x86_64-linux-gnu-objdump works > as well for this purpose and 2) I could edit the script to directly > refer to a binary offset specific to the .elf I hand out. D'oh! Completely forgot about objcopy to produce a pure binary (.bin) from .elf. That one does require the proper objcopy binary. Still, it can be solved by directly patching the .bin with a script that uses the offsets precomputed for the .bin file. -- 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 gniibe at fsij.org Tue Dec 11 03:33:19 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 11 Dec 2018 11:33:19 +0900 Subject: Distribution of binary In-Reply-To: References: Message-ID: <87zhtcdc7k.fsf@iwagami.gniibe.org> Peter Lebbing wrote: > TL;DR: Is it okay to give people gnuk-no-vidpid.elf along with the > script to insert a VID:PID? As long as it's an experimental use (it's not commercial product) with the condition of: * Distribution here means delivery of a limited number of hardware by hand (in person) * Both sides have enough knowledge, and agree it's an experiment * Both sides actually have official Gnuk Token already Then, I'd say, it's OK even with 234b:0000. Please note that it's my personal opinion. This is not something like an official resolution at FSIJ annual meeting. What I ask clearly is not to distribute binary of gnuk.elf which contains VID:PID of FSIJ, by a media (like CD-ROM, SD card, etc.) or on network. If done for commercial product, I think that both cases (distributing a hardware with 0000:0000, distributing a hardware with 234b:0000) anyway violate the assumption of USB governance. In the (ideal) USB world, it assumes it is only done by the vendor. If done for personal experiment, nothing could stop that, I suppose. For distribution of experimental hardware among friends, in general, it's better not to do that using someone's vendor ID (as a good citizen, not to confuse the world). For this particular case of experimental Gnuk Token, as long as it is recognized as an experiment and both have official Gnuk Token (which means no possible misunderstanding), it's OK. This is my opinion. >From here, we have other technical discussion... For users to experiment "out of box", obviously 234b:0000 is better, because there are situations like: > GnuPG was less willing to work with such a GnuK; it reports: > > ccid-driver: usb_open failed: LIBUSB_ERROR_IO This is because of configuration. In Debian, for example, it is the distribution which arranges udev rules to access the hardware. It is basically configured based on VID:PID, because each hardware behaves differently (unfortunately). It could use USB interface class ID (bInterfaceClass), in theory, when each hardware hehaves well. -- From peter at digitalbrains.com Wed Dec 12 15:48:24 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 12 Dec 2018 15:48:24 +0100 Subject: Distribution of binary In-Reply-To: <87zhtcdc7k.fsf@iwagami.gniibe.org> References: <87zhtcdc7k.fsf@iwagami.gniibe.org> Message-ID: <8ed318e1-6048-7f1e-b2f1-fae1e30188c4@digitalbrains.com> Hi Gniibe, Thanks for getting back to me so quickly! I've been playing around some more. On 11/12/2018 03:33, NIIBE Yutaka wrote: > As long as it's an experimental use (it's not commercial product) with > the condition of: > > * Distribution here means delivery of a limited number of hardware > by hand (in person) > > * Both sides have enough knowledge, and agree it's an experiment > > * Both sides actually have official Gnuk Token already > > Then, I'd say, it's OK even with 234b:0000. Ah, okay, that's good to know! That's a really good compromise. But there might be people who don't have a GnuK yet and might want to experiment with a Maple Mini with GnuK. Given an explanation of the risks involved with regard to supply chain (which includes me), they might still be interested. The biggest hurdle: programming the Maple Mini if you don't have equipment. If I can give them a Maple Mini with GnuK but with a VID:PID of 0000:0000, they could build their own GnuK on Debian stable, which is really simple, and reGNUal their design into it. Would you be OK with a Maple Mini with GnuK with VID:PID 0000:0000, purely for the functionality of reGNUal? Note that NeuG did not come up on the Maple Mini and I haven't investigated why, since I didn't see any advantage to using NeuG with reGNUal over GnuK with reGNUal. Another option would be DFU. But I've been struggling with this for a bit; I'll split off the thread with a mail about that. > If done for commercial product, I think that both cases (distributing > a hardware with 0000:0000, distributing a hardware with 234b:0000) > anyway violate the assumption of USB governance. In the (ideal) USB > world, it assumes it is only done by the vendor. Hehe, yes, 0000:0000 is definitely not okay in general. But I don't care about that if it works under Linux for a single limited purpose. What I care about is violating licence or spirit of GnuK and FSIJ. >> GnuPG was less willing to work with such a GnuK; it reports: >>> ccid-driver: usb_open failed: LIBUSB_ERROR_IO > > This is because of configuration. In Debian, for example, it is the > distribution which arranges udev rules to access the hardware. PEBKAC. I /had/ configured udev, but it appears something had started pcscd without my knowledge.[1] It is working now even for GnuPG with a VID:PID of 0000:0000. Not that I intend anyone use it as that, just noting that technically, under Linux, it /does/ work. Cheers, Peter. [1] Hypothesis: if you insert a CCID-class device which does not have an udev rule that says ENV{ID_SMARTCARD_READER_DRIVER}="gnupg", does pcscd start on a systemd-managed Debian stable? Because I inserted the device before I wrote the udev rule. Anyway, it's not important, it just occured to me that might have been it. -- 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: 484 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Wed Dec 12 15:51:11 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 12 Dec 2018 15:51:11 +0100 Subject: Using GnuK with DFU bootloader In-Reply-To: <87zhtcdc7k.fsf@iwagami.gniibe.org> References: <87zhtcdc7k.fsf@iwagami.gniibe.org> Message-ID: Hi Gniibe, I was trying to make it so that you can upload GnuK to the Maple Mini with a DFU bootloader. Here's what happened :-). First of all, uploading by DFU 1) does not protect the flash from reading 2) keeps the bootloader intact, through which you can also read out the flash. So my goal is to upload GnuK through DFU and then upload another GnuK through reGNUal, which would kill the DFU and engage read lockout. There is already some DFU code in GnuK, I tried to leverage that. One ~~~ The default Maple Mini DFU puts uploaded code at 0x8005000. This is too high for GnuK (at least, without changes, it does not fit). But STM32duino-bootloader[1] is small; it loads code at 0x8002000. So I changed ORIGIN in gnuk/src/configure to match. Two ~~~ It appears the DFU-code in GnuK is faulty? First, `func` (main.c:412 [2]) is loaded from new_vector[9] while the DFU bootloader is still there, picking up data from the bootloader (at 0x8000024). It should only be loaded later, when SYS is copied to the first sectors. Second, the first 4 KiB is erased, but not written with SYS. flash_write() refuses to overwrite the first 4 KiB, leaving it empty instead of filled with SYS. I tried to fix these things in commit 2e2d68d, which you can find at my GitLab: [3]. I used a copy of flash_write() with the check removed. This should actually still be portable, since flash_program_halfword() is also in SYS? Anyway, it'll do for now for sure. PLEASE NOTE: upgrade_by_password.py has been modified to not lock memory readout. After all, that is slightly annoying when debugging ;-). Three ~~~~~ It still does not work. Why? Simple. We have SYS copied from 0x8002000 to 0x8000000, including all the pointers. So the vector at 0x8000024 (flash_erase_all_and_exec) is still pointing to the routine of the SYS at 0x8002000, and when called, it will soon erase itself. Not so much self-modifying as self-destroying code, and the processor faults. Four ~~~~ My current attempt is to have the GnuK that has been loaded via DFU not do any erasing or relocating. Instead, have a custom reGNUal erase the whole flash including the first 4KiB, and then have it program the whole flash including the first 4 KiB, with a bog-standard GnuK without DFU support. This doesn't work yet, and I really need to be doing other stuff now, so, to be continued. What do you make of this? Does the DFU+reGNUal work on other boards; I cannot see how it could? Cheers, Peter. [1] [2] [3] -- 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 gniibe at fsij.org Thu Dec 13 01:00:54 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 13 Dec 2018 09:00:54 +0900 Subject: Using GnuK with DFU bootloader In-Reply-To: References: <87zhtcdc7k.fsf@iwagami.gniibe.org> Message-ID: <87bm5qgurt.fsf@fsij.org> Peter Lebbing wrote: > It appears the DFU-code in GnuK is faulty? Possibly. The code of DFU support in Gnuk was written in very early stage of Gnuk development, for people with STBee and STBee mini. No surprises if not working. > I tried to fix these things in commit 2e2d68d, which you can find at my > GitLab: [3]. I will have a look at this. > Instead, have a custom reGNUal erase the whole flash including the > first 4KiB, and then have it program the whole flash including the > first 4 KiB, with a bog-standard GnuK without DFU support. I think that if you want to do that, in the first stage, flash ROM should not be protected. The first 4KiB cannot be written by running program (when protected). Since I interpreted so, I keep my practice of filling the first pages of 4KiB for SYS routines (and a part of table for AES). In the PM0075 Programming manual of STM32F10xxx Flash memory microcontrollers, it says (section 2.4.1 in page 17): Once the protection byte has been programmed: * Main Flash memory read access is not allowed except for the user code (when booting from main Flash memory itself with the debug mode not active). * Pages 0-3 (for low- and medium-density devices), or pages 0-1 (for high-density and connectivity line devices) are automatically write-protected. The rest of the memory can be programmed by the code executed from the main Flash memory (for IAP, constant storage, etc.), but it is protected against write/erase (but not against mass erase) in debug mode or when booting from the embedded SRAM. Well, it doesn't describe the specific case of IAP (in-application programming) booting from flash ROM and running code in SRAM, but it is likely the pages 0-3 are write-protected. -- From gniibe at fsij.org Thu Dec 13 01:19:53 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 13 Dec 2018 09:19:53 +0900 Subject: Distribution of binary In-Reply-To: <8ed318e1-6048-7f1e-b2f1-fae1e30188c4@digitalbrains.com> References: <87zhtcdc7k.fsf@iwagami.gniibe.org> <8ed318e1-6048-7f1e-b2f1-fae1e30188c4@digitalbrains.com> Message-ID: <877egegtw6.fsf@fsij.org> Peter Lebbing wrote: > But there might be people who don't have a GnuK yet and might want to > experiment with a Maple Mini with GnuK. In that case... how about some procedure like this? * Give (or sell) a Maple Mini (factory setup) to your friend. * Offer a service of flashing Gnuk on behalf of your friend, in person That is, it is your friend who flashes Gnuk onto her own board, while you help that. In this scenario, I think that it could be considered as: no distribution of binary occurs. It is the best when she uses her own notebook computer to flash the board, but it would be also OK her using your notebook computer (directly or indirectly). At least, I don't mind. It's acceptable for me. Even if it's all you who type in commands to flash, when it's done by her will, it's OK for me. For your using your notebook computer while it's completely out of control by her... that would be considered distribution of binary from you to her. That's my interpretation and thought. -- From jeremydrake+gnuk at eacceleration.com Thu Dec 13 02:24:01 2018 From: jeremydrake+gnuk at eacceleration.com (Jeremy Drake) Date: Wed, 12 Dec 2018 17:24:01 -0800 (PST) Subject: Distribution of binary In-Reply-To: References: Message-ID: On Mon, 10 Dec 2018, Peter Lebbing wrote: > > In Debian bug #903163, Guilhem Moulin mentioned he cannot test code for > multi-card-reader GnuPG setups since he has only one reader. Chris Lamb > offered to get him a reader, but I also replied[1] since I know how to > put GnuK on a 3 dollar Maple Mini clone and both Guilhem and I will be > at the 35C3 in two weeks. If all you want is to test GnuPG, and not store any secrets, couldn't you use the GNU/Linux port of GnuK? There's not much documentation out there for that, that I've found, but a while back I took an email from (the predecessor to) this list's archives and attempted to format the instructions a little better, and correct typos. https://salsa.debian.org/snippets/151 From peter at digitalbrains.com Thu Dec 13 09:51:20 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 13 Dec 2018 09:51:20 +0100 Subject: Using GnuK with DFU bootloader In-Reply-To: <87bm5qgurt.fsf@fsij.org> References: <87zhtcdc7k.fsf@iwagami.gniibe.org> <87bm5qgurt.fsf@fsij.org> Message-ID: On 13/12/2018 01:00, NIIBE Yutaka wrote: > I will have a look at this. Do note it is not actually working :-). > I think that if you want to do that, in the first stage, flash ROM > should not be protected. That is my interpretation also, but the DFU doesn't engage protection. Running GnuK with a DFU bootloader present is completely not an option, since both SWD and the DFU bootloader can readily hand you a copy of the encrypted private keys on the GnuK. You would subsequently need to wipe the DFU and after that engage readout locks. Which can all theoretically be done by GnuK and reGNUal in concert. 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 peter at digitalbrains.com Thu Dec 13 10:07:00 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 13 Dec 2018 10:07:00 +0100 Subject: Distribution of binary In-Reply-To: <877egegtw6.fsf@fsij.org> References: <87zhtcdc7k.fsf@iwagami.gniibe.org> <8ed318e1-6048-7f1e-b2f1-fae1e30188c4@digitalbrains.com> <877egegtw6.fsf@fsij.org> Message-ID: <9b3783be-d288-ef12-c453-85ab3ea8708d@digitalbrains.com> On 13/12/2018 01:19, NIIBE Yutaka wrote: > In that case... how about some procedure like this? That gives me plenty to work with, thank you! I'd still like to enable the DFU method, since it can then all be done on any computer without programming hardware (after the factory bootloader has been replaced by a smaller alternative DFU bootloader; a step that does require programming hardware). I'm not comfortable lending random people my FT2232H-based programmer on a hackers congress, what with BadUSB and all. I realize that might sound a bit hypocritical when you say so while handing out USB devices, but everybody needs to make their own assessment of the risks involved. I will be worthy of any trust, but can give no more than my word on that. 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 peter at digitalbrains.com Thu Dec 13 10:14:37 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 13 Dec 2018 10:14:37 +0100 Subject: Distribution of binary In-Reply-To: References: Message-ID: <2f7229da-649a-bb41-c838-c7c86577d38b@digitalbrains.com> On 13/12/2018 02:24, Jeremy Drake wrote: > If all you want is to test GnuPG, and not store any secrets, couldn't > you use the GNU/Linux port of GnuK? There's not much documentation > out there for that, that I've found, but a while back I took an email > from (the predecessor to) this list's archives and attempted to format > the instructions a little better, and correct typos. Yes, that had occurred to me as well, after the topic of more hardware came up. But I hadn't looked into it at all yet and I would be meeting Guilhem in a couple of weeks anyway at the congress :-). The OS that needs the GnuK will be running in a virtual machine, and it will be impossible to have the GNU/Linux port of GnuK running inside that virtual machine. I know for a fact you can pass the VM the control of a physical stick. It will probably be possible to wire the virtual machine to a USB-over-IP instance as well, but I haven't tried. Thanks for the pointer and the instructions! 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 gniibe at fsij.org Fri Dec 14 01:23:19 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 14 Dec 2018 09:23:19 +0900 Subject: Distribution of binary In-Reply-To: <9b3783be-d288-ef12-c453-85ab3ea8708d@digitalbrains.com> References: <87zhtcdc7k.fsf@iwagami.gniibe.org> <8ed318e1-6048-7f1e-b2f1-fae1e30188c4@digitalbrains.com> <877egegtw6.fsf@fsij.org> <9b3783be-d288-ef12-c453-85ab3ea8708d@digitalbrains.com> Message-ID: <875zvxdki0.fsf@fsij.org> Peter Lebbing wrote: > I'd still like to enable the DFU method, since it can then all be done > on any computer without programming hardware (after the factory > bootloader has been replaced by a smaller alternative DFU bootloader; a > step that does require programming hardware). I see your point. That's fair, when done properly. Please note that it should not result a situation like: (a) Random persons' knowing your offering of Maple Mini (or Blue Pill) at a conference. (b) They will just take the advantage of this opportunity to get it at zero price, and will flash Gnuk on to the board with FSIJ's. (c) Selling it at eBay (or equivalent). If it will happen, the step (c) violates the assumption of experimental personal use, and it will put FSIJ into difficult situation about their management of VID. I'd say that the step (c) constitutes a distribution of binary, if I were a lawyer. My request is: Please don't automate it too much, to prevent such a situation. I recommend requiring some manual edit (human interaction step) which can be only proceeded after learning USB things. Well, it was a coincidence, I just received an email yesterday: USB Implementers Forum wrote: > Dear VID Holders, The USB-IF is going to make our master VID listing > available on our public website. This is in line with standard industry > practice and based upon requests from other industry organizations and some > members. I hope this oppotunity eventually brings better output of lsusb for Gnuk Token. -- From peter at digitalbrains.com Tue Dec 18 18:59:37 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 18 Dec 2018 18:59:37 +0100 Subject: Using GnuK with DFU bootloader In-Reply-To: References: <87zhtcdc7k.fsf@iwagami.gniibe.org> <87bm5qgurt.fsf@fsij.org> Message-ID: Hello Niibe and list, I have implemented support for safe DFU uploads, and tested it with a Maple Mini clone from Baite, with the STM32duino bootloader. As I said before, unfortunately it is not possible to implement this with the factory bootloader of Maple Mini's, because there is only 108 KiB flash left with the factory bootloader, and GnuK is simply too large. Normally, the SYS block of the code is at the start of the flash and is the first thing executed. It cannot ever be updated with reGNUal. With DFU, the DFU bootloader is at the start of the flash and GnuK starts at an offset. Also, the DFU bootloader might leave the flash unprotected from readout. I'm not experienced enough to say whether this is always the case, but it is for the STM32duino bootloader and I expect it is true for most DFU bootloaders. We don't want the DFU bootloader to stay even when flash readout were protected, as it might still expose the flash to readout. Flash readout protection only protects from programming hardware, code in the flash can still read the flash, unsurprisingly. Also, if we want to use reGNUal to later update to a new GnuK version, we need SYS at the start of flash because this is what reGNUal and the new GnuK will expect. So my implementation has two versions of SYS, one running version at an offset, and one copy of a version at the start of the flash. The first time GnuK runs, it will remove the DFU bootloader, install the copy of SYS at the start of the flash and enable readout protection. It will continue to use the copy at an offset, but the one at the start is there for a future GnuK to start using. The GnuK firmware increases in size by 1 kilobyte with this option. Once reGNUal is used, the GnuK becomes identical to one that was flashed "bare" in the usual way, without DFU. But this is not necessary for safe operation, it is just there to provide an upgrade path. GnuK is safe to use directly after being flashed with a DFU bootloader. My changes can be found in commit 00039c2419919b396ff11f119820f8cae5ab1d31 at [1]. This might be useful to have during the 35C2 Congress[2] ;-) which is from Dec 27 to Dec 30, in a bit more than a week! Niibe, I cannot ask you to accept these changes on such short notice, so I won't. But I hope the extra functionality is useful. I have tried several things with a Maple Mini with this GnuK and it behaved completely normally. By the way, I did not implement --gc-sections support for the copy of SYS in stdaln-sys-bin.o because I seemed to be missing a small part of the puzzle to make it work and it wasn't very necessary since the Makefile only includes the object when DFU support is enabled. With the current code, it is then also needed anyway. HTH, Peter. [1] [2] It's the 35C3, but the last C is for Congress. Just like an LCD is an LC display, when you write out the last C, you need to remove it from the abbreviation, right? ;-P And as a proper name, a capitalized C. -- 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 gniibe at fsij.org Thu Dec 20 04:54:17 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 20 Dec 2018 12:54:17 +0900 Subject: Chopstx 1.13 and FST-01SZ Message-ID: <87o99gsviu.fsf@iwagami.gniibe.org> Hello, Chopstx 1.13 is released. tag release/1.13 Tagger: NIIBE Yutaka Date: Wed Dec 19 13:40:49 2018 +0900 commit b6c90e3df450cf4b33571733211e1ad6849656ac The API of chopstx_poll is improved, so that user of the function can use the update of *USEC_P when non-timeout event occurs. Also, I updated the PCB design of FST-01SZ a bit. FST-01SZ (version 3.01 in fst-01) is released. tag release/3.01 Tagger: NIIBE Yutaka Date: Wed Dec 12 12:39:02 2018 +0900 commit 74ad36a6acc91924b22de09b4c49a9241db052a9 It's now in production. Here is another information. In the end of November, I visited the new office of Seeed Technology for the production. Their marketing team will answer my question about if they will sell FST-01SZ at SeeedStudio.com again, but my gut feeling is it's difficult, because of lower volume. And even if it will be done, their preference is selling the product as their own, and paying back royalty. (Here, 'royalty' is in their term). Because it is my personal business which gets permission by FSIJ for its use of VID:PID, this arrangement is not good for me. Well, I'm testing configuration which doesn't use VID:PID. This is my current configuration in Debian. /etc/udev/rules.d/61-gnuk-scdaemon.rules: =============================== SUBSYSTEM=="usb", ATTR{product}=="Gnuk Token", ENV{ID_SMARTCARD_READER}="1", ENV{ID_SMARTCARD_READER_DRIVER}="gnupg" =============================== -- From gniibe at fsij.org Thu Dec 20 10:06:07 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 20 Dec 2018 18:06:07 +0900 Subject: Using GnuK with DFU bootloader In-Reply-To: References: <87zhtcdc7k.fsf@iwagami.gniibe.org> <87bm5qgurt.fsf@fsij.org> Message-ID: <87r2ecwosg.fsf@fsij.org> Peter Lebbing wrote: > I have implemented support for safe DFU uploads, and tested it with a > Maple Mini clone from Baite, with the STM32duino bootloader. Great. > My changes can be found in commit > 00039c2419919b396ff11f119820f8cae5ab1d31 at [1]. I think that you meant four commits which ends by the commit of 00039c2419919b396ff11f119820f8cae5ab1d31, right? I'll merge them. Hopefully, before the Congress. -- From peter at digitalbrains.com Thu Dec 20 11:51:44 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 20 Dec 2018 11:51:44 +0100 Subject: Using GnuK with DFU bootloader In-Reply-To: <87r2ecwosg.fsf@fsij.org> References: <87zhtcdc7k.fsf@iwagami.gniibe.org> <87bm5qgurt.fsf@fsij.org> <87r2ecwosg.fsf@fsij.org> Message-ID: <40b1cbd1-81aa-069a-0c44-254cd579ff1e@digitalbrains.com> Hello Niibe! On 20/12/2018 10:06, NIIBE Yutaka wrote: > I think that you meant four commits which ends by the commit of > 00039c2419919b396ff11f119820f8cae5ab1d31, right? Yes, exactly. > I'll merge them. Hopefully, before the Congress. Very cool, thanks! By the way, when I wrote: On 18/12/2018 18:59, Peter Lebbing wrote: > I have tried several things with a Maple Mini with this GnuK and it > behaved completely normally. I again didn't communicate very clearly. I actually did quite a lot of testing. I hooked the GNU debugger up to a board through SWD, and placed breakpoints at suitable places. Of the code I've written, I verified that it did what I expected it to do. Correctly erase the start of flash up to the running GnuK copy. Copy the new SYS at the start of flash. Verify that the end result is that the first 4 KiB is byte for byte equal to the first 4 KiB of a release 1.2.11 stock GnuK firmware. Verify that on reGNUal invocation, all but the first 4 KiB is erased and reGNUal correctly executed. Finally, at the end, add setting of flash readout protection to the code (which precludes debugging) and verify that flash is indeed protected. Verify that if --with-dfu is not supplied, the result is the same as before the patches, comparing disassembled code. Probably some more stuff. I took my time testing. I meant that /in addition to/ all these tests, I also did a test to see the behaviour of everything I didn't change still appeared to be the same. So it was quite silly of me to only mention the latter :-). Regards, 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 wk at gnupg.org Thu Dec 20 12:58:00 2018 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Dec 2018 12:58:00 +0100 Subject: Distribution of binary In-Reply-To: <8ed318e1-6048-7f1e-b2f1-fae1e30188c4@digitalbrains.com> (Peter Lebbing's message of "Wed, 12 Dec 2018 15:48:24 +0100") References: <87zhtcdc7k.fsf@iwagami.gniibe.org> <8ed318e1-6048-7f1e-b2f1-fae1e30188c4@digitalbrains.com> Message-ID: <871s6cpfzr.fsf@wheatstone.g10code.de> Hi! On Wed, 12 Dec 2018 15:48, peter at digitalbrains.com said: > Mini if you don't have equipment. If I can give them a Maple Mini with > GnuK but with a VID:PID of 0000:0000, they could build their own GnuK on > Debian stable, which is really simple, and reGNUal their design into it. May I suggest to use 1209:2440 for such uses? I applied for this PID (what a silly acronym given that it is used more commonly on all operating systems for sometjhing very different) so that we can distribute our own token as member ship card and also for the use cases you described. See http://pid.codes/1209/2440/. Many thanks to the pid.codes folks for assigning that PID. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From peter at digitalbrains.com Thu Dec 20 14:01:44 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 20 Dec 2018 14:01:44 +0100 Subject: Distribution of binary In-Reply-To: <871s6cpfzr.fsf@wheatstone.g10code.de> References: <87zhtcdc7k.fsf@iwagami.gniibe.org> <8ed318e1-6048-7f1e-b2f1-fae1e30188c4@digitalbrains.com> <871s6cpfzr.fsf@wheatstone.g10code.de> Message-ID: Hi! 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. 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") 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. 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'". > I applied for this PID Nice callback to the RFC :-). > (what a silly acronym given that it is used more commonly on all > operating systems for sometjhing very different) Product, process... (production process?). It would be more descriptive if they called them VendID and ProdID. Or name it a Device rather than a Product. > Many thanks to the pid.codes folks for assigning that PID. Yes, they have my thanks as well. It's a great service they are providing. The USB spec should have worked with 128-bit UUID's generated by vendors without central oversight from the get-go, if you ask me. This might have even prevented Microsoft from creating the Microsoft OS Descriptors as a proprietary method of not relying on the USB-IF supplied identifiers. Then again, embrace, *extend*, extinguish, right? Cheers, Peter. [1] -- 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 gniibe at fsij.org Fri Dec 21 04:02:20 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 21 Dec 2018 12:02:20 +0900 Subject: Using GnuK with DFU bootloader In-Reply-To: <40b1cbd1-81aa-069a-0c44-254cd579ff1e@digitalbrains.com> References: <87zhtcdc7k.fsf@iwagami.gniibe.org> <87bm5qgurt.fsf@fsij.org> <87r2ecwosg.fsf@fsij.org> <40b1cbd1-81aa-069a-0c44-254cd579ff1e@digitalbrains.com> Message-ID: <87lg4jr39f.fsf@iwagami.gniibe.org> Hello, Peter, I cherry picked your changes into master, writing ChangeLog entries. Peter Lebbing wrote: > I actually did quite a lot of testing. Thanks a lot for your intensive testing. I have a little concern here. diff --git a/src/main.c b/src/main.c index a8c80b6..04a8c9e 100644 --- a/src/main.c +++ b/src/main.c @@ -141,7 +141,7 @@ device_initialize_once (void) addr = ORIGIN_REAL + 0x1000; if (addr < ORIGIN) { - /* Need to patch reset vector there */ + /* Patch vectors by vector_table??? */ handler *new_vector = (handler *) addr; flash_write((uintptr_t) &new_vector[1], (const uint8_t *) &vector[1], sizeof(handler)); After writing Gnuk for DFU to the board, at the first run, it writes new SYS killing DFU, and in the code above, the reset vector is patched. This is no problem, if a user upgrades Gnuk with reGNUal at the first run (because, for the first run, SCR->VCR and MSP are configured by DFU, and then configured again by old SYS). For the second run, for me, it is more clear and clean if all vectors are updated by vector_table of chopstx/entry.c. Currently, it updates only the reset vector by old SYS reset routine ("old" means SYS for DFU, here). For the second run (if any), the control goes from new SYS:reset to old SYS:reset which again sets SCR->VCR and MSP. (In this transition, MSP is once set to 0xffffffff, which is not correct.) This sounds not great. Well, it's acceptable, because nobody should keep using Gnuk for DFU. In this morning, I tried to modify the code, but I realized that the sizeof(vector_table) is not determined at the compile time of main.c, in the current code of chopstx/entry.c. So, I didn't change the code. Please make sure the second reset works well. I mean, after writing Gnuk for DFU (by DFU), reset (which kills DFU by new SYS), reset again, and upgrade by reGNUal. -- From peter at digitalbrains.com Sat Dec 22 15:05:12 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 22 Dec 2018 15:05:12 +0100 Subject: Using GnuK with DFU bootloader In-Reply-To: <87lg4jr39f.fsf@iwagami.gniibe.org> References: <87zhtcdc7k.fsf@iwagami.gniibe.org> <87bm5qgurt.fsf@fsij.org> <87r2ecwosg.fsf@fsij.org> <40b1cbd1-81aa-069a-0c44-254cd579ff1e@digitalbrains.com> <87lg4jr39f.fsf@iwagami.gniibe.org> Message-ID: <26c8c375-536c-bd8e-8afb-7746ccc2f777@digitalbrains.com> Hello Niibe! On 21/12/2018 04:02, NIIBE Yutaka wrote: > This sounds not great. Well, it's acceptable, because nobody should > keep using Gnuk for DFU. I think it's fine to just use the GnuK that was uploaded through DFU. The bootloader is erased and readout protection enabled, it should be as safe as a normal bare-programmed GnuK. > In this morning, I tried to modify the code, but I realized that the > sizeof(vector_table) is not determined at the compile time of main.c, in > the current code of chopstx/entry.c. So, I didn't change the code. I don't think it's necessary (see further mail), but as an aside: it would still be possible by using an undefined symbol, and having the linker fill in that symbol with the correct data. If you don't have a custom linker script yet, it's cumbersome, because then you do need it. But you already have a custom linker script, so it's easy. > Please make sure the second reset works well. I mean, after writing > Gnuk for DFU (by DFU), reset (which kills DFU by new SYS), reset again, > and upgrade by reGNUal. I tried that, and it seems to work fine. I did now also notice the unintended behaviour with regard to MSP, but it doesn't change run-time behaviour. I somehow hadn't realized it was loading the initial MSP from 0x8001000. This appears to be harmless because it is overwritten with the correct value very soon after, before it is ever used. But I fixed it and in the following discussion, I will describe the fixed behaviour, because the subject matter is already complicated enough without discussing this as well. It might be there's some confusion with all the vector tables while trying to understand the code flow. First, for easy reference, let's show the vector tables for a bare-programmed GnuK: 0x8000000 sys-stm32f103.c::vector 0x8001000 chopstx/entry.c::vector_table On with the DFU stuff. The smallest DFU bootloader possible with this code would be 4 KiB long, hence it would locate the user code at 0x8001000. If it would locate before that, the DFU-mode GnuK would be overwriting itself with the new SYS. We distinguish two cases: DFU-mode GnuK is at 0x8001000 or it is at a higher address. First, let's take the, as far as I'm aware, hypothetical situation we have a bootloader only 4 KiB large, and it loads user code at 0x8001000. We have the following tables: 0x8000000 stdaln-sys.elf::vector 0x8001000 sys-stm32f103.c::vector 0x8002000 chopstx/entry.c::vector_table The latter two are from the DFU-mode GnuK, only the range 0x8000000-0x8000fff comes from stdaln-sys.elf. When the Maple Mini boots, it ends up in stdaln-sys.elf::reset. This sets SCR->VCR as it would be for a bare-programmed Maple Mini. It then loads MSP with vector[0] at 0x8001000, but this is equal to the initial MSP at reset, so it is a no-operation. It seems unavoidable because we need the first 4 KiB to be exactly equal to a bare-programmed chip so we can reGNUal a normal GnuK into it later.[1] It then jumps to sys-stm32f103.c::reset from the vector table at 0x8001000, which again modifies SCR->VCR and MSP to be correct for a GnuK at that origin (0x8001000). In fact, it just overwrites the actions of stdaln-sys.elf::reset, and correctly sets the initial MSP from vector_table[0]. Finally, it jumps to chopstx/entry.c::entry, which it got from vector_table[1] in the table at 0x8002000. After the jump to sys-stm32f103.c::reset, no code from stdaln-sys.elf will ever run again, until we do a reGNUal. And only sys-stm32f103.c::vector and chopstx/entry.c::vector_table are ever used during further running. We need to have the whole of stdaln-sys.elf unmodified at the first 4 KiB, because that's what we rely on if ever we update the GnuK with reGNUal. But it only runs a few lines of code at first bootup, whose actions even get nullified by the code that runs after. Now the other situation, where the bootloader is larger than 4 KiB. Let's say it loads code at 0x8002000. This is correct for the Maple Mini. Then we have the following tables: 0x8000000 stdaln-sys.elf::vector 0x8002000 sys-stm32f103.c::vector 0x8003000 chopstx/entry.c::vector_table This is where that line of code we're discussing kicks in. The processor boots, it goes to stdaln-sys.elf::reset, and all that code does is set up SCR->VCR, load MSP from 0x8001000 and jump to the address at 0x8001004. Oops. That page is blank. So, I put the address of sys-stm32f103.c::reset at 0x8001004 so it goes right. And with the new fix, it gets the proper initial MSP. Once we end up in sys-stm32f103.c::reset, the only vector tables that will ever be used are sys-stm32f103.c::vector at 0x8002000 (!) and choptx/entry.c::vector_table at 0x8003000. Only a few cycles after cpu reset will anything in 0x8001000 be used. Only stdaln-sys.elf::reset runs, which reads the first two vectors. During further running, ORIGIN is set to 0x8002000, which is higher than that. The SYS at the start of the memory might need vector_table at 0x8001000, but it never runs again until reGNUal, and then only flash_erase_all_and_exec() runs. I did assume flash_erase_all_and_exec() would never need the vector_table, seeing how it is erasing all memory but the first 4 KiB, which includes vector_table and currently all entries in it. But the SYS at 0x8002000 and the GnuK at 0x8003000 never refer to anything at 0x8001000, so there is no need to put a vector table there. If you expect SYS ever to be using vector_table even before it jumps to chopstx/entry.c::entry, then yes, we have a problem. Faults and interrupts that occur in sys-stm32f103.c::reset will for a short time have a bogus vector table (currently interrupts are disabled, so there's no problem). However, any such code would have to be considered well anyway because it mixes code linked at different ORIGINs, and that might be a recipe for disaster. Since it is currently not used and would require special attention due to mixed ORIGINs if it were ever used, I didn't think copying the vector table was called for. But as long as sys-stm32f103.c::reset is as lean as it is now, there's no problem. As soon as chopstx/entry.c::entry is entered all vectors are fully correct, and only code from the high ORIGIN ever runs. I thought it rather unlikely sys-stm32f103.c::reset would ever get so heavyweight as to need interrupts, seeing how it is now. I fixed the issue with the wrong MSP for a DFU larger than 4 KiB in commit ca3312eb253e6a523e01b64903ebb08d336218ec. Since the MSP was overwritten with the correct value before anything used the stack, the original code ran fine. Interrupts were disabled until well after MSP was correct. I also added a reset after flash_protect(). The flash programming manual says: >The read protection is activated by setting the RDP option byte and >then, by applying a system reset to reload the new RDP option byte. so it's probably better to add that reset. Incidentally, I also fixed two clean targets in the next commit, b57c33c204f7fc5c04aab7b2ffd0f7e0bfdc78ea. It's a tiny change. Both can be found in [2]. If you would still like to have all of vector_table at 0x8001000 (but with the reset vector patched to sys-stm32f103.c::reset), I could write that as well. Also, I was happy to discover that actually, the boards I bought to perhaps be handed out to some people at the 35C3 /do/ have the small STM32duino bootloader that is required for GnuK in DFU-mode! Up until now, I had been testing with an old board revision I bought in May 2017. It turns out that in the boards I ordered a few weeks ago they updated the bootloader (the schematic is unchanged, but they did change the board, it now uses a micro-USB connector rather than mini-USB). Regards, Peter. [1] Perhaps you could make it so a DFU-programmed GnuK can only ever be updated with a --with-dfu configured GnuK, then the restriction could be weakened if this ever becomes necessary. [2] -- 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 peter at digitalbrains.com Sat Dec 22 15:15:01 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 22 Dec 2018 15:15:01 +0100 Subject: Distribution of binary In-Reply-To: <875zvxdki0.fsf@fsij.org> References: <87zhtcdc7k.fsf@iwagami.gniibe.org> <8ed318e1-6048-7f1e-b2f1-fae1e30188c4@digitalbrains.com> <877egegtw6.fsf@fsij.org> <9b3783be-d288-ef12-c453-85ab3ea8708d@digitalbrains.com> <875zvxdki0.fsf@fsij.org> Message-ID: <9ae823fd-8eeb-a09e-f243-55a8ce2088bd@digitalbrains.com> Hello Niibe! On 14/12/2018 01:23, NIIBE Yutaka wrote: > (c) Selling it at eBay (or equivalent). > > If it will happen, the step (c) violates the assumption of experimental > personal use, and it will put FSIJ into difficult situation about their > management of VID. I'd say that the step (c) constitutes a distribution > of binary, if I were a lawyer. Yes, that would be bad. If we could quickly decide on the proper vendor/product strings for VID:PID 1209:2440, I can simply tell anyone interested to use that. I don't even know if I'll be giving anybody a board :-). I mean, I'm not going to walk around with a sign with a big arrow that says "free GnuKs for experiments available here" :-). Regards, Peter. [1] [2] -- 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 peter at digitalbrains.com Sun Dec 23 12:41:37 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 23 Dec 2018 12:41:37 +0100 Subject: Using GnuK with DFU bootloader In-Reply-To: <87lg4jr39f.fsf@iwagami.gniibe.org> References: <87zhtcdc7k.fsf@iwagami.gniibe.org> <87bm5qgurt.fsf@fsij.org> <87r2ecwosg.fsf@fsij.org> <40b1cbd1-81aa-069a-0c44-254cd579ff1e@digitalbrains.com> <87lg4jr39f.fsf@iwagami.gniibe.org> Message-ID: <186cec82-7a91-a4da-ca6f-41dfd8cc22ec@digitalbrains.com> Hello Niibe! On 21/12/2018 04:02, NIIBE Yutaka wrote: > I cherry picked your changes into master, writing ChangeLog entries. That's great, thanks a lot! And thanks for doing it so fast! (I was so focussed on the issue I forgot to thank you earlier... I apologize for that.) Regards, 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 avamander at gmail.com Sun Dec 23 12:53:51 2018 From: avamander at gmail.com (Avamander) Date: Sun, 23 Dec 2018 13:53:51 +0200 Subject: U2F and nRF52840 Message-ID: Hello As I was kindly informed by Niibe Yutaka that he doesn't have time for answering questions in private non-encrypted e-mail and that I should ask here instead, so I'm going to ask here, I hope that's fine. My first question was about U2F. As far as I could see, client certificate TLS authentication isn't widespread enough, the biggest deployment probably being Estonian ID card authentication which isn't private at all, this leaves pretty much only U2F on the table if I want something a bit more secure (than just TOTP), correct? A while ago Niibe wrote that U2F is not worth (for him) to integrate into Gnuk, a year has passed, could the assessment have changed? If not, how (in)compatible is the current code with a possible U2F/UAF implementation? Second question was about porting Gnuk to other MCUs, is there a guide available somewhere? Or just some general architectural overview? I'd love to get/make Gnuk run on nRF52840 (and possibly get some functionality run over NFC/BT). Yours sincerely Avamander -------------- next part -------------- An HTML attachment was scrubbed... URL: From pablo1 at mailbox.org Sun Dec 23 13:34:15 2018 From: pablo1 at mailbox.org (Pablo Ovelleiro Corral) Date: Sun, 23 Dec 2018 13:34:15 +0100 Subject: Where to buy 128K st-links? Message-ID: <20181223123415.aitpxwk4jkxejo4g@kartoffel.localdomain> Hi, I have seen this post outlining how to run gnuk on a st-link device: https://blog.danman.eu/2-usb-crypto-token-for-use-with-gpg-and-ssh/ I would like to build one of those myself, but the problem seems to be to find the correct st-link device. There are a lot of sellers, but some of those keys seem to have a different version of the STM32 chip with only 64K. The one needed has a 128K flash chip on it. Most sellers don't specify the exact chip in the device, so it's a suprise what you get. Can anybody link me to a suppliers of those chips that delivers the 128K flash version? Has anybody build this and can share his experieces and where he got the device? 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 mike at sowbug.com Sun Dec 23 16:55:57 2018 From: mike at sowbug.com (Mike Tsao) Date: Sun, 23 Dec 2018 07:55:57 -0800 Subject: Where to buy 128K st-links? In-Reply-To: <20181223123415.aitpxwk4jkxejo4g@kartoffel.localdomain> References: <20181223123415.aitpxwk4jkxejo4g@kartoffel.localdomain> Message-ID: They're all 128K. See https://wiki.stm32duino.com/index.php?title=Blue_Pill for one discussion. If you use stlink to program, you need a version that knows the chip is 128K: https://lists.gnupg.org/pipermail/gnuk-users/2018-February/000019.html On Sun, Dec 23, 2018, 6:19 AM Pablo Ovelleiro Corral wrote: > > Hi, > > I have seen this post outlining how to run gnuk on a st-link device: > https://blog.danman.eu/2-usb-crypto-token-for-use-with-gpg-and-ssh/ > > I would like to build one of those myself, but the problem seems to be > to find the correct st-link device. > > There are a lot of sellers, but some of those keys seem to have a > different version of the STM32 chip with only 64K. The one needed has > a 128K flash chip on it. Most sellers don't specify the exact chip in > the device, so it's a suprise what you get. > > Can anybody link me to a suppliers of those chips that delivers the > 128K flash version? Has anybody build this and can share his > experieces and where he got the device? > > Cheers, > > Pablo > > -- > Pablo Ovelleiro Corral > Web: http://pablo.tools > XMPP: pablo1 at mailbox.org > _______________________________________________ > Gnuk-users mailing list > Gnuk-users at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnuk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Sun Dec 23 17:40:50 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 23 Dec 2018 17:40:50 +0100 Subject: Where to buy 128K st-links? In-Reply-To: References: <20181223123415.aitpxwk4jkxejo4g@kartoffel.localdomain> Message-ID: <88d6c10f-b4ab-2f36-1be0-c8ec89bce032@digitalbrains.com> Hi, First of all, Pablo, thanks for the interesting link :-). On 23/12/2018 16:55, Mike Tsao wrote: > They're all 128K. See > https://wiki.stm32duino.com/index.php?title=Blue_Pill for one > discussion. The blog post mentions the chip is a STM32F101CBT6. Note the one instead of a three. But it goes on to mention others had found out they might well just be a 103 on the inside. Even though the mentioned 101 is advertised as having 128 KiB flash, it is advertised as having 16 KiB of RAM instead of the 103's 20 KiB. Now, it might be this is again untrue, but it might lead to trouble if it really ends at 16 KiB. I just looked at a compile with master, ./configure --vidpid=234b:0000 --target=ST_DONGLE --enable-factory-reset --enable-certdo and the heap starts at just over 10 KiB. That means you can allocate a bit less than 6 KiB of data before it will crash horribly ;-). I have no idea how much RAM is allocated on the heap by GnuK, but it could lead to trouble. Possibly quicker when a reGNUal is attempted... It would be interesting to confirm some RAM sizes on some of these devices. Not by looking at configuration registers, but by just writing and reading data (mind any aliasing of addresses, though). My 2 cents, 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 wk at gnupg.org Sun Dec 23 20:49:34 2018 From: wk at gnupg.org (Werner Koch) Date: Sun, 23 Dec 2018 20:49:34 +0100 Subject: Distribution of binary In-Reply-To: <9ae823fd-8eeb-a09e-f243-55a8ce2088bd@digitalbrains.com> (Peter Lebbing's message of "Sat, 22 Dec 2018 15:15:01 +0100") References: <87zhtcdc7k.fsf@iwagami.gniibe.org> <8ed318e1-6048-7f1e-b2f1-fae1e30188c4@digitalbrains.com> <877egegtw6.fsf@fsij.org> <9b3783be-d288-ef12-c453-85ab3ea8708d@digitalbrains.com> <875zvxdki0.fsf@fsij.org> <9ae823fd-8eeb-a09e-f243-55a8ce2088bd@digitalbrains.com> Message-ID: <87muowkoq9.fsf@wheatstone.g10code.de> On Sat, 22 Dec 2018 15:15, peter at digitalbrains.com said: > Yes, that would be bad. If we could quickly decide on the proper > vendor/product strings for VID:PID 1209:2440, I can simply tell anyone Linux already has a list of vendors, so the VID should not be a problem. For 2440 I would suggest "An OpenPGP Token" to keep it flexible. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From peter at digitalbrains.com Sun Dec 23 21:42:26 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 23 Dec 2018 21:42:26 +0100 Subject: Distribution of binary In-Reply-To: <87muowkoq9.fsf@wheatstone.g10code.de> References: <87zhtcdc7k.fsf@iwagami.gniibe.org> <8ed318e1-6048-7f1e-b2f1-fae1e30188c4@digitalbrains.com> <877egegtw6.fsf@fsij.org> <9b3783be-d288-ef12-c453-85ab3ea8708d@digitalbrains.com> <875zvxdki0.fsf@fsij.org> <9ae823fd-8eeb-a09e-f243-55a8ce2088bd@digitalbrains.com> <87muowkoq9.fsf@wheatstone.g10code.de> Message-ID: <5947c1d1-5a95-106f-040e-0a653aeb5ea8@digitalbrains.com> Hello Werner! On 23/12/2018 20:49, Werner Koch wrote: > Linux already has a list of vendors, so the VID should not be a problem. > For 2440 I would suggest "An OpenPGP Token" to keep it flexible. ACK on the product string. But the device needs to report a string to the computer with the vendor in it. The vendor list used by Linux says > 1209 InterBiometrics because that is the original owner of the VID. It seems weird to have the device report that... I think it is technically completely compliant to not report a vendor string at all, but this would need source code changes to drop the reference to the string. I don't know whether an empty string (rather than no string) is compliant. (Note that Linux currently does not name the GnuK at all, since it has no entry for the FSIJ VID at all. However, the strings reported by the device itself are "Free Software Initiative of Japan"/"Gnuk Token".) 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 gniibe at fsij.org Wed Dec 26 05:19:12 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 26 Dec 2018 13:19:12 +0900 Subject: Chopstx 1.13 and FST-01SZ In-Reply-To: <87o99gsviu.fsf@iwagami.gniibe.org> References: <87o99gsviu.fsf@iwagami.gniibe.org> Message-ID: <8736qk2a4f.fsf@iwagami.gniibe.org> Hello, FST-01SZ, which is now in production, uses a bit of different connector (than its prototype). This version has four slits in the bottom side. I think that the purpose of change is to reduce materials. I put the datasheet as: fst-01/datasheet/ZL-272-variant.pdf But... it seems that... it looks like they (a company in Dong Guang, next to ShenZhen) use competitor's manufacturer product number, although it's a bit different. This is confusing. I wish the quality is good. -- From gniibe at fsij.org Wed Dec 26 06:53:58 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 26 Dec 2018 14:53:58 +0900 Subject: Using GnuK with DFU bootloader In-Reply-To: <26c8c375-536c-bd8e-8afb-7746ccc2f777@digitalbrains.com> References: <87zhtcdc7k.fsf@iwagami.gniibe.org> <87bm5qgurt.fsf@fsij.org> <87r2ecwosg.fsf@fsij.org> <40b1cbd1-81aa-069a-0c44-254cd579ff1e@digitalbrains.com> <87lg4jr39f.fsf@iwagami.gniibe.org> <26c8c375-536c-bd8e-8afb-7746ccc2f777@digitalbrains.com> Message-ID: <87wonwzvd5.fsf@iwagami.gniibe.org> Hello Peter, Thanks for your fixes. I merged and released Gnuk 1.2.13. tag release/1.2.13 Tagger: NIIBE Yutaka Date: Wed Dec 26 14:14:23 2018 +0900 commit b7368e41e9d15f3f1d25572a8dc3bf53bfa95723 > It might be there's some confusion with all the vector tables while > trying to understand the code flow. Yes. It's complicated. > I also added a reset after flash_protect(). The flash programming manual > says: >>The read protection is activated by setting the RDP option byte and >>then, by applying a system reset to reload the new RDP option byte. > so it's probably better to add that reset. IIUC, it is recommended to have power off -> power on cycle, when we change the RDB option byte. Perhaps, I am confused about the case of mass erase. Anyway, for this particular case, I thik that it is recommended to have power off -> power on cycle, after the first run (which kills DFU). As I added a comment in the commit log, we should know that this reset event in the first run uses old RESET vector. This does not go through newly written SYS. Thus, the VCR register keeps its old value. When there is no power cycle, after reGNUal's reset, it might go wrong place. > Incidentally, I also fixed two clean targets in the next commit, > b57c33c204f7fc5c04aab7b2ffd0f7e0bfdc78ea. It's a tiny change. Both can > be found in [2]. Thank you. All merged. > Also, I was happy to discover that actually, the boards I bought to > perhaps be handed out to some people at the 35C3 /do/ have the small > STM32duino bootloader that is required for GnuK in DFU-mode! Up until > now, I had been testing with an old board revision I bought in May 2017. > It turns out that in the boards I ordered a few weeks ago they updated > the bootloader (the schematic is unchanged, but they did change the > board, it now uses a micro-USB connector rather than mini-USB). It seems that it's common in China. I hope they change MPN (manufacturer part number), when having such changes (hardware-wise or firmware-wise), so that a user can distinguish changes. -- From gniibe at fsij.org Wed Dec 26 07:55:47 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 26 Dec 2018 15:55:47 +0900 Subject: U2F and nRF52840 In-Reply-To: References: Message-ID: <87k1jwzsi4.fsf@iwagami.gniibe.org> Hello, Please note that Gnuk is a firmware which supports OpenPGP card protocol. With its capability of three private keys, OpenPGP card supports digital signature, encryption, and authentication. Speaking about authentication, we can put SSH key, by its authentication feature. Avamander wrote: > My first question was about U2F. As far as I could see, client certificate > TLS authentication isn't widespread enough, the biggest deployment probably > being Estonian ID card authentication which isn't private at all, this > leaves pretty much only U2F on the table if I want something a bit more > secure (than just TOTP), correct? I don't know about current situation of web authentication well. Currently, I don't use any services which use/require U2F. I think that client certificate TLS authentication is still good, when it is our own server. We have (very experimental) software for OpenPGP card, called Scute, which enables client certificate TLS authentication with the card/token. Once, around 2012, I used Scute with Gnuk Token to be authenticated by my own OpenID server, so that I could login to other services with OpenID. Unfortunately, OpenID hasn't become popular enough. If I will need to use U2F, I will implement another firmware software using some parts of Gnuk (USB, CCID, and Crypto). That's because, for me, the use cases sound very different. For typical use cases of OpenPGP card, it's your encrypted resources, to be accessed. Or you are going make digital signature for your data in your control. For web authentication with U2F, it is some external service provider, who asks your identity with a dongle. It seems for me that it's not good idea to use a single device (or single software) for both use cases. > 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. > Second question was about porting Gnuk to other MCUs, is there a guide > available somewhere? I don't know about such a guide. Last year, Aurelien Jarno did some work for STM32L432. > I'd love to get/make Gnuk run on nRF52840 (and possibly get some > functionality run over NFC/BT). Use of wireless technology requires another encryption. And, I just found that nRF52840 comes with hardware crypto accelerator. Well, while some keywords are some, I feel that we are taling about somehow different topics. For Gnuk, I'm talking about ... something like a bicycle which I can control using my own skill and my own energy. I'm afraid you are talking about something like luxury automatic car. Gnuk doen't depend on any hardware crypto accelerator. This is on purpose. It is important for Gnuk to minimize attack surface. A hardware crypto accelerator by semiconductor vendor, which is difficult to examine by its users, can bring possible attack vectors. In many cases, development with a hardware crypto accelerator might require NDA, which can bring another type attack vector (say, of social engineering). -- From peter at digitalbrains.com Fri Dec 28 20:08:13 2018 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 28 Dec 2018 20:08:13 +0100 Subject: Using GnuK with DFU bootloader In-Reply-To: <87wonwzvd5.fsf@iwagami.gniibe.org> References: <87zhtcdc7k.fsf@iwagami.gniibe.org> <87bm5qgurt.fsf@fsij.org> <87r2ecwosg.fsf@fsij.org> <40b1cbd1-81aa-069a-0c44-254cd579ff1e@digitalbrains.com> <87lg4jr39f.fsf@iwagami.gniibe.org> <26c8c375-536c-bd8e-8afb-7746ccc2f777@digitalbrains.com> <87wonwzvd5.fsf@iwagami.gniibe.org> Message-ID: <977d88f3-a298-ba83-8c49-48283f3b7a21@digitalbrains.com> Hello Niibe! On 26/12/2018 06:53, NIIBE Yutaka wrote: > Thanks for your fixes. I merged and released Gnuk 1.2.13. Thank you, it's much appreciated! > As I added a comment in the commit log, we should know that this reset > event in the first run uses old RESET vector. This does not go through > newly written SYS. Thus, the VCR register keeps its old value. When > there is no power cycle, after reGNUal's reset, it might go wrong place. I've been investigating this when I had free time during the congress. I think that it's not the case that the NVIC system reset actually uses a relocated vector table to find the reset vector! It is my interpretation that on NVIC system reset, the VCR register is cleared to default and the vector at 0x0000 0004 and MSP at 0x0000 0000 are taken. I've found statements on reset and reset vector in the following sections: Programming Manual (PM0056): - Page 15 -> Stack pointer and Program counter - Page 32 -> Reset - Page 15 -> Directly below figure - Page 133 -> Vector table offset register reset value Reference manual (RM0008): - Page 90 -> System reset ("resets all registers to their reset values except...") and they explicitly group 'Software reset' under this type of reset. And this is also what seems to happen when nvic_system_reset() is invoked from device_initialize_once(), as the following gdb trace seems to indicate. Now, debugging over reset is a bit funky, openocd drops the connection for a moment (fraction of a second), but the program counter when it picks up again is where it would be for the vector at 0x0000 0004. The break at 0x80031d8 is at main.c:154, the call to nvic_system_reset from device_initialize_once(). I show all the various vector tables, and then single-step over the reset instruction. What we see is that openocd regains control at 0x8000272, which is only referenced from the table at 0x8000000. So it appears that is the table that is used, i.e., VCR is cleared before the reset vector is looked up. While reading, keep a close eye on the hexadecimal address of a function. Since there are sys-stmf103.o's at both 0x8000000 and 0x8002000, the labels are ambiguous and you need the address to know which of those it refers to. --8<---------------cut here---------------start------------->8--- $ arm-none-eabi-gdb --eval-command="target remote :3333" build/gnuk.elf GNU gdb (7.12-6+9+b2) 7.12.0.20161007-git [...] Reading symbols from build/gnuk.elf...done. Remote debugging using :3333 0x080000f0 in ?? () (gdb) add-symbol-file build/stdaln-sys.elf 0x8000000 add symbol table from file "build/stdaln-sys.elf" at .text_addr = 0x8000000 (y or n) y Reading symbols from build/stdaln-sys.elf...warning: section .text not found in /home/peter/src/arm/gnuk/src/build/stdaln-sys.elf done. (gdb) break *0x80031d8 Breakpoint 1 at 0x80031d8: file ../chopstx/mcu/sys-stm32f103.h, line 119. (gdb) continue Continuing. Note: automatically using hardware breakpoints for read-only addresses. Breakpoint 1, 0x080031d8 in nvic_system_reset () at ../chopstx/mcu/sys-stm32f103.h:119 119 (func) (); (gdb) display/i $pc 1: x/i $pc => 0x80031d8 : blx r3 (gdb) display/a $msp 2: /a $msp = 0x20000060 (gdb) x/a 0xe000ed00 + 8 0xe000ed08: 0x8003000 (gdb) x/2a 0x8000000 0x8000000 : 0x20005000 0x8000271 (gdb) x/2a 0x8001000 0x8001000: 0x20000060 0x8002271 (gdb) x/2a 0x8002000 0x8002000 : 0x20005000 0x8002271 (gdb) x/2a 0x8003000 0x8003000 : 0x20000060 0x8003491 (gdb) si 6 0x08002260 309 SCB->AIRCR = (0x05FA0000 | (SCB->AIRCR & 0x70) | SCB_AIRCR_SYSRESETREQ); 1: x/i $pc => 0x8002260 : str r3, [r1, #12] 2: /a $msp = 0x20000060 (gdb) si 0x08000272 in reset () at ../chopstx/mcu/sys-stm32f103.c:323 323 asm volatile ("cpsid i\n\t" /* Mask all interrupts. */ 1: x/i $pc => 0x8000272 : ldr r0, [pc, #32] ; (0x8000294 ) 2: /a $msp = 0x20005000 (gdb) --8<---------------cut here---------------end--------------->8--- OpenOCD complains on that (last) "si" above: --8<---------------cut here---------------start------------->8--- Info : SWD IDCODE 0x1ba01477 Error: Failed to read memory at 0xfffff000 --8<---------------cut here---------------end--------------->8--- I don't know why that error is there. It has something to do with a reset during a debugging session. So... I think the VCR register contents don't matter on invoking nvic_system_reset(). Also, I think that if a "reset" call from a bare-programmed GnuK works, then a "reset" call from a DFU-programmed GnuK should work as well. On a bare-programmed GnuK, it would take these vectors if VCR were unchanged: --8<---------------cut here---------------start------------->8--- (gdb) x/a 0xe000ed00 + 8 0xe000ed08: 0x8001000 (gdb) x/2a 0x8001000 0x8001000 : 0x20000060 0x80013f1 --8<---------------cut here---------------end--------------->8--- That's no different than a DFU-programmed GnuK taking the vectors at 0x8003000: they would both skip setting up the VCR and take the correct MSP directly from the vector table, and continue running in the main application. However, current GnuK doesn't ever invoke nvic_system_reset() AFAIK. reGNUal does, and actually has VCR pointing into the SRAM when it calls nvic_system_reset(). Again, this is a moot point since VCR is not used. I investigated the reGNUal reset and it goes fine as well. > It seems that it's common in China. I hope they change MPN > (manufacturer part number), when having such changes (hardware-wise or > firmware-wise), so that a user can distinguish changes. I think they handled it pretty well. The silkscreen of the board clearly indicates a new board revision. The AliExpress product ID is the same. The old "item specifics" didn't mention a model number, but the new one has the new board revision as the model number now. The product pictures clearly show a new board with a new board revision code clearly visible in the silkscreen. And the new bootloader is compatible with the old bootloader in usage, so it's a very welcome improvement that they now flash the more advanced bootloader STM32duino-bootloader. They had one omission: the product text still says you need a mini-B cable. I alerted them to this and they said they would change the text. I agree it could be even better, but at the price point they sell them at, you really can't realistically expect everything to be best of industry :-). I hope this clears up some more details! Regards, 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 gniibe at fsij.org Sat Dec 29 01:45:26 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Sat, 29 Dec 2018 09:45:26 +0900 Subject: Using GnuK with DFU bootloader In-Reply-To: <977d88f3-a298-ba83-8c49-48283f3b7a21@digitalbrains.com> References: <87zhtcdc7k.fsf@iwagami.gniibe.org> <87bm5qgurt.fsf@fsij.org> <87r2ecwosg.fsf@fsij.org> <40b1cbd1-81aa-069a-0c44-254cd579ff1e@digitalbrains.com> <87lg4jr39f.fsf@iwagami.gniibe.org> <26c8c375-536c-bd8e-8afb-7746ccc2f777@digitalbrains.com> <87wonwzvd5.fsf@iwagami.gniibe.org> <977d88f3-a298-ba83-8c49-48283f3b7a21@digitalbrains.com> Message-ID: <87pntlupnd.fsf@fsij.org> Hello, Peter, Thanks a lot for your correcting my misunderstanding. Well, I wonder how I will put the correction to the wrong description in my commit log. Perhaps, I will address it in another commit log. Peter Lebbing wrote: > I think that it's not the case that the NVIC system reset actually uses > a relocated vector table to find the reset vector! It is my > interpretation that on NVIC system reset, the VCR register is cleared to > default and the vector at 0x0000 0004 and MSP at 0x0000 0000 are taken. > I've found statements on reset and reset vector in the following > sections: > > Programming Manual (PM0056): > - Page 15 -> Stack pointer and Program counter > - Page 32 -> Reset > - Page 15 -> Directly below figure > - Page 133 -> Vector table offset register reset value > Reference manual (RM0008): > - Page 90 -> System reset ("resets all registers to their reset values > except...") and they explicitly group 'Software reset' under this type > of reset. > > And this is also what seems to happen when nvic_system_reset() is > invoked from device_initialize_once(), as the following gdb trace seems > to indicate. [...] > So... I think the VCR register contents don't matter on invoking > nvic_system_reset(). I see. Thank you for your time to investigate this. Then, there are no problem what I was care of. It goes through by new SYS reset routine, and reGNUal will be able to use new SYS routines. > However, current GnuK doesn't ever invoke nvic_system_reset() AFAIK. > reGNUal does, and actually has VCR pointing into the SRAM when it calls > nvic_system_reset(). Again, this is a moot point since VCR is not used. > I investigated the reGNUal reset and it goes fine as well. I had forgotten this case when I wrote previous mail. Indeed, if current VCR were used for nvic_system_reset, this wouldn't work. BTW, today, I can't find the reason why I call it VCR (vector control register, which we have the name in the comment of mcu/sys-stm32f103.c). In ARMv7m manual and Cortex-M3 manual, it is called VTOR (vector table offset register). I'm going to fix the comment in Chopstx, to avoid confusion. --