From gnupg.org at terminada.io Thu Oct 3 16:54:18 2024 From: gnupg.org at terminada.io (Terminada) Date: Fri, 4 Oct 2024 00:54:18 +1000 Subject: Certificate Authority using ed25519 key on Gnuk? Message-ID: Is it possible to set up a self signed certificate authority using a ed25519 key protected by a Gnuk (FST-01sz) device? It appears that gpgsm supports creating a self signed CA but maybe only for RSA keys? I have tried running gpgsm --gen-key but I end up receiving this response at the end: > gpgsm: error setting the siginfo: Wrong public key algorithm Is there some way I can get a self signed CA working with a ed25519 key on Gnuk? Do I need to convert the format of the ed25519 private key to that wanted by openssl, prior to sending it to my Gnuk? From gniibe at fsij.org Fri Oct 4 02:20:09 2024 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 04 Oct 2024 09:20:09 +0900 Subject: Certificate Authority using ed25519 key on Gnuk? In-Reply-To: References: Message-ID: <87ttdszpl2.fsf@akagi.fsij.org> Terminada wrote: > Is it possible to set up a self signed certificate authority using a > ed25519 key protected by a Gnuk (FST-01sz) device? I think that you mean X.509 certificate. In theory, it is possible; Gnuk handles private keys and their crypto operations (in this case, it's signing with Ed25519) and it's up to host side to determine the purpose of raw signature produced by Gnuk. > It appears that gpgsm supports creating a self signed CA but maybe only > for RSA keys? I don't know for X.509 CA use cases. Could you please ask gnupg-devel? For X.509 Ed25519 support, it would not be tested well or it's buggy, and the UI is not that good. Although I don't know if it's related, for X.509 EdDSA certificates, I can find this commit: https://dev.gnupg.org/rG6dc3846d78192e393be73c16c72750734a9174d1 -- From wk at gnupg.org Fri Oct 4 09:34:26 2024 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Oct 2024 09:34:26 +0200 Subject: Certificate Authority using ed25519 key on Gnuk? In-Reply-To: <87ttdszpl2.fsf@akagi.fsij.org> (NIIBE Yutaka via Gnuk-users's message of "Fri, 04 Oct 2024 09:20:09 +0900") References: <87ttdszpl2.fsf@akagi.fsij.org> Message-ID: <87ldz4s4n1.fsf@jacob.g10code.de> On Fri, 4 Oct 2024 09:20, NIIBE Yutaka said: > I don't know for X.509 CA use cases. Could you please ask gnupg-devel? The problem with ed25519 X.509 certifciates is that we don't have real sample data or a large CA which uses such certificates. IIRC, I implemented X.509 support for ed25519 or at least for ECDSA keys but it has never been thoroughly tested. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From gnupg.org at terminada.io Fri Oct 4 10:33:11 2024 From: gnupg.org at terminada.io (Terminada) Date: Fri, 4 Oct 2024 18:33:11 +1000 Subject: Certificate Authority using ed25519 key on Gnuk? In-Reply-To: <87ttdszpl2.fsf@akagi.fsij.org> References: <87ttdszpl2.fsf@akagi.fsij.org> Message-ID: <6381b4ed-872f-4861-8cf6-7089672f5ca5@terminada.io> On 4/10/24 10:20, NIIBE Yutaka wrote: > Terminada wrote: > >> It appears that gpgsm supports creating a self signed CA but maybe only >> for RSA keys? > > I don't know for X.509 CA use cases. Could you please ask gnupg-devel? Yes, it seems that the failure relates to unimplemented functionality in gpg-agent / gpgsm, rather than Gnuk. I'll sign up to gnupg-devel and ask. > > For X.509 Ed25519 support, it would not be tested well or it's buggy, > and the UI is not that good. Although I don't know if it's related, for > X.509 EdDSA certificates, I can find this commit: > > https://dev.gnupg.org/rG6dc3846d78192e393be73c16c72750734a9174d1 > That link gave me hope so I installed the lastest development version of gnupg and all dependencies and re-tried using the same parameter file demonstrated in the commit that you linked (but with my keygrip). Unfortunately gpgsm wouldn't work and I got a message saying "Signing failed: Not implemented". It seems strange to me that more people don't want to use ed25519 keys protected by a smartcard as the basis for their self-signed CA. The ed25519 keys have become much more commonly used and they seem better suited for use on devices with limited resources like a smartcard. Do you know if there is a way I can work around the gpgsm inadequacy? Is there some way that I can do part of the self signed CA creation with openssl and then sign using gpg-agent talking to Gnuk? For example, I believe it might be possible to use the ssh key equivalent of the gpg private key in openssl to create the self signed CA. However, I will still need to sign user CSRs after the private key is residing on my Gnuk token, which doesn't seem possible? From gnupg.org at terminada.io Fri Oct 4 10:54:46 2024 From: gnupg.org at terminada.io (Terminada) Date: Fri, 4 Oct 2024 18:54:46 +1000 Subject: Certificate Authority using ed25519 key on Gnuk? In-Reply-To: <87ldz4s4n1.fsf@jacob.g10code.de> References: <87ttdszpl2.fsf@akagi.fsij.org> <87ldz4s4n1.fsf@jacob.g10code.de> Message-ID: On 4/10/24 17:34, Werner Koch wrote: > On Fri, 4 Oct 2024 09:20, NIIBE Yutaka said: > >> I don't know for X.509 CA use cases. Could you please ask gnupg-devel? > > The problem with ed25519 X.509 certifciates is that we don't have real > sample data or a large CA which uses such certificates. IIRC, I > implemented X.509 support for ed25519 or at least for ECDSA keys but it > has never been thoroughly tested. > Maybe I don't need to ask on gnupg-devel since I have the ear of both Werner Koch and NIIBE Yutaka? It certainly looks like the functionality should work based upon what the commit link said: https://dev.gnupg.org/rG6dc3846d78192e393be73c16c72750734a9174d1 But I am not a developer, so I wouldn't know. Here is what I did: I compiled and installed to my local user account GnuPG software devel version 2.5.1 after first compiling and locally installing all the dependency libraries which my Debian Bookworm system doesn't have (libgpg-error-1.50, libgcrypt-1.11.0, libassuan-3.0.0, libksba-1.6.7). Then I reconfigured my Debian /usr/lib/systemd/user/gpg-agent.service to use the newly installed versions in my local user path after configuring appropriate PATH and LD_LIBRARY_PATH variables in user $HOME/.profile. gpg --version > gpg (GnuPG) 2.5.1 > libgcrypt 1.11.0 > ... gpg --card-status sees my Gnuk token correctly exactly as it does under the Debian stable version of gnupg. gpg-agent log: > 2024-10-04 16:58:03 gpg-agent[1066523] gpg-agent (GnuPG) 2.5.1 started > 2024-10-04 16:58:03 gpg-agent[1066523] card has S/N: D276000124010200FFFE3931CF920000 Now trying gpgsm again to create a self signed CA: gpgsm --armor --gen-key gpgsm (GnuPG) 2.5.1; Copyright (C) 2024 g10 Code GmbH This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Please select what kind of key you want: (1) RSA (2) Existing key (3) Existing key from card Your selection? 3 Serial number of the card: D276000124010200FFFE3931CF920000 Available keys: (1) FD125D82F23050A7BB3AE9069BB63C0D29FB0CEC OPENPGP.1 ed25519 (cert,sign) (2) 5EA0EB1BA041CC48A0F1CAD493ED8A41D3C7D6CB OPENPGP.2 cv25519 (encr) (3) E652047FB00D17CB06A0C49BDDBE279521B95984 OPENPGP.3 ed25519 (sign,auth) Your selection? 1 Possible actions for a RSA key: (1) sign, encrypt (2) sign (3) encrypt Your selection? 2 Enter the X.509 subject name: CN=example.org CA, O=example.org, C=US Enter email addresses (end with an empty line): > admin at example.org > Enter DNS names (optional; end with an empty line): > Enter URIs (optional; end with an empty line): > Enter extensions (optional; end with an empty line): > Create self-signed certificate? (y/N) y These parameters are used: Key-Type: card:OPENPGP.1 Key-Length: 1024 Key-Usage: sign Serial: random Name-DN: CN=example.org CA, O=example.org, C=AU Name-Email: admin at example.org Proceed with creation? (y/N) y Now creating self-signed certificate. This may take a while ... gpgsm: about to sign the certificate for key: &FD125D82F23050A7BB3AE9069BB63C0D29FB0CEC gpgsm: signing failed: Not implemented gpgsm: error creating certificate request: Not implemented Just in case, I re-tried with the parameter file used in the linked commit after changing the Key-Grip value to my key. But, unfortunately I received the exact same error. Maybe I am doing something wrong or I have installed some component incorrectly? I am prepared to install Debian sid to a spare machine and then install gnupg from the "experimental" distribution which has gnupg version 2.4.5, if you think that might make a difference? From gnupg.org at terminada.io Fri Oct 4 15:13:27 2024 From: gnupg.org at terminada.io (Terminada) Date: Fri, 4 Oct 2024 23:13:27 +1000 Subject: Certificate Authority using ed25519 key on Gnuk? In-Reply-To: References: <87ttdszpl2.fsf@akagi.fsij.org> <87ldz4s4n1.fsf@jacob.g10code.de> Message-ID: On 4/10/24 18:54, Terminada wrote: > > It certainly looks like the functionality should work based upon what > the commit link said: > https://dev.gnupg.org/rG6dc3846d78192e393be73c16c72750734a9174d1 > > Here is what I did: > > I compiled and installed to my local user account GnuPG software devel > version 2.5.1 after first compiling and locally installing all the > dependency libraries which my Debian Bookworm system doesn't have > (libgpg-error-1.50, libgcrypt-1.11.0, libassuan-3.0.0, libksba-1.6.7). > Then I reconfigured my Debian /usr/lib/systemd/user/gpg-agent.service > to use the newly installed versions in my local user path after > configuring appropriate PATH and LD_LIBRARY_PATH variables in user > $HOME/.profile. > > gpg --version > > gpg (GnuPG) 2.5.1 > ... snip ... > Create self-signed certificate? (y/N) y > These parameters are used: > ??? Key-Type: card:OPENPGP.1 > ??? Key-Length: 1024 > ??? Key-Usage: sign > ??? Serial: random > ??? Name-DN: CN=example.org CA, O=example.org, C=AU > ??? Name-Email: admin at example.org > > Proceed with creation? (y/N) y > Now creating self-signed certificate.? This may take a while ... > gpgsm: about to sign the certificate for key: > &FD125D82F23050A7BB3AE9069BB63C0D29FB0CEC > gpgsm: signing failed: Not implemented > gpgsm: error creating certificate request: Not implemented > > Just in case, I re-tried with the parameter file used in the linked > commit after changing the Key-Grip value to my key.? But, > unfortunately I received the exact same error. > > Maybe I am doing something wrong or I have installed some component > incorrectly? I checked the 2.5.1 source code I compiled on my main machine and the code mentioned in that commit is there. > > I am prepared to install Debian sid to a spare machine and then > install gnupg from the "experimental" distribution which has gnupg > version 2.4.5, if you think that might make a difference? > > I proceeded to install Debian unstable on another machine, and then installed gnupg and scdaemon from experimental (both version 2.4.5), but, I get the same error unfortunately. I don't know what else I can do now to test this any further. Thanks for any assistance. From abhijith at disroot.org Wed Oct 16 08:18:00 2024 From: abhijith at disroot.org (Abhijith PA) Date: Wed, 16 Oct 2024 11:48:00 +0530 Subject: STLink Gnuk is not getting detected Message-ID: Hello, I recently flashed a Stlink v2 clone with latest Gnuk version. There are lot of tutorials available online and I could say my flash went fine. But after flashing, system is not recognizing gnuk usb device. May be 1 in 10 times, it get recognized, but most of the time its not. ``` [832888.723134] usb 1-1: new full-speed USB device number 70 using xhci_hcd [832888.851179] usb 1-1: device descriptor read/64, error -71 [832889.087001] usb 1-1: device descriptor read/64, error -71 [832889.323145] usb 1-1: new full-speed USB device number 71 using xhci_hcd [832889.451001] usb 1-1: device descriptor read/64, error -71 [832889.687192] usb 1-1: device descriptor read/64, error -71 ``` I've tried different USB ports, different machines. Even flashed another stlink and have the same result. --abhijith From gniibe at fsij.org Thu Oct 17 03:28:33 2024 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 17 Oct 2024 10:28:33 +0900 Subject: STLink Gnuk is not getting detected In-Reply-To: References: Message-ID: <87msj3ecvy.fsf@akagi.fsij.org> Hello, Abhijith PA wrote: > But after flashing, system is not recognizing gnuk usb device. May be > 1 in 10 times, it get recognized, but most of the time its not. Firstly, please check the physical hardware for USB DP pull up. There are multiple ST-Link implementations; There would be more for ST-Link clones. Did you configure with --target=ST_DONGLE (it means the ST-Link V2-1 in Nucleo F103)? For ST_DONGLE, we can find three versions of board schematics at st.com in the page of: Schematic Pack (3): https://www.st.com/en/evaluation-tools/nucleo-f103rb.html#cad-resources To enable USB communication, the board requires PA15 (signal name USB_RENUMn) asserted (and --target=ST_DONGLE does that). We also have a support for STM8S_DISCOVERY, which is a version of ST-Link implementation in STM8S Discovery Kit. IIUC, for STM8S_DISCOVERY, we can find a board schematic at st.com, in the page of: User Manuals (2): UM1482: https://www.st.com/en/evaluation-tools/stm8svldiscovery.html#documentation This implementation does not have USB_RENUMn pin support and --target=STM8S_DISCOVERY does nothing. (Note that hardware feature of USB_RENUMn is not needed when we use the board bus-powered.) I thik that this pull-up might be a cause of problem for some boards. I know "Bluepill" does wrong thing: https://electronics.stackexchange.com/questions/598925/usb-pull-up-in-stm32f103-d Secondly.... another problem would be... I wonder if the chip on your board is STM32F103 or one of its variants. If its not STM32F103, sleep support of the chip would have different behavior. (I encounter a symptom of USB enumeration sometime works, but not all the times, for CH32V203 for sleep support of chip.) If it might be the case, please modify the function chx_idle in chopstx-STABLE-2/mcu/chx-stm32f103.c into: ========================== void __attribute__((naked)) chx_idle (void) { for (;;) ; } ========================== That is, no use of sleep support of the chip. Try and see if things improved. -- From abhijith at disroot.org Thu Oct 17 10:10:34 2024 From: abhijith at disroot.org (Abhijith PA) Date: Thu, 17 Oct 2024 13:40:34 +0530 Subject: STLink Gnuk is not getting detected In-Reply-To: <87msj3ecvy.fsf@akagi.fsij.org> References: <87msj3ecvy.fsf@akagi.fsij.org> Message-ID: Hi NIIBE, Thank you for looking in to my issues. On 17/10/24 10:28 AM, NIIBE Yutaka wrote: > Hello, > > Abhijith PA wrote: > > But after flashing, system is not recognizing gnuk usb device. May be > > 1 in 10 times, it get recognized, but most of the time its not. > > Firstly, please check the physical hardware for USB DP pull up. Sorry, I have no experience with inspecting physical hardware and identifying components. My device look exactly like this. https://raw.githubusercontent.com/Zelmoghazy/st-link-v2-clone/refs/heads/main/Images/A611cf33089f74830b00823becb2412c8A.webp Perhaps can you point to any tutorial on how to do it. > There are multiple ST-Link implementations; There would be more for > ST-Link clones. > > > Did you configure with --target=ST_DONGLE (it means the ST-Link V2-1 in > Nucleo F103)? Yes. I configured with --target=ST_DONGLE > Secondly.... another problem would be... I wonder if the chip on your > board is STM32F103 or one of its variants. If its not STM32F103, sleep > support of the chip would have different behavior. (I encounter a > symptom of USB enumeration sometime works, but not all the times, for > CH32V203 for sleep support of chip.) If it might be the case, please > modify the function chx_idle in > > chopstx-STABLE-2/mcu/chx-stm32f103.c > > into: > > ========================== > void __attribute__((naked)) > chx_idle (void) > { > for (;;) > ; > } > ========================== > > That is, no use of sleep support of the chip. Try and see if things > improved. I tried this and unfortunely there isn't any difference. I could say its one of 'STM32F103' by looking at https://github.com/Zelmoghazy/st-link-v2-clone . I have exactly same inscription on MCU as the above image 'MH2103A CBT6' --abhijith From gniibe at fsij.org Fri Oct 18 03:50:00 2024 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 18 Oct 2024 10:50:00 +0900 Subject: STLink Gnuk is not getting detected In-Reply-To: References: <87msj3ecvy.fsf@akagi.fsij.org> Message-ID: <87cyjyyybb.fsf@akagi.fsij.org> Hello, # Note: I have been learning Chinese for years by a radio program in # Japan and I think that I can read some technical documents in Chinese, # but my Chinese skill is quite limited. The MH2103A chip is new to me. I learned that it's a variant (or alias) of AIR32F103. I found this repo for the chip: https://github.com/IOsetting/air32f103-template Also, I found another repo (in Chinese): https://github.com/SoCXin/MH32F103A Abhijith PA wrote: > Sorry, I have no experience with inspecting physical hardware and identifying > components. My device look exactly like this. Thank you for the photo. It seems that it's exactly the case (of USB-DP pull-up); I found an explanation in this wiki (in Chinese): https://wiki.luatos.com/chips/air32f103/enhancement.html USB-DP 1.5k ohm pull-up resistor is supported internally, as an enhancement of the chip, so no extra external care is needed with the chip. It's a great enhancement, but when it's used, software-wise, it's incompatible. (If this new feature is not used, and the board still keeps 1.5k ohm pull-up resistor, then software could be compatible.) So, Gnuk requires a change to support boards with MH32F103A, if the board in qustion takes advantage of the enhancement. In the file: air32f103-template/Libraries/AIR32_USB-FS-Device_Driver/inc/use_regs.h We can find a (new; not in original STM32F103) register, named DP_PUUP. This should be initizlized by one. We can find an example of use case of DP_PUUP: air32f103-template/Examples/NonFreeRTOS/USB/Virtual_COM_Port/main.c Also, I found this document (in Chinese): https://wiki.luatos.com/chips/air32f103/switchFromSxx.html#usb It explains that the interrupt handling in USB driver should be modified for AIR32F103. However, in the file, we can't find any modification: air32f103-template/Libraries/AIR32_USB-FS-Device_Driver/src/usb_int.c So, I guess that it would be a problem for some version(s) of AIR32F103, and it would be OK for other versions. Attached is a highly experimental patch for Chopstx. If it works, we are lucky. -- diff --git a/mcu/usb-st-common.c b/mcu/usb-st-common.c index 58fe4fc..a9c43a1 100644 --- a/mcu/usb-st-common.c +++ b/mcu/usb-st-common.c @@ -37,8 +37,10 @@ struct USB { volatile uint16_t reserved2; volatile uint16_t DADDR; /* Device address register */ volatile uint16_t reserved3; - volatile uint16_t BTABLE; /* Buffer Table address register */ + volatile uint16_t BTABLE; /* Buffer Table address register */ volatile uint16_t reserved4; + volatile uint16_t DP_PULL_UP; /* DP Pull-up register found in some chips */ + volatile uint16_t reserved5; }; static struct USB *const USB = (struct USB *)REG_BASE; @@ -240,6 +242,8 @@ usb_lld_init (struct usb_dev *dev, uint8_t feature) USB->BTABLE = 0; USB->CNTR = (CNTR_CTRM | CNTR_OVRM | CNTR_ERRM | CNTR_WKUPM | CNTR_SUSPM | CNTR_RESETM); + /* Experiment: does it work with MH2103A? */ + USB->DP_PULL_UP = 1; } void From abhijith at disroot.org Mon Oct 21 08:28:16 2024 From: abhijith at disroot.org (Abhijith PA) Date: Mon, 21 Oct 2024 11:58:16 +0530 Subject: STLink Gnuk is not getting detected In-Reply-To: <87cyjyyybb.fsf@akagi.fsij.org> References: <87msj3ecvy.fsf@akagi.fsij.org> <87cyjyyybb.fsf@akagi.fsij.org> Message-ID: Hi NIIBE, On 18/10/24 10:50 AM, NIIBE Yutaka wrote: > Hello, ... > Attached is a highly experimental patch for Chopstx. If it works, we > are lucky. > > -- > > diff --git a/mcu/usb-st-common.c b/mcu/usb-st-common.c > index 58fe4fc..a9c43a1 100644 > --- a/mcu/usb-st-common.c > +++ b/mcu/usb-st-common.c > @@ -37,8 +37,10 @@ struct USB { > volatile uint16_t reserved2; > volatile uint16_t DADDR; /* Device address register */ > volatile uint16_t reserved3; > - volatile uint16_t BTABLE; /* Buffer Table address register */ > + volatile uint16_t BTABLE; /* Buffer Table address register */ > volatile uint16_t reserved4; > + volatile uint16_t DP_PULL_UP; /* DP Pull-up register found in some chips */ > + volatile uint16_t reserved5; > }; > > static struct USB *const USB = (struct USB *)REG_BASE; > @@ -240,6 +242,8 @@ usb_lld_init (struct usb_dev *dev, uint8_t feature) > USB->BTABLE = 0; > USB->CNTR = (CNTR_CTRM | CNTR_OVRM | CNTR_ERRM > | CNTR_WKUPM | CNTR_SUSPM | CNTR_RESETM); > + /* Experiment: does it work with MH2103A? */ > + USB->DP_PULL_UP = 1; > } > > void Unfortunely this also didn't work :( . Also confirmed by friend Anoop (Cc'ed) Recently I found this project https://github.com/gl-sergei/u2f-token and flashed that to my device (Anoop also did this). 10/10 times system detected the USB device. Do you think we can take something from there to fix gnuk on my device. (they are using Chopstx) --abhijith From gniibe at fsij.org Mon Oct 21 09:30:15 2024 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 21 Oct 2024 16:30:15 +0900 Subject: STLink Gnuk is not getting detected In-Reply-To: References: <87msj3ecvy.fsf@akagi.fsij.org> <87cyjyyybb.fsf@akagi.fsij.org> Message-ID: <8734kphq0o.fsf@akagi.fsij.org> Hello, Abhijith PA wrote: > Unfortunely this also didn't work :( . Also confirmed by friend Anoop > (Cc'ed) Thank you for your testing. > Recently I found this project https://github.com/gl-sergei/u2f-token > and flashed that to my device (Anoop also did this). 10/10 times > system detected the USB device. Do you think we can take something > from there to fix gnuk on my device. (they are using Chopstx) I didn't know the project. It's interesting. It looks like they are using Chopstx 1.4 (which does not have USB suspend support). So, let me check the code around USB suspend (the second problem in my initial message). Possibly, modifying the chx_sleep_mode function (to do nothing) would be also needed as well as modification of chx_idle. --