From gnupg.org at terminada.io Wed Oct 11 09:24:19 2023 From: gnupg.org at terminada.io (Terminada) Date: Wed, 11 Oct 2023 17:24:19 +1000 Subject: Suitability of STM32L432KC? Message-ID: <3691da8c-2e29-47bd-a5ca-95c43280387e@terminada.io> Hi NIIBE Yutaka, I am wondering about the suitability of STM32L432KC chip if I was to build a FST-01SZ equivalent. The datasheet https://www.st.com/resource/en/datasheet/stm32l432kc.pdf Says: "Core: Arm? 32-bit Cortex?-M4 CPU with FPU,Adaptive real-time accelerator (ART Accelerator?) allowing 0-wait-state execution from Flash memory, frequency up to 80 MHz, MPU, 100DMIPS and DSP instructions" "The STM32L432xx devices embed several protection mechanisms for embedded Flash memory and SRAM: readout protection, write protection, proprietary code readout protection and Firewall." Would this be a better ARM processor to use than the one used in FST-01SZ? Or would you recommend something else? I have a FST-01SZ currently, which I use daily, but I need more. Thanks for all your work. From gniibe at fsij.org Thu Oct 12 02:41:02 2023 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 12 Oct 2023 09:41:02 +0900 Subject: Suitability of STM32L432KC? In-Reply-To: <3691da8c-2e29-47bd-a5ca-95c43280387e@terminada.io> References: <3691da8c-2e29-47bd-a5ca-95c43280387e@terminada.io> Message-ID: <87il7czn8h.fsf@akagi.fsij.org> Hello, In the development history of mine, I tried: STM32L432 GD32VF103 But I don't use them for Gnuk. Let me explain. Terminada wrote: > I am wondering about the suitability of STM32L432KC chip if I was to > build a FST-01SZ equivalent. Chopstx has support of STM32L432 for its core, USART driver and USB driver. I use STM32L432 for my card reader implementation (named TTXS), using Chopstx. In this situation, if we will implement RNG driver for STM32L432 or port the ADC driver (for NeuG), it is possible to *run* Gnuk on the MCU. I didn't do that, however, because I'm not confident enough if it can run securely. The code of Gnuk assumes the MCU is *not* that good, that is, - without (better) branch predictor - without cache (or flash accelerator) In other words, our unique/peculiar approach is: assuming use of not-that-good MCU, we can keep the code simpler. Please note that, in the code of Gnuk: - The execution path may depend on secret values. - It may have table access which depends on secret values. This is "feature", not bug. > "Core: Arm? 32-bit Cortex?-M4 CPU with FPU,Adaptive real-time > accelerator (ART Accelerator?) allowing 0-wait-state execution > from Flash memory, frequency up to 80 MHz, MPU, 100DMIPS and DSP > instructions" My concern is possible side-channel attacks against this accelerator. IIUC, GD32F103 (on FST-01SZ) has SRAM and SPI Flash ROM, and the contents of Flash are copied into SRAM at boot. Table access with secret values is considered secure on the MCU (against possible side-channel attacks). -- From gnupg.org at terminada.io Thu Oct 12 06:14:21 2023 From: gnupg.org at terminada.io (Terminada) Date: Thu, 12 Oct 2023 14:14:21 +1000 Subject: Suitability of STM32L432KC? In-Reply-To: <87il7czn8h.fsf@akagi.fsij.org> References: <3691da8c-2e29-47bd-a5ca-95c43280387e@terminada.io> <87il7czn8h.fsf@akagi.fsij.org> Message-ID: On 12/10/23 10:41, NIIBE Yutaka wrote:> > The code of Gnuk assumes the MCU is *not* that good, that is, > > - without (better) branch predictor > - without cache (or flash accelerator) > > In other words, our unique/peculiar approach is: assuming use of > not-that-good MCU, we can keep the code simpler. > > Please note that, in the code of Gnuk: > > - The execution path may depend on secret values. > - It may have table access which depends on secret values. > > This is "feature", not bug. > >> "Core: Arm? 32-bit Cortex?-M4 CPU with FPU,Adaptive real-time >> accelerator (ART Accelerator?) allowing 0-wait-state execution >> from Flash memory, frequency up to 80 MHz, MPU, 100DMIPS and DSP >> instructions" > > My concern is possible side-channel attacks against this accelerator. > > > IIUC, GD32F103 (on FST-01SZ) has SRAM and SPI Flash ROM, and the > contents of Flash are copied into SRAM at boot. Table access with > secret values is considered secure on the MCU (against possible > side-channel attacks). Very interesting. I think I understand what you are saying at a high level. But, please explain a bit more. I am not sure how to word my questions given my more limited understanding: How does the password used to unlock the smartcard (Gnuk) result in the secret values being more secure for memory access? Does STM32L432's ART Accelerator undermine this because the compiler will optimise the binary for the ART Accelerator? Does this mean that the processor used in FST-01SZ is less susceptible to side channel attacks compared to a Trezor One device (STM32F10XRXT6) or even the more recent Trezor T device (STM32F427VIT6)? See this link about breaking Trezor One: https://www.ledger.com/blog/breaking-trezor-one-with-sca > > In the development history of mine, I tried: > > STM32L432 > GD32VF103 > > But I don't use them for Gnuk. Let me explain. > What do you use now? I am happy with my FST-01SZ boards subject to not knowing how secure they are against various attacks. However, I was unable to re-program my FST-01 and FST-01G boards until I realised that I needed to trigger a reset by shorting pins NRST and VSSA on the processor whilst trying to keep the ST-Link V2 programmer connected. That was a bit tricky but I eventually re-programmed them all to Gnuk version 2.1. I am motivated to make some Gunk tokens because it is impossible to purchase any FST-01SZ or similar from anywhere. The board design looks reasonably simple and I should be able to solder the IC by hand, but if I am going to go to the trouble of doing this, I thought I might get the most appropriate processor for the task. So what would you recommend now? I am particularly concerned to get the most secure, least easily attacked, processor chip. I don't care if it will cost a few dollars more. Another thing I would be very interested in achieving is to be able to use my Gnuk token to sign Cardano blockchain transactions. The keys used on Cardano are ed25519 keys and the hashing algorithm used is Blake2b. There would be significant Cardano community support for getting this to work and there is funding available to pay for development expenses through project Catalyst. (https://projectcatalyst.io/) This video from one developer illustrates that the missing features, from what is already implemented in Gnuk, are likely quite minimal. (Maybe only the Blake2b hashing algorithm?): https://youtu.be/rVdpUpavLgM -- From gnupg.org at terminada.io Fri Oct 13 16:20:34 2023 From: gnupg.org at terminada.io (Terminada) Date: Sat, 14 Oct 2023 00:20:34 +1000 Subject: Second passphrase feature request Message-ID: I am interested by some extra functionality that the Trezor devices provide. These devices store a key on them and require a passphrase for unlocking similar to Gnuk. But they also allow you to enter _any_ additional passphrase to generate new keys by combining the second passphrase entered with the existing stored key. This second passphrase does not get stored on the device and simply gets entered each time. If you enter a different second passphrase then you will produce a different key. Bitcoin, Cardano, and other blockchains generate their keys from a 12 or 24 word seed phrase. This second passphrase is like an additional seed word that gets combined with the existing seed words to produce a new key. This second passphrase makes the physical device, in a way, un-hackable because it is not even stored, anywhere. And entering anything will still produce a valid key. However the process is deterministic in that entering the same second passphrase will always generate the same key. The other benefit of this second passphrase is that in effect you can generate an unlimited number of keys from the base key. Also, entering the empty passphrase produces the base key. Would there be a way to add such a feature to Gnuk and gnupg? Is there some way to generate a new gpg key from an existing one if given some additional data (second passphrase)? -- From gnupg.org at terminada.io Fri Oct 27 00:26:54 2023 From: gnupg.org at terminada.io (gnupg.org at terminada.io) Date: Fri, 27 Oct 2023 08:26:54 +1000 Subject: Second passphrase feature request In-Reply-To: References: Message-ID: This video outlines how it is easy to extract the key from Trezor T devices which use a similar chip to FST-01SZ: https://youtu.be/50eiA-75NMY But, using a second passphrase to generate the required key each time would protect against such attacks because this second passphrase would not be stored anywhere. From gniibe at fsij.org Fri Oct 27 02:22:35 2023 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 27 Oct 2023 09:22:35 +0900 Subject: Second passphrase feature request In-Reply-To: References: Message-ID: <87bkckx6b8.fsf@akagi.fsij.org> Hello, I answer in different order of you asked. It sounds like you have a specific use case in mind, and I'm not sure if use of Gnuk Token is appropriate for that. Terminada wrote: > Is there some way to generate a new gpg key from an existing one if > given some additional data (second passphrase)? Technically, it is possible to use data of a private key to derive another. I don't think there is an existing tool for OpenPGP to help this use case. > Would there be a way to add such a feature to Gnuk and gnupg? It would be. For Gnuk, it sounds like you are suggesting (or expecting) another design of token, like FIDO2, which has a secret in a device to derive (possibly many) keys. (Sorry, I don't know about how Trezor devices are implemented.) It would be good to add a feature to GnuPG, which supports generating OpenPGP key from externally generated raw private key material (by some derivation mechanism using secret like existing private key (in OpenPGP format or whatever)). Currently, GnuPG has a limited support to generate OpenPGP key from existing card key. This feature could be generalized/enhanced. > I am interested by some extra functionality that the Trezor devices > provide. In Gnuk, passphrase is not stored in the device, at all. Passphrase is used to decrypt your key on the device. -- From gnupg.org at terminada.io Fri Oct 27 04:29:32 2023 From: gnupg.org at terminada.io (gnupg.org at terminada.io) Date: Fri, 27 Oct 2023 12:29:32 +1000 Subject: Second passphrase feature request In-Reply-To: <87bkckx6b8.fsf@akagi.fsij.org> References: <87bkckx6b8.fsf@akagi.fsij.org> Message-ID: On 27/10/23 10:22, NIIBE Yutaka wrote> > It sounds like you have a specific use case in mind, and I'm not sure if > use of Gnuk Token is appropriate for that. Well, it would be good to include implementation of the Blake2b hashing algorithm because then a simple device like FST-01SZ could also be used for signing blockchain transactions on Cardano, which uses ed25519 keys. > > Technically, it is possible to use data of a private key to derive > another. I don't think there is an existing tool for OpenPGP to help > this use case. Yes, that would be a good feature because it would achieve three advantages: 1. It would remove the limitation of 3 key storage. Since different second passphrase would generate different keys, effectively a single device can manage an infinite number of keys (limited only by unique second passphrases). 2. It would make the secret key storage more secure, or even un-crackable depending on strength of the second passphrase since the device would then really only be storing a partial key or seed. 3. It would enable plausible deniability. Since every possible second passphrase would generate a valid key. If subjected to a "wrench attack" the user can reveal a valid key but this may not be his most valuable key. Eg: A User can prepare a throw away key in advance for disclosure in the event of a "wrench attack" and say that this is "the" key he uses with this smartcard. The attacker has no way of knowing if that assertion is correct or not because he would see a working key. The user can plausibly deny that he has any other key available from this particular smartcard. By contrast, the way GnuPG used with FST-01SZ works today, an attacker will know immediately if the correct PIN is entered because the software will tell him. > >> Would there be a way to add such a feature to Gnuk and gnupg? > > It would be. For Gnuk, it sounds like you are suggesting (or expecting) > another design of token, like FIDO2, which has a secret in a device to > derive (possibly many) keys. (Sorry, I don't know about how Trezor > devices are implemented.) I don't think FST-01SZ hardware needs to be changed. Though maybe there are ways to simply add a secure element IC to the FST-01SZ design to improve the security of the partial key storage. I don't know how feasible this would be or even if it would be worth doing. > > It would be good to add a feature to GnuPG, which supports generating > OpenPGP key from externally generated raw private key material (by some > derivation mechanism using secret like existing private key (in OpenPGP > format or whatever)). > > Currently, GnuPG has a limited support to generate OpenPGP key from > existing card key. This feature could be generalized/enhanced. > Excellent. Would you consider adding this feature? Note that adding this second passphrase feature can have zero impact on current usage patterns for users that didn't want to use it. This is because using an empty passphrase would simply use the key stored, unchanged. You could simply add a menu option to enable this second passphrase feature so the user is prompted to enter a second passphrase. If the feature is not enabled, then the empty second passphrase is always used without any prompting, which would provide the exact same usage pattern as current. This is exactly how the Trezor devices work with their second passphrase feature. > > In Gnuk, passphrase is not stored in the device, at all. Passphrase is > used to decrypt your key on the device. OK, I think that is better than what the Trezor devices are doing for key storage. However, as Gnuk is currently implemented, if the key was copied from the device still in it's encrypted state, is it possible to know when the data is successfully decrypted by applying AES decryption with guessed PINs? IE: Can you know when successfully decrypted because you see a specific header byte sequence? From gniibe at fsij.org Fri Oct 27 08:03:38 2023 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 27 Oct 2023 15:03:38 +0900 Subject: Second passphrase feature request In-Reply-To: References: <87bkckx6b8.fsf@akagi.fsij.org> Message-ID: <877cn8wqit.fsf@akagi.fsij.org> Hello, I will read your suggestion later. For now, let me reply to a question. gnupg.org at terminada.io wrote: > However, as Gnuk is currently implemented, if the key was copied from > the device still in it's encrypted state, is it possible to know when > the data is successfully decrypted by applying AES decryption with > guessed PINs? IE: Can you know when successfully decrypted because you > see a specific header byte sequence? Let me explain. Terms: KDF: Key Derivation Function KEK: Key Encoding Key DEK: Data Encoding Key AEAD: Authenticated Encryption Here is a figure: Passphrase --[KDF on your computer + on the device]--> KEK KEK --> [AES decryption] --> DEK ^ Encrypted | key -----/ DEK --> [AEAD decryption] --> private key material ^ Encrypted | private key --/ with authentication tag (stored in the flash memory of the device) With AEAD, it determines that the decrypted data has correct or not. In the situation where the all data is extracted from MCU (somehow), brute force attack with guessed DEK (or KEK) is possible, and brute force attack with guessed passphrase is possible, too. With Gnuk, computation of KEK is done togerther with the host computer and the device (when configured correctly). KDF on the device side uses (32-bit from 96-bit) unique ID of MCU. When the host computer is cracked, passphrase might be known. In this case, private key material may be aquired using the passphrase, and the information (or guessing) of unique ID. When the USB communication is tapped and monitored, partially computed KEK might be known. In this case, private key material may be aquired by a bit of brute force attack with partially computed KEK, and the information (or guessing) of unique ID. -- From simon at josefsson.org Fri Oct 27 09:17:21 2023 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 27 Oct 2023 09:17:21 +0200 Subject: Second passphrase feature request In-Reply-To: (gnupg org's message of "Fri, 27 Oct 2023 12:29:32 +1000") References: <87bkckx6b8.fsf@akagi.fsij.org> Message-ID: <87v8as1qm6.fsf@kaka.sjd.se> gnupg.org at terminada.io writes: > 1. It would remove the limitation of 3 key storage. Since different > second passphrase would generate different keys, effectively a single > device can manage an infinite number of keys (limited only by unique > second passphrases). This is like the FIDO-approach: no storage requirement on the device except for possibly crypto-related incremental counters. It is quite orthogonal to the current GNUK design, but I think GNUK could be extended to support it: replace reading the encrypted key material with reading a blob from the machine together with a second passphrase and use some it together with a device-specific key to decrypt it before use. Reading the blob from the machine isn't critical: if storage is available, it can use blob from GNUK storage instead. The Tillitis Key -- https://tillitis.se/ -- follow this approach, and has Ed25519 signing for SSH working. It could be extended to support OpenPGP too under the FIDO-model. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 255 bytes Desc: not available URL: