From akktor at net-c.ca Sun Nov 11 17:22:13 2018 From: akktor at net-c.ca (akktor) Date: Sun, 11 Nov 2018 11:22:13 -0500 Subject: Usage of usb gnuk token Message-ID: <6ed9db92-f3e0-894d-5c68-4597f5a928eb@net-c.ca> Hi. I have ubuntu 18.04. I have fst-01. I want to use it with login and sudo command. What should I do? Regardss -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Mon Nov 12 07:27:15 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 12 Nov 2018 15:27:15 +0900 Subject: Usage of usb gnuk token In-Reply-To: <6ed9db92-f3e0-894d-5c68-4597f5a928eb@net-c.ca> References: <6ed9db92-f3e0-894d-5c68-4597f5a928eb@net-c.ca> Message-ID: <878t1ybykc.fsf@fsij.org> akktor wrote: > Hi. I have ubuntu 18.04. I have fst-01. I want to use it with login and > sudo command. > > What should I do? I maintain Poldi in Debian, which offers PAM module with OpenPGP card / Gnuk Token. Attached is my patch to configure lightdm for Poldi, for your reference. No, I don't use that other than testing Poldi. It's for your reference only. I use etc-keeper for files under /etc, and the patch is to show what kinds of files you need to provide. It's for my key and my login. You need to change login name and key informtion. For detail, please read Poldi documentation. After just putting "RETURN" for the prompt of lightdm, you enter PIN for your token and then, you can login by token's singing data and computer's verification of the signature. Here, PIN input is required, because it's OpenPGP card. Please note that Poldi is expelimental software, which is not well designed and implemented, in my opinion. I think that the use case of Gnuk Token for OpenPGP signing/decryption is quite different to the use case for local machine login / sudo using cryptographic key. And... from the viewpoint of device access by OS to an application, the use case for login and the use case of sudo is also different. In my opinion, while I'd somehow understand the demand to use a single "security device" for all such usages, it's not good idea to mix things. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: etc-changes-poldi-lightdm.patch Type: text/x-diff Size: 2110 bytes Desc: etc-changes-poldi-lightdm.patch URL: From gniibe at fsij.org Mon Nov 19 03:24:03 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 19 Nov 2018 11:24:03 +0900 Subject: Chopstx 1.12 Message-ID: <87o9al954s.fsf@iwagami.gniibe.org> Hello, Chopstx 1.12 is released. tag release/1.12 Tagger: NIIBE Yutaka Date: Mon Nov 12 15:29:05 2018 +0900 commit 39683dbc5f66e92457f031bdf303c8226e75d55e Now, I am testing acknowledge button with FST-01SZ prototype. Version 1.10, 1.11, and 1.12 are basically for FST-01SZ. Actually, I released Gnuk 1.2.11 for FST-01SZ prototype. Then, on Friday, I received the result of fusion PCBA service. I realized that the 96-bit unique ID nature of GD32F103 is a bit different. I need to change how unique ID is used (if not, all serial numbers among different boards are same). My plan is another release of Gnuk and NeuG this month, with unique ID change. While testing FST-01SZ prototype, I feel it is convenient not using the acknowledge button for SSH. For me, it seems better to use gpg-agent's "confirmation" pop-up dialog feature for SSH, instead, because I don't need to leave my hand from keyboard for pop-up dialog confirmation (TAB and RET). I'm not sure, if I (for myself) will use the acknowledge button feature for signing and decryption. -- From amos at propellered.com Mon Nov 19 18:32:38 2018 From: amos at propellered.com (Amos Sam) Date: Mon, 19 Nov 2018 18:32:38 +0100 Subject: Exporting private key Message-ID: <4fa9a858-060f-5d8c-1477-b54d98b6d66f@propellered.com> Hello there New user here... I have ST-Link v2 as primary gnuk device, and blue pill for backup. I was wondering is it possible to export private key from gnuk? So, if I loose primary stick, to export private key from backup device and recreate new stick. I hope that my question has sense... gniibe: Will FST-01SZ design be opensource? And if yes, where it will be? I would like to have physically smaller device to carry around, and button for confirming operations is something I got used to (before I was using yubikey) Thanks for any help, Amos Sam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From amos at propellered.com Mon Nov 19 21:06:31 2018 From: amos at propellered.com (Amos Sam) Date: Mon, 19 Nov 2018 21:06:31 +0100 Subject: Exporting private key In-Reply-To: References: <4fa9a858-060f-5d8c-1477-b54d98b6d66f@propellered.com> Message-ID: <8d883d6e-ba50-529c-23b4-e1ce81311884@propellered.com> Thanks for reply! On 11/19/18 8:34 PM, Mike Tsao wrote: > If you generated the key externally (e.g., with GnuPG) and still have > the encrypted private key + passphrase on your host PC, then you can > import it to as many OpenPGP hardware keys, such as gnuk or Yubikey, as > you wish. But if the gnuk device generated the key internally, and you > didn't say yes to the "Make off-card backup of encryption key?" question > when creating it, then by design it cannot be exported. Well, currently it was generated externally, and I have copy of private key (encrypted) on USB drive... > > For signing/authenticating/certifying operations, backing up the private > key isn't essential. You signed a document at a specific moment in time, > and after that moment in time, the only important operation is to verify > the document's signature, which requires only the public key, which > presumably won't ever be lost because it's widely distributed. It is > inconvenient to lose the only copy of the private key because you'll > have to generate and distribute a replacement public key, but there is > no data loss in the sense of no longer being able to do something. This part is not a problem, I agree... > For encryption, though, the answer is different. Backing up the private > key is important. Someone (maybe you) could encrypt data for you using > your public key, and if you've lost the only copy of the private key, > then you won't ever be able to decrypt that data. But, this one and ssh one is a problem. Specially because I use it as only option for logging over ssh... > Thus, if your gnuk is only an authentication token (e.g., the thing you > use to ssh into a server), then some people are of the opinion that it's > better to generate on-device, decline the backup option, and enjoy peace > of mind that it's impossible for the private key to be copied because it > exists in only one place and can't be extracted without physical access > and special knowledge. If you lose that token, update the servers that > recognize it to delete the public key from authorized_keys, and replace > it with a new token/key. (Of course, we're assuming you had some other > way to update the server besides the token you lost.) But if you use > your gnuk for encryption, then most people would agree you should > generate the private key on the host PC, back it up well, and then > import it to the gnuk(s). I'm doing it like that... So, either have backup on mass storage media (or real hard copy) of private key, or use backup key to login to server/decrypt data and generate new key and redo all operations with new one... > > But again, if you generated the key on the gnuk and didn't make a > backup, that's the end of the story. (There are supposed to be ways to > get around this, such > as?https://lists.gnupg.org/pipermail/gnuk-users/2018-June/000051.html.) Yea, i saw that, and it's intriguing, but I was aiming for something that is accessible to mere mortals... :-D > > On Mon, Nov 19, 2018 at 11:10 AM Amos Sam via Gnuk-users > > wrote: > > Hello there > > New user here... > > I have ST-Link v2 as primary gnuk device, and blue pill for backup. > I was wondering is it possible to export private key from gnuk? > So, if I loose primary stick, to export private key from backup > device and recreate new stick. > I hope that my question has sense... > > gniibe: Will FST-01SZ design be opensource? And if yes, > where it will be? I would like to have physically smaller device > to carry around, and button for confirming operations is something > I got used to (before I was using yubikey) > > Thanks for any help, > Amos Sam > > _______________________________________________ > Gnuk-users mailing list > Gnuk-users at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnuk-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From mike at sowbug.com Mon Nov 19 22:02:41 2018 From: mike at sowbug.com (Mike Tsao) Date: Mon, 19 Nov 2018 13:02:41 -0800 Subject: Exporting private key In-Reply-To: <8d883d6e-ba50-529c-23b4-e1ce81311884@propellered.com> References: <4fa9a858-060f-5d8c-1477-b54d98b6d66f@propellered.com> <8d883d6e-ba50-529c-23b4-e1ce81311884@propellered.com> Message-ID: The only purpose of a hardware key like gnuk is to stop mere mortals from copying a usable private key. Otherwise it's no better than an unencrypted private key on an ordinary USB drive. Fortunately, because you have a backup of your private key, you already have all you need to make a backup hardware key. On Mon, Nov 19, 2018 at 12:06 PM Amos Sam wrote: > Thanks for reply! > > On 11/19/18 8:34 PM, Mike Tsao wrote: > > If you generated the key externally (e.g., with GnuPG) and still have > > the encrypted private key + passphrase on your host PC, then you can > > import it to as many OpenPGP hardware keys, such as gnuk or Yubikey, as > > you wish. But if the gnuk device generated the key internally, and you > > didn't say yes to the "Make off-card backup of encryption key?" question > > when creating it, then by design it cannot be exported. > Well, currently it was generated externally, and I have copy of private > key (encrypted) on USB drive... > > > > > For signing/authenticating/certifying operations, backing up the private > > key isn't essential. You signed a document at a specific moment in time, > > and after that moment in time, the only important operation is to verify > > the document's signature, which requires only the public key, which > > presumably won't ever be lost because it's widely distributed. It is > > inconvenient to lose the only copy of the private key because you'll > > have to generate and distribute a replacement public key, but there is > > no data loss in the sense of no longer being able to do something. > This part is not a problem, I agree... > > > For encryption, though, the answer is different. Backing up the private > > key is important. Someone (maybe you) could encrypt data for you using > > your public key, and if you've lost the only copy of the private key, > > then you won't ever be able to decrypt that data. > But, this one and ssh one is a problem. Specially because I use it as > only option for logging over ssh... > > > Thus, if your gnuk is only an authentication token (e.g., the thing you > > use to ssh into a server), then some people are of the opinion that it's > > better to generate on-device, decline the backup option, and enjoy peace > > of mind that it's impossible for the private key to be copied because it > > exists in only one place and can't be extracted without physical access > > and special knowledge. If you lose that token, update the servers that > > recognize it to delete the public key from authorized_keys, and replace > > it with a new token/key. (Of course, we're assuming you had some other > > way to update the server besides the token you lost.) But if you use > > your gnuk for encryption, then most people would agree you should > > generate the private key on the host PC, back it up well, and then > > import it to the gnuk(s). > I'm doing it like that... > > So, either have backup on mass storage media (or real hard copy) of > private key, or use backup key to login to server/decrypt data and > generate new key and redo all operations with new one... > > > > > But again, if you generated the key on the gnuk and didn't make a > > backup, that's the end of the story. (There are supposed to be ways to > > get around this, such > > as https://lists.gnupg.org/pipermail/gnuk-users/2018-June/000051.html.) > Yea, i saw that, and it's intriguing, but I was aiming for something > that is accessible to mere mortals... :-D > > > > > On Mon, Nov 19, 2018 at 11:10 AM Amos Sam via Gnuk-users > > > wrote: > > > > Hello there > > > > New user here... > > > > I have ST-Link v2 as primary gnuk device, and blue pill for backup. > > I was wondering is it possible to export private key from gnuk? > > So, if I loose primary stick, to export private key from backup > > device and recreate new stick. > > I hope that my question has sense... > > > > gniibe: Will FST-01SZ design be opensource? And if yes, > > where it will be? I would like to have physically smaller device > > to carry around, and button for confirming operations is something > > I got used to (before I was using yubikey) > > > > Thanks for any help, > > Amos Sam > > > > _______________________________________________ > > 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 mike at sowbug.com Mon Nov 19 20:34:56 2018 From: mike at sowbug.com (Mike Tsao) Date: Mon, 19 Nov 2018 11:34:56 -0800 Subject: Exporting private key In-Reply-To: <4fa9a858-060f-5d8c-1477-b54d98b6d66f@propellered.com> References: <4fa9a858-060f-5d8c-1477-b54d98b6d66f@propellered.com> Message-ID: If you generated the key externally (e.g., with GnuPG) and still have the encrypted private key + passphrase on your host PC, then you can import it to as many OpenPGP hardware keys, such as gnuk or Yubikey, as you wish. But if the gnuk device generated the key internally, and you didn't say yes to the "Make off-card backup of encryption key?" question when creating it, then by design it cannot be exported. For signing/authenticating/certifying operations, backing up the private key isn't essential. You signed a document at a specific moment in time, and after that moment in time, the only important operation is to verify the document's signature, which requires only the public key, which presumably won't ever be lost because it's widely distributed. It is inconvenient to lose the only copy of the private key because you'll have to generate and distribute a replacement public key, but there is no data loss in the sense of no longer being able to do something. For encryption, though, the answer is different. Backing up the private key is important. Someone (maybe you) could encrypt data for you using your public key, and if you've lost the only copy of the private key, then you won't ever be able to decrypt that data. Thus, if your gnuk is only an authentication token (e.g., the thing you use to ssh into a server), then some people are of the opinion that it's better to generate on-device, decline the backup option, and enjoy peace of mind that it's impossible for the private key to be copied because it exists in only one place and can't be extracted without physical access and special knowledge. If you lose that token, update the servers that recognize it to delete the public key from authorized_keys, and replace it with a new token/key. (Of course, we're assuming you had some other way to update the server besides the token you lost.) But if you use your gnuk for encryption, then most people would agree you should generate the private key on the host PC, back it up well, and then import it to the gnuk(s). But again, if you generated the key on the gnuk and didn't make a backup, that's the end of the story. (There are supposed to be ways to get around this, such as https://lists.gnupg.org/pipermail/gnuk-users/2018-June/000051.html.) On Mon, Nov 19, 2018 at 11:10 AM Amos Sam via Gnuk-users < gnuk-users at gnupg.org> wrote: > Hello there > > New user here... > > I have ST-Link v2 as primary gnuk device, and blue pill for backup. > I was wondering is it possible to export private key from gnuk? > So, if I loose primary stick, to export private key from backup > device and recreate new stick. > I hope that my question has sense... > > gniibe: Will FST-01SZ design be opensource? And if yes, > where it will be? I would like to have physically smaller device > to carry around, and button for confirming operations is something > I got used to (before I was using yubikey) > > Thanks for any help, > Amos Sam > > _______________________________________________ > 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 trick at vanstaveren.us Tue Nov 20 23:16:02 2018 From: trick at vanstaveren.us (Patrick van Staveren) Date: Tue, 20 Nov 2018 22:16:02 +0000 Subject: SWD interface disabled once Gnuk programmed? Message-ID: Hi there, I am new to Gnuk so forgive me if this is a newbie mistake... I have successfully built and programmed Gnuk onto a ST-Link V2 clone (target=ST_DONGLE). I have programmed it with OpenOCD using another ST-Link V2 :) it works. However it now seems that the SWD interface on the Gnuk target board is disabled so I can't connect with OpenOCD to reprogram it. OpenOCD behaves as if I'm not plugged into any device. Is this by design? I assume it might be, to close this off as a vector of attack. Is there a way to open it back up? I don't mind losing the key I've generated on it as this is just experimental so far. Thanks, -- Patrick "Trick" van Staveren http://trick.vanstaveren.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at sowbug.com Wed Nov 21 01:06:29 2018 From: mike at sowbug.com (Mike Tsao) Date: Tue, 20 Nov 2018 16:06:29 -0800 Subject: SWD interface disabled once Gnuk programmed? In-Reply-To: References: Message-ID: If you have gnupg installed, then it might be claiming the USB interface now that the device is an OpenPGP key. Try killing gpg-agent, unplugging, and plugging back in. On Tue, Nov 20, 2018, 3:40 PM Patrick van Staveren wrote: > Hi there, > > I am new to Gnuk so forgive me if this is a newbie mistake... > > I have successfully built and programmed Gnuk onto a ST-Link V2 clone > (target=ST_DONGLE). I have programmed it with OpenOCD using another ST-Link > V2 :) it works. > > However it now seems that the SWD interface on the Gnuk target board is > disabled so I can't connect with OpenOCD to reprogram it. OpenOCD behaves > as if I'm not plugged into any device. > > Is this by design? I assume it might be, to close this off as a vector of > attack. Is there a way to open it back up? I don't mind losing the key I've > generated on it as this is just experimental so far. > > Thanks, > > -- > Patrick "Trick" van Staveren > http://trick.vanstaveren.us/ > _______________________________________________ > 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 gary at mups.co.uk Wed Nov 21 00:56:37 2018 From: gary at mups.co.uk (Gary) Date: Tue, 20 Nov 2018 23:56:37 +0000 Subject: SWD interface disabled once Gnuk programmed? In-Reply-To: References: Message-ID: <033dc71b-23b8-52f9-65d2-1bc6cd71986a@mups.co.uk> On 20/11/2018 22:16, Patrick van Staveren wrote: > Hi there, > > I am new to Gnuk so forgive me if this is a newbie mistake... > > I have successfully built and programmed Gnuk onto a ST-Link V2 clone > (target=ST_DONGLE). I have programmed it with OpenOCD using another ST-Link > V2 :) it works. > > However it now seems that the SWD interface on the Gnuk target board is > disabled so I can't connect with OpenOCD to reprogram it. OpenOCD behaves > as if I'm not plugged into any device. > > Is this by design? I assume it might be, to close this off as a vector of > attack. Is there a way to open it back up? I don't mind losing the key I've > generated on it as this is just experimental so far. Even if the device has been "locked" to prevent any reading back of flash via ST-Link, you should be able to wipe and flash new firmware (losing any keys on the device in the process). I'm not sure if that's the issue you're facing when you say "OpenOCD behaves as if I'm not plugged into any device" but these are the steps I use to upgrade firmware with a locked device and relock it afterwards, make sure you double check the ST-Link is correctly connected to the 4 vias on the GNUK too:- openocd -f interface/stlink-v2.cfg -f target/stm32f1x_stlink.cfg telnet localhost 4444 > reset halt > stm32f1x unlock 0 > reset > reset halt > flash write_image erase /home/user/gnuk/src/build/gnuk.elf > reset > exit Then to relock you can also do: > reset halt > stm32f1x lock 0 > reset > shutdown and verify you can no longer read flash back dump_image mygnuk.img 0 10000 then inspect the img to see if it's blank or valid flash contents for example compare it to a read back prior to locking. If that doesn't work, it may be worth including the output you get from ST-Link for the various commands. Someone should be able to help pinpoint the problem then. Regards, Gary From gniibe at fsij.org Wed Nov 21 06:02:50 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 21 Nov 2018 14:02:50 +0900 Subject: SWD interface disabled once Gnuk programmed? In-Reply-To: References: Message-ID: <874lcbkop1.fsf@fsij.org> Hello, The access can be protected against SWD interface (if you did so by "stm32f1x lock 0" command of OpenOCD). If not, it may be a problem of sleep mode of the MCU. Let me explain in detail. Newer Gnuk (1.2.7 or later) supports USB suspend to minimize power consumption. When suspended (by no USB communication for a while), it enters sleep mode of MCU. When MCU is in sleep mode, I think that ST-Link/V2 doesn't work well. Patrick van Staveren wrote: > Is this by design? I assume it might be, to close this off as a vector of > attack. Is there a way to open it back up? I don't mind losing the key I've > generated on it as this is just experimental so far. I think that you didn't connect and used your board to host PC when you tried to access by OpenOCD. Please connect it to host PC by USB, and do "gpg --card-status" (or something equivalent), so that host PC runs scdaemon to access your board. Then, on your board, Gnuk is keep running, not in sleep mode. In this condition, ST-Link/V2 must be able to access your board. Even if it's protected, "stm32f1x unlock 0" command should work, which unlock the SWD access erasing all flash. Other information: This problem can be solved when hardware and software support RESET signal, to wake up MCU from sleep mode. But FST-01 original and FST-01G don't expose RESET signal to users, unfortunately. Besides, support of RESET signal by OpenOCD (and its drivers) is not in good shape, I suppose. Only some drivers with specific configuration can use RESET signal. I don't know how RESET signal can be used with ST-Link/V2. (BTW, I support RESET signal by my patch of OpenOCD for BBG-SWD.) -- From amos at propellered.com Fri Nov 23 23:19:18 2018 From: amos at propellered.com (Amos Sam) Date: Fri, 23 Nov 2018 23:19:18 +0100 Subject: UIF settings Message-ID: <7aad8ab2-e3bb-ac44-d21c-7c563ca782af@propellered.com> Hello Me again. I modified source to enable ACKBTN on ST-LINK on PA2 pin on raising edge, and soldered switch to 3.3 source, and flashed it. Then I cloned gnupg repo, and build it (didn't installed it). When I run gpg --edit-card from repo, i get UIF setting ......: Sign=off Decrypt=off Auth=off So, firmware is correctly build and installed, and gpg is gpg (GnuPG) 2.3.0-beta535 Then I go to admin mode, and input "uif 1 on", but I get gpg/card> uif 1 on gpg: error for setup UIF: Invalid name Any help? Or, am I jumping in front of train? Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Sun Nov 25 02:25:03 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Sun, 25 Nov 2018 10:25:03 +0900 Subject: UIF settings In-Reply-To: <7aad8ab2-e3bb-ac44-d21c-7c563ca782af@propellered.com> References: <7aad8ab2-e3bb-ac44-d21c-7c563ca782af@propellered.com> Message-ID: <877eh2j6ds.fsf@fsij.org> Amos Sam via Gnuk-users wrote: > I cloned gnupg repo, and build it (didn't installed it). You need to install, if not, scdaemon invoked will be the one of old one. > gpg/card> uif 1 on > gpg: error for setup UIF: Invalid name While gpg is new one, scdaemon is old which doesn't know UIF. Thus, scdaemon returns: GPG_ERR_INV_NAME Invalid name for the UIF object. -- From amos at propellered.com Sun Nov 25 16:35:13 2018 From: amos at propellered.com (Amos Sam) Date: Sun, 25 Nov 2018 16:35:13 +0100 Subject: UIF settings In-Reply-To: <877eh2j6ds.fsf@fsij.org> References: <7aad8ab2-e3bb-ac44-d21c-7c563ca782af@propellered.com> <877eh2j6ds.fsf@fsij.org> Message-ID: You were right... Once I installed gnupgp from git, I was able to activate UIF... but, switch fell off after few tries (my lousy soldering work :-D ) Anyway, that ack btn is what I got used to on yubi, but I'll wait for FST-01SZ to be realeased (and stable gnupg). Thanks for answer, and for this great project! On 11/25/18 2:25 AM, NIIBE Yutaka wrote: > Amos Sam via Gnuk-users wrote: >> I cloned gnupg repo, and build it (didn't installed it). > > You need to install, if not, scdaemon invoked will be the one of old > one. > >> gpg/card> uif 1 on >> gpg: error for setup UIF: Invalid name > > While gpg is new one, scdaemon is old which doesn't know UIF. > Thus, scdaemon returns: > > GPG_ERR_INV_NAME Invalid name > > for the UIF object. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Mon Nov 26 01:31:39 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 26 Nov 2018 09:31:39 +0900 Subject: UIF settings In-Reply-To: <7aad8ab2-e3bb-ac44-d21c-7c563ca782af@propellered.com> References: <7aad8ab2-e3bb-ac44-d21c-7c563ca782af@propellered.com> Message-ID: <874lc4of10.fsf@iwagami.gniibe.org> Amos Sam via Gnuk-users wrote: > soldered switch to 3.3 source I did like this with FST-01G, and it works for me. PA2 <-----+ | o / o _|_ /// GND Could you please test again with this circuit, when you have time? Since I leaned English (by UNIX Manuals) after learning Electric engineering in Japanese, it's better for me to explain in ASCII art. (I mean, I don't have good terminology in Electronics in English.) The switch on-off generates a signal (+3V3 to GND, and then +3V3 again, since it's pulled up internally) and Gnuk detects its rising edge. The detection of rising edge (transition) is important. It should not just to check the level. That's because the purpose of this feature is to require user interaction. Well, still, an attacker can connect square wave generator to PA2 to cheat the device. Or an attacker with mechanical engineering can even arrange a robot to push the button or to move a magnet to mimic the user interaction. I know that. You don't need to file a bug report for that. If enough demands, Flying Stone Technology would develop self-defense robot for FST-01. But, here again, we will have an export control issue. :-) -- From gniibe at fsij.org Mon Nov 26 02:11:42 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 26 Nov 2018 10:11:42 +0900 Subject: NeuG 1.0.9 and Gnuk 1.2.12 Message-ID: <87tvk4mylt.fsf@iwagami.gniibe.org> Hello, I fixed an issue of 96-bit unique bits for GD32F103. I also finally fixed a race condition of ACK button for Gnuk. Thus, these releases. NeuG 1.0.9 is released. tag release/1.0.9 Tagger: NIIBE Yutaka Date: Tue Nov 20 17:16:08 2018 +0900 commit 5d51022a97a5b7358d0ea62bbbc00628c6cec06a Gnuk 1.2.12 is released. tag release/1.2.12 Tagger: NIIBE Yutaka Date: Sun Nov 25 14:37:44 2018 +0900 commit 7249775c171013daca08bc21fd36546fdf74872a I wrote two articles for FST-01SZ: Flying Stone Tiny 01 revision SZ: https://www.gniibe.org/memo/development/fst-01/fst-01-revision-sz.html Flying Stone Tiny 01SZ Test Plan: https://www.gniibe.org/memo/development/fst-01/fst-01sz-testplan.html In the first article, you can see the connector ZL-272 (black USB connector) and the metal enclosure ZL-271. In the second article, you can see an orange test clip. It's 1.27mm pitch test clip with needles. I imported it from China, as well as the connector ZL-272 and the metal enclosure ZL-271. You see, we can find these tools and parts in Chinese market (like Taobao). I encountered several failures for importing them. Firstly, "USB" is difficult, just like CD-ROM or DVD, since it could be considered including anti-China content. For exporting/importing, it's better to explain it's just a part, connector and enclosure, specifically, with no memory, disk or content. Secondly, you need to use better terminology for a tool like test clip. In the translation process from Chinese to English, "needles" or "clip" could be described wrongly. When it sounded like a weapon, they stopped the shipment. In a case of mine, the shop kindly added a small screw driver as an additional gift, and it was described by a term in Chinese with the character which can be interpreted as "knife", then, the entire package was stopped. This week, I'll visit ShenZhen, for SDZIY, Seeed Technology, and OpenTechSummit in China. Now, I'm not sure if Seeed will like to sell FST-01SZ at Seeed Studio or not. I am asking them. Your support will be helpful. I suppose you can write your requests to (Seeed Forum -> Products & Technology -> Others): https://forum.seeedstudio.com/ --