Sammanfattning av öppet möte 32 om att bygga egen e-leg-lösning, 23 juni
2025:
Tack till alla som var med på mötet!
- CA-programvara för utgivaren och test med nginx, status? Procedur för
att förnya utgivarens cert?
Elias har inte hunnit komma till det än. Bra att få till att utgivaren
kan använda hårdvarunyckel.
Christian har tänkt sätta upp en webbsida där man kan sätta upp
e-legitimation på fil, är på gång men har inte hunnit riktigt ännu.
Har även provat EJBCA som är en open-source web-tjänst.
https://www.ejbca.org/use-cases/issue-tls-and-mtls-certificates/
Har testkört deras docker-image med framgång men inte fått igång en
utvecklingsmiljö för att lägga till nyckelpargenerering i browsern.
- OpenPGP-kort, testat mer. pkcs11, olika kort har olika uppsättning av
"mechanisms" som stöds
Verkar gå bra att skapa nyckel på kortet, skapa csr, och generera cert.
Återstår att få användningen av cert att fungera, alltså kommunikationen
med förlitande part. Testar med curl.
Olika versioner av OpenPGP-kort, så kanske en nyare version kan funka.
Ska undersökas mer, för att se vad som funkar och inte, och varför.
- Sätta upp server med revokeringslista, ordna domän och webbserver för det?
Den som agerar utfärdare behöver något sätt att kunna lägga upp en
uppdaterad revokeringslista. Utfärdare ska kunna lägga upp, så att
förlitande part sen kan hämta listan. ljo fortsätter kolla på det
utifrån önskemålen möte 31 efter den här veckan när det börjat lugna ner
sej på arbetet.
- Skriva debattartikel om robusthet apropå BankID-problemen nyligen?
Ingen har hunnit. Fortfarande en bra idé att skriva något!
Vi siktar på en "skrivarstuga" snart för att få ihop något. Någon gång
från den 7e juli kan funka tror vi. Alla som vill hjälpa till med att
skriva får gärna höra av sig via projektets mejllista.
- "Invitation: Participatory Requirements Workshop for eIDAS Oversight
Platform", se projektets mejllista.
Vem/vilka kan vara med vid tillfället 2/7? Ch är med.
- "Remiss av Uppgiftsskyldighet för vissa e-legitimationsföretag"
Senaste dag att svara är den 8 juli.
Några instanser har redan svarat, ca 7 stycken.
https://www.regeringen.se/remisser/2025/04/remiss-av-uppgiftsskyldighet-for…
Viktiga är att vi får fram våra synpunkter. Vi borde därför skriva nåt
också, även om vi håller det ganska kort.
Ch är gärna med och skriver ett utkast.
- Paneldiskussion om certifikat
Ch berättar: jag var där, i stan, det var fyra föredragshållare och sen
ett litet mingel.
När vi gick runt bordet, ca 20-25 personer och jag sa att jag var från
DFRI så blev folk intresserade och kom och frågade saker sen under minglet.
Många verkar tycka att det är jobbigt att förnya certifikat och det
fanns produkter för att göra det automatiskt.
Acme-protokollet som Let's Encrypt m fl använder, går att använda för
att förnya certifikat.
Det diskuterades en del om smartcards. Om man har ett smartcard som
stöder pkcs11 är det skillnad mot ett kort som stöder PIV.
Det var en som förklarade att de har levererat något för bilar som
ringer hem och ska identifiera sig, där det behövde uppdateras inom
några dagar, där det kanske var risk att bilen blir "brickad" om bilen
är undanställd några dagar.
Korttids-certifikat: För webb-certifikat går de ner från ca 300 dagar
till 47 dagar (helt arbiträrt valt) och sen vidare ner till 7 dagar. För
att de vill komma bort från revokerings-systemet för att det inte funkar
bra.
Det finns protokoll för att revokera (återkalla) certifikat.
Lösningen vi gör kanske ska stödja att man som e-leg-innehavara kan
skicka med senaste revokerings-listan för att det ska kunna fungera även
om förlitande part inte har en tillräckligt färsk lista.
Läsnyttigt om att ha med egen revokeringslista:
https://blog.cloudflare.com/high-reliability-ocsp-stapling/#ocspstapling
- En till punkt: Ch ska vara med i ett hackaton den 1 juli, där det ska
tas fram en e-legitimation som tema för hackatonet, med tema "resilience"!
Kan ha många kopior av revokeringslistan, med hjälp av en databaslösning
som stöder replikering.
https://cillers.com/hackathons/couchbase-disaster-resilience-hackathon
- När blir nästa möte?
Nästa möte hålls måndag 2025-07-14 klockan 18 till 19 (en timme)
Alla är välkomna att vara med på kommande möten. OBS även du som inte
varit med förut är mycket välkommen att vara med!
/ Elias
PS
Läs gärna om projektet här: https://www.dfri.se/projekt/e-legitimation/
PS 2
Alla som är intresserade är välkomna att höra av sig via projektets
mejllista
Hej!
Försöker få vår proof-of-concept att fungera med OpenPGP-kort (sedan
tidigare funkar det med YubiKey och NitroKey HSM, men inte ännu med
OpenPGP-kort).
Några länkar om bakgrunden finns längst ner i mejlet.
Allt som används nedan är fri programvara, de olika kommandona finns som
Debian-paket till exempel.
Det jag vill kunna göra är följande tre saker:
(1) Skapa nyckelpar på smartkortet
(2) Skapa en motsvarande CSR-fil (som sen kan ges till utfärdaren som då
kan skapa ett motsvarande personligt certifikat)
(3) Använda det personliga certifikatet för att identifiera sig mot en
test-webbsida
Försöker få det att fungera med ett OpenPGP-kort av den här typen:
https://www.cryptoshop.com/products/smartcards/proprietary-solution-cards/o…
Kommandon som kan användas för att visa info om smartkort (oavsett om
det är ett OpenPGP-kort eller en YubiKey eller NitroKey eller liknande):
gpg --card-status
pkcs11-tool --list-slots
p11tool --list-tokens
Kommandot "p11tool --list-tokens" visar bland annat en "URL" för varje
token, som kan användas som input till vissa andra kommandon för att
säga vilken token man vill använda.
Man kan även köra det här för att visa bara just token url och inget annat:
p11tool --list-token-urls
Om man har ett cert (skapat med vår utfärdar-programvara) kan man
använda det för att identifiera sig mot test-sidan
https://eid-test-2.eliasrudberg.se/ med curl såhär:
curl --cert eid_200001012384.crt.pem --key $url
https://eid-test-2.eliasrudberg.se/
Enter PKCS#11 token PIN for SmartCard-HSM (UserPIN):
Hej 200001012384! Välkommen till Test-sajten :-)
(Alltså ovanstående "Välkommen till Test-sajten" är hur det ser ut om
det fungerar, just nu kan jag få det att fungera med Nitrokey HSM men
inte med OpenPGP-kortet, mer om det här nedanför)
Följande kan hjälpa för att undvika konflikter när olika programvaror
försöker dra i smartkortet samtidigt:
echo disable-ccid >> ~/.gnupg/scdaemon.conf
Se
https://support.yubico.com/hc/en-us/articles/4819584884124-Resolving-GPG-s-…
Ett sätt att skapa nyckelpar på kortet är det här:
gpgsm --generate-key > my-openpgp-card.csr
(men kanske inte bästa sättet)
Ett annat sätt är det här:
pkcs11-tool --module /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so --login
--login-type so --keypairgen --key-type rsa:2048 --id 3 --so-pin 12345678
Valet av "id" spelar roll, alltså "--id 3" ovan. Det går att köra med id
1 eller 2 också, men då blir det problem senare så jag tror att 3 är bäst.
Outputen från kommandot ovan ser ut såhär:
Using slot 0 with a present token (0x0)
Key pair generated:
Private Key Object; RSA
label: Private Key
ID: 03
Usage: decrypt, sign
Access: none
Public Key Object; RSA 16384 bits
label: Private Key
ID: 03
Usage: encrypt, verify
Access: none
Om man kör "gpg --card-status" i det läget kan man se att en
"Authentication key" har skapats på OpenPGP-kortet.
Sen kan man skapa CSR såhär:
openssl req -new -engine pkcs11 -subj "/C=GB/CN=foo" -key id_3 -keyform
engine -out openpgpcard_id3.csr.pem
Den CSR-filen kan ges till utfärdaren, praktiskt nog i detta test är
utfärdaren jag själv :-)
(Den som vill testa kan själv vara utfärdare om man vill, koden finns
här https://codeberg.org/DFRI-eID/dfri-eid)
Utfärdaren skapar cert och sen kan man försöka använda sitt cert.
curl --cert eid_200001012394.crt.pem --key $url
https://eid-test-2.eliasrudberg.se/
(där $url ovan är en url man fått fram med t.ex. "p11tool
--list-token-urls")
Då blir det dock problem:
curl --cert eid_200001012394.crt.pem --key $url
https://eid-test-2.eliasrudberg.se/
Enter PKCS#11 token PIN for OpenPGP card (User PIN):
curl: (35) error:8207A070:PKCS#11
module:pkcs11_private_encrypt:Mechanism invalid
Felmeddelandet säger "Mechanism invalid" alltså.
Genom att lägga till OPENSC_DEBUG=9 kan man få en massa debug-loggning:
OPENSC_DEBUG=9 PKCS11SPY=/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so curl
-vvvv --cert eid_200001012394.crt.pem --key $url
https://eid-test-2.eliasrudberg.se/
Då ser man bland annat följande som verkar intressant:
P:16041; T:0x140368933964096 19:47:35.351 [opensc-pkcs11]
framework-pkcs15.c:3689:pkcs15_prkey_get_attribute:
pkcs15_prkey_get_attribute() called
P:16041; T:0x140368933964096 19:47:35.351 [opensc-pkcs11]
framework-pkcs15.c:3689:pkcs15_prkey_get_attribute:
pkcs15_prkey_get_attribute() called
P:16041; T:0x140368933964096 19:47:35.351 [opensc-pkcs11]
mechanism.c:251:sc_pkcs11_sign_init: called
P:16041; T:0x140368933964096 19:47:35.352 [opensc-pkcs11]
mechanism.c:256:sc_pkcs11_sign_init: mechanism 0xD, key-type 0x0
P:16041; T:0x140368933964096 19:47:35.352 [opensc-pkcs11]
mechanism.c:260:sc_pkcs11_sign_init: returning with: 112
P:16041; T:0x140368933964096 19:47:35.352 [opensc-pkcs11]
pkcs11-object.c:679:C_SignInit: C_SignInit() = CKR_MECHANISM_INVALID
P:16041; T:0x140368933964096 19:47:35.352 [opensc-pkcs11]
framework-pkcs15.c:3689:pkcs15_prkey_get_attribute:
pkcs15_prkey_get_attribute() called
P:16041; T:0x140368933964096 19:47:35.352 [opensc-pkcs11]
framework-pkcs15.c:3689:pkcs15_prkey_get_attribute:
pkcs15_prkey_get_attribute() called
P:16041; T:0x140368933964096 19:47:35.352 [opensc-pkcs11]
mechanism.c:251:sc_pkcs11_sign_init: called
P:16041; T:0x140368933964096 19:47:35.352 [opensc-pkcs11]
mechanism.c:256:sc_pkcs11_sign_init: mechanism 0x3, key-type 0x0
P:16041; T:0x140368933964096 19:47:35.353 [opensc-pkcs11]
mechanism.c:260:sc_pkcs11_sign_init: returning with: 112
P:16041; T:0x140368933964096 19:47:35.353 [opensc-pkcs11]
pkcs11-object.c:679:C_SignInit: C_SignInit() = CKR_MECHANISM_INVALID
Alltså, den försöker använda "mechanism 0xD" och sen "mechanism 0x3" och
sen ger den upp.
Det går att lista vilka mechanisms som ett smartkort har stöd för såhär:
p11tool --list-mechanisms $url
[0x0220] CKM_SHA_1 digest
[0x0255] CKM_SHA224 digest
[0x0250] CKM_SHA256 digest
[0x0260] CKM_SHA384 digest
[0x0270] CKM_SHA512 digest
[0x0210] CKM_MD5 digest
[0x0240] CKM_RIPEMD160 digest
[0x1210] CKM_GOSTR3411 digest
[0x0001] CKM_RSA_PKCS keysize range (2048, 2048) hw decrypt sign verify
[0x0006] CKM_SHA1_RSA_PKCS keysize range (2048, 2048) sign verify
[0x0046] CKM_SHA224_RSA_PKCS keysize range (2048, 2048) sign verify
[0x0040] CKM_SHA256_RSA_PKCS keysize range (2048, 2048) sign verify
[0x0041] CKM_SHA384_RSA_PKCS keysize range (2048, 2048) sign verify
[0x0042] CKM_SHA512_RSA_PKCS keysize range (2048, 2048) sign verify
[0x0005] CKM_MD5_RSA_PKCS keysize range (2048, 2048) sign verify
[0x0008] CKM_RIPEMD160_RSA_PKCS keysize range (2048, 2048) sign verify
[0x0000] CKM_RSA_PKCS_KEY_PAIR_GEN keysize range (2048, 2048)
generate_key_pair
Kollar samma sak "p11tool --list-mechanisms" for Nitrokey HSM:
p11tool --list-mechanisms $url2
[0x0220] CKM_SHA_1 digest
[0x0255] CKM_SHA224 digest
[0x0250] CKM_SHA256 digest
[0x0260] CKM_SHA384 digest
[0x0270] CKM_SHA512 digest
[0x0210] CKM_MD5 digest
[0x0240] CKM_RIPEMD160 digest
[0x1210] CKM_GOSTR3411 digest
[0x1041] CKM_ECDSA keysize range (192, 521) hw sign ec_f_p ec_namedcurve
ec_uncompress
[0x1042] CKM_ECDSA_SHA1 keysize range (192, 521) hw sign ec_f_p
ec_namedcurve ec_uncompress
[0x1051] CKM_ECDH1_COFACTOR_DERIVE keysize range (192, 521) hw derive
ec_f_p ec_namedcurve ec_uncompress
[0x1050] CKM_ECDH1_DERIVE keysize range (192, 521) hw derive ec_f_p
ec_namedcurve ec_uncompress
[0x1040] CKM_ECDSA_KEY_PAIR_GEN keysize range (192, 521) hw
generate_key_pair ec_f_p ec_namedcurve ec_uncompress
[0x0003] CKM_RSA_X_509 keysize range (1024, 4096) hw decrypt sign verify
[0x0001] CKM_RSA_PKCS keysize range (1024, 4096) hw decrypt sign verify
[0x0006] CKM_SHA1_RSA_PKCS keysize range (1024, 4096) sign verify
[0x0046] CKM_SHA224_RSA_PKCS keysize range (1024, 4096) sign verify
[0x0040] CKM_SHA256_RSA_PKCS keysize range (1024, 4096) sign verify
[0x0041] CKM_SHA384_RSA_PKCS keysize range (1024, 4096) sign verify
[0x0042] CKM_SHA512_RSA_PKCS keysize range (1024, 4096) sign verify
[0x0005] CKM_MD5_RSA_PKCS keysize range (1024, 4096) sign verify
[0x0008] CKM_RIPEMD160_RSA_PKCS keysize range (1024, 4096) sign verify
[0x000d] CKM_RSA_PKCS_PSS keysize range (1024, 4096) hw sign verify
[0x000e] CKM_SHA1_RSA_PKCS_PSS keysize range (1024, 4096) sign verify
[0x0047] CKM_SHA224_RSA_PKCS_PSS keysize range (1024, 4096) sign verify
[0x0043] CKM_SHA256_RSA_PKCS_PSS keysize range (1024, 4096) sign verify
[0x0044] CKM_SHA384_RSA_PKCS_PSS keysize range (1024, 4096) sign verify
[0x0045] CKM_SHA512_RSA_PKCS_PSS keysize range (1024, 4096) sign verify
[0x0000] CKM_RSA_PKCS_KEY_PAIR_GEN keysize range (1024, 4096)
generate_key_pair
Då ser man att för Nitrokey HSM finns både "mechanism 0xD" och sen
"mechanism 0x3"
[0x000d] CKM_RSA_PKCS_PSS keysize range (1024, 4096) hw sign verify
[0x0003] CKM_RSA_X_509 keysize range (1024, 4096) hw decrypt sign verify
Men för OpenPGP-kortet saknas de två.
Alltså:
mechanism 0xD
-->
[0x000d] CKM_RSA_PKCS_PSS keysize range (1024, 4096) hw sign verify
--> finns för nitrokey HSM
--> finns INTE för openpgp-kortet
mechanism 0x3
-->
[0x0003] CKM_RSA_X_509 keysize range (1024, 4096) hw decrypt sign verify
--> finns för nitrokey HSM
--> finns INTE för openpgp-kortet
Nar det gäller "mechanism 0xD" CKM_RSA_PKCS_PSS finns det liknande i
alla fall:
Det finns en som heter CKM_RSA_PKCS på openpgp-kortet:
[0x0001] CKM_RSA_PKCS keysize range (2048, 2048) hw decrypt sign verify
Funderingar:
Kan det gå att göra någon inställning (eller annan version av curl eller
SSL-bibliotek eller så) så att CKM_RSA_PKCS används istället för
CKM_RSA_PKCS_PSS (alltså att välja att använda det som stöds av
OpenPGP-kortet)?
Kan det vara så att någon annan variant av OpenPGP-kort (nyare version
kanske) skulle kunna ha stöd för någon av de "mechanisms" som verkar
behövas?
Tacksam för alla tips och idéer om hur man kommer vidare!
/ Elias
PS
Länkar till tidigare mejl om liknande saker:
https://mailman.dfri.se/mailman3/hyperkitty/list/eleg-projekt@lists.dfri.se…https://mailman.dfri.se/mailman3/hyperkitty/list/eleg-projekt@lists.dfri.se…https://mailman.dfri.se/mailman3/hyperkitty/list/eleg-projekt@lists.dfri.se…https://mailman.dfri.se/mailman3/hyperkitty/list/eleg-projekt@lists.dfri.se…
Hej!
Välkomna till distans-möte nummer 32 om hur vi kan bygga en egen
decentraliserad lösning för fri och öppen e-legitimation. Vi fortsätter
med kravspecifikation, design, implementation och testning av de olika
komponenter som kommer behövas.
Tid: måndag 23 juni 2025 klockan 18:00. Vi siktar på att hålla på i upp
till en timme.
Plats: https://jitsi.eliasrudberg.se/e-id-meeting
Förslag till agenda:
- CA-programvara för utgivaren och test med nginx, status? Procedur för
att förnya utgivarens cert?
- OpenPGP-kort, testat mer
- Sätta upp server med revokeringslista, ordna domän och webbserver för det?
- Skriva debattartikel om robusthet apropå BankID-problemen nyligen?
- "Invitation: Participatory Requirements Workshop for eIDAS Oversight
Platform", se projektets mejllista
- "Remiss av Uppgiftsskyldighet för vissa e-legitimationsföretag":
https://www.regeringen.se/remisser/2025/04/remiss-av-uppgiftsskyldighet-for…
-- senaste dag att svara är den 8 juli.
Alla är välkomna, både ni som varit med tidigare och alla nya som vill
vara med och diskutera och hjälpa till med det här.
Svara gärna här på mejllistan med alla frågor och funderingar inför
mötet, och förslag på fler saker vi borde ta upp.
Välkomna!
Vänliga hälsningar
Projektets styrgrupp genom Elias
Som jag skrivit tidigare var jag med på en paneldiskussion i Stockholm
den 10 Juni:
https://info.knowit.se/automation_av_pki
Huvudfokuset var CA/Browser Forum's beslut att förkorta
websides-certifikats giltighetstid till 47 dagar, vilket ställer större
krav på automatiserad förnyelse av websides-certifikat.
---
Henrik Andersson från Abero Security berättade om de olika protokoll som
finns för automatisk certifkat-uppdatering;
* SCEP - Simple Certificate Enrollment Protocol
* CMP/EST - lite modernare variant av SCEP
* ACME - det nya som bl.a. Let's Encrypt använder
Körde ett live-demo av ACME med smallstep-ca som server och certbot som
klient.
ACME har en plugin-arktitektur där det jobbas på hårdvaru-tokens (TPM
och SecureEnclave) under namnet device-attest-01. Se acmeprotocol.dev
---
Sedan följde en session där vi skulle reflektera över om
certifikathanteringen var på väg att försvinna till förmån för
ssh-nycklar, wireguard och openpgp. Det gnälldes också över att
constraints i X.509 är kasst implementerat och krashar vissa mjukvaror,
samt att ingen slår på CRL (revokeringslistor).
---
Tomas Gustavsson tog sedan över och pratade om EJBCA och de olika
entiteterna som finns i ett komplett system:
* CA - Certification Authority
* RA - Registration Authrorty
* VA - Validation Authority
* TSA - Timestamp Authority
Kom in på post-quantum algorithmer och nämde att MLDSA är både vacker
matematiskt och godkänd enligt NIST.
---
Sedan följde mingel och folk var allmänt intresserade av vårt e-leg
användningsområde. En smartcard-expert vid namn Pål Ragnarson nämnde
massor av hårdvarutokens, där jag febrilt antecknade buzzwords som jag
tänkte kolla upp senare (inte hunnit än):
* Fortify: webb-baserad smartcard enrollment
* TPM: om man har problem ska man kolla att man slagit på "Enhanced TPM"
i BIOS
* Yubikey: använder PIV, har plats för 24 tokens, FIDO for enterprise
* Thales MD830 / MD940 använder pksc15.
* SafeNET Etoken
* secure channel - global platform keys
* signature creation device
* JCOB-kort med hemmaskriven Applet
---
Vidare har jag anmält mig till ett resiliance-hackaton
https://cillers.com/hackathons/couchbase-disaster-resilience-hackathon
och försöker få till att min grupp ska utveckla vårt e-id :)
Ses på online-mötet på måndag!
/ Christian