- Eleg-projekt

Re: Debattartikel [var: SVT skriver om att "Attacken mot Bank-id borde mana till en större diskussion om alternativ till tjänsten"]
by Erik Josefsson 25 Jul '25

25 Jul '25

Fattar jag rätt om det blir tydligare så här? original:ID-handlingen innehåller digitala certifikat, som då får en digital signatur av en betrodd instans, ändra till -> ID-handlingen innehåller digitala certifikat, som vid verifikationen får en digital signatur av en betrodd instans, mvh //Erik Sent from my Samsung Galaxy smartphone.-------- Original message --------From: Marcus via Eleg-projekt <eleg-projekt(a)lists.dfri.se> Date: 20/07/2025 10:41 (GMT+01:00) To: Elias Rudberg via Eleg-projekt <eleg-projekt(a)lists.dfri.se> Subject: [Eleg-projekt] Re: Debattartikel [var: SVT skriver om att "Attacken mot Bank-id borde mana till en större diskussion om alternativ till tjänsten"] Hej, jag tycker att det ser riktigt bra ut!Jag står gärna med på artikeln om det inte är för sent!! Bra jobbat allihop!! MvhMarcus On lör, jul 19 2025 at 17:49:18 +0200, Elias Rudberg via Eleg-projekt <eleg-projekt(a)lists.dfri.se> wrote: Hej, Tack Mikael och Linn för era tankar, här nedanför är en ny version där jag lagt till enligt era förslag (med den grundläggande förklaringen från Linn, jag håller med om att det nog blir för långt att ha mer än så). Jag petade in ordet "lokalt" också för att man inte ska tro att listan kräver central kommunikation varje inloggning. Allt annat är likadant som förut. Blir det bra med den här versionen? Linn, kan vi lägga till ditt namn också? / Elias -- här kommer nya versionen --- (Rubrik) Robust e-legitimation är inte svårt (Kontextualisera) Samhällsdebatten om elektronisk legitimation har aktualiserats igen efter incidenten när BankID låg nere i tre timmar. Civilminister Erik Slottner anser att staten bör ta ett större ansvar och att det behöver finnas flera lösningar. Det är en viktig diskussion, men det finns en övertro på centraliserade system. Behovet av en central server som måste vara nåbar är djupt rotat i tankesättet hos många beslutsfattare, vilket framgår av Finansinspektionens förslag om ”Uppgiftsskyldighet för vissa e-legitimationsföretag” Fi2025/00837, där myndigheten verkar ta för givet att alla elektroniska legitimeringar samlas in av utgivaren. Vidare säger Andreas Bergqvist på BankID till SVT att ”oavsett vem som driver en tjänst så kommer alla ha samma utmaning som vi när det gäller cyberangrepp”. Denna föreställning om att central aktör måste vara nåbar vid varje enskild identifiering, behöver förändras. DIGG (Myndigheten för digital förvaltning) skriver om ersättning till e-legitimationsföretag för användning av e-legitimation i MDFFS 2025:2 där den rörliga ersättningen baseras på antalet identifieringar. Återigen verkar synsättet vara att varje identifiering måste involvera någon form av bokföring hos en central part. (Teknisk förklaring) Grundtekniken som får kommunikation på internet att bli säker och trovärdig kräver inte att en central tjänst är igång och fungerar. På samma sätt som polisen kan ge ut plastkort som inte försvinner bara för att någon i protest blockerar ingången till polisstationen de hämtas från, kan företag och myndigheter ge ut elektroniska ID-handlingar som går att verifiera utan att fråga utgivaren varje gång. ID-handlingen innehåller digitala certifikat, som då får en digital signatur av en betrodd instans, t.ex. Polismyndigheten eller BankID. För att spärra en ID-handling publicerar utgivaren en lista med serienummer på ej-giltiga ID-handlingar. Denna lista innehåller i sig ingen personlig information, utan används enbart lokalt när en autentisering sker och det finns ett specifikt serienummer att kolla upp. Om du då försöker logga in hos din hyresvärd för att boka nästa tvättid kan du visa upp ditt certifikat för hyresvärden som då, utan att behöva internet-uppkoppling, kan verifiera att detta certifikat är utfärdat av någon som den litar på och att du kan boka. Det finns inget i grundtekniken som kräver att utgivaren är aktiv aktör i inloggningarna som är fallet med BankID och Freja. (Robusthet) System som är decentraliserade och kan fungera lokalt, där varje användning inte behöver gå genom en central punkt, är överlägsna när det gäller robusthet. Det gör att samhällskritiska system fortsätter att fungera under krig eller stora cyberangrepp av främmande makter. Decentraliserade lösningar är dessutom att föredra utifrån ett demokrati-perspektiv: ett starkt samhälle bygger på att det finns starka, fria individer, som inte ständigt står under statens kontroll. Auktoritära stater vill gärna ha centrala system som gör det möjligt för staten att utöva kontroll över människor. Så är det inte i ett fritt samhälle. Den centralisering som auktoritära stater strävar efter kan förstås verka bra för en diktator som vill behålla makt och kontroll, men centraliseringen gör samhället sårbart. (om vår förening) Föreningen för Digitala Fri- och Rättigheter (DFRI) har ett projekt om fri och öppen e-legitimation, där vi ger exempel på hur en lösning skulle kunna skapas baserat på fri och öppen programvara, öppen specifikation, tillgänglighet och decentralisering. Vi ser ett stort behov av samhällsförändring i riktning mot mer frihet och mindre central kontroll, både för demokratins skull och för att göra samhället mindre sårbart. (Slutkläm) Nästa gång du blir tvingad till ett inloggningssystem som kräver att du låser dig till ett visst bolags app, fråga vad för protokoll de använder, om det är decentraliserat, och om du själv eller tillsammans med den eller de du väljer är fri att skriva en egen implementation på öppna standarder. Alla förtjänar att känna trygghet i att e-id-systemet fungerar även under kris och krig! (Signatur) Christian Häggström, Elias Rudberg, Leif-Jöran Olsson, Mikael Odhage Föreningen för digitala fri- och rättigheter -- slut på nya versionen --- _______________________________________________ Eleg-projekt mailing list -- eleg-projekt(a)lists.dfri.se To unsubscribe send an email to eleg-projekt-leave(a)lists.dfri.se

5 6

SVT skriver om att "Attacken mot Bank-id borde mana till en större diskussion om alternativ till tjänsten"
by Elias Rudberg 20 Jul '25

20 Jul '25

Hej! Här säger cybersäkerhetsexperten Marcus Nohlberg att "både individer och samhället borde fundera på alternativ till Bank-id och utforma en plan b": "Avancerad överbelastningsattack mot Bank-id: ”Kommer definitivt hända igen”" https://www.svt.se/nyheter/inrikes/avancerad-overbelastningsattack-mot-bank… En representant för Bank-id säger "oavsett vem som driver en tjänst så kommer alla ha samma utmaning som vi när det gäller cyberangrepp". Det stämmer väl inte riktigt, man kan ju ha ett decentraliserat system som i sin design är mer robust. De tänker inte ens på den möjligheten verkar det som. Vi kanske kan passa på att skriva en debattartikel om det nu? Någon här på listan som skulle vilja hjälpa till med att skriva något? / Elias

7 12

Sammanfattning av öppet möte 33 om att bygga egen e-leg-lösning, 14 juli 2025
by Elias Rudberg 18 Jul '25

18 Jul '25

Sammanfattning av öppet möte 33 om att bygga egen e-leg-lösning, 14 juli 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? Fortfarande vill vi garna fa till hårdvarunyckel for utgivaren, inte hunnit. C p12-fil till nästa möte. - OpenPGP-kort, testat mer Se https://mailman.dfri.se/mailman3/hyperkitty/list/eleg-projekt@lists.dfri.se… LJO tänker verifiera Elias steg. Möte med Cryptas för att se att vår tolkning av best practice funkar osv. ide: prova med curl byggt med olika backend-mekanismer, openssl/gnutls/wolfssl - Sätta upp server med revokeringslista, ordna domän och webbserver för det? Börjat enligt tidigare. Nästa steg är att byta ut revokeringslistan av de olika utfärdarna. Skulle enligt tidigare mötesanteckningar behöva ett sätt att ladda upp revokeringslista till server, ljo kollar vidare på det. - Tidsplan för "release" av vår proof-of-concept? Har sagt tidigare att vi skulle ha något under 2025 Vad vill vi få med? hårdvarunycklar, p12-fil ... server med revokeringslista enligt ovan FAQ:n offentliggöra Vad får vi skjuta på? - Skriva debattartikel om robusthet apropå BankID-problemen nyligen? Inget har hänt mer än små bubblor av tankeaktivitet. Christian kallar till digitalt skrivarmöte, så får vi se hur många som kan. - Remiss-svar skickat för "Uppgiftsskyldighet för vissa e-legitimationsföretag". Andra remisser eller liknande saker på gång? Skickades in före deadline som var 8 juli. https://www.dfri.se/remissvar-pa-uppgiftsskyldighet-for-e-legitimationsfore… - Christian har varit på hackaton --> demo! Temat for hackatonet var att göra en resilient app som kunde funka även om nätverket var nere. C var med som enskild person, blev assignad till en grupp och diskuterade via en digital whiteboard. Skissade på tre aktörer: en person, en utgivare, en verifierande part. Sen var det inte så många som jobbade på det förrän på själva dagen, då samlades man och kodade tillsammans. Gjorde tre olika appar for de tre olika aktörerna, olika kataloger i ett repo https://github.com/sardnas/id-card. Gruppen kunde visa att de kunde koppla ner utgivaren och att det ända gick att logga in hos verifierande part. En tilldelad distribuerad databas användes for revokeringslistan. Fler hackaton finns på https://cillers.com/hackathons Termen "resilient" är på svenska "motståndskraftig". - När blir nästa möte? Nästa möte hålls måndag 2025-08-04 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

1 0

Välkomna på öppet möte nr 33 om att bygga egen e-leg-lösning, 14 juli klockan 18
by Elias Rudberg 13 Jul '25

13 Jul '25

Hej! Välkomna till distans-möte nummer 33 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 14 juli 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? - Tidsplan för "release" av vår proof-of-concept? - Skriva debattartikel om robusthet apropå BankID-problemen nyligen? - Remiss-svar skickat för "Uppgiftsskyldighet för vissa e-legitimationsföretag". Andra remisser eller liknande saker på gång? 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

1 0

Artikel i Flamman idag: "Hackarna som utmanar Bankid"
by Elias Rudberg 25 Jun '25

25 Jun '25

Jag blev intervjuad av Daniel Díaz för några veckor sedan, om det här projektet, idag kom hans artikel: https://www.flamman.se/hackarna-som-utmanar-bankid/ / Elias

1 0

Sammanfattning av öppet möte 32 om att bygga egen e-leg-lösning, 23 juni 2025
by Elias Rudberg 24 Jun '25

24 Jun '25

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

2 1

Försöker använda OpenPGP-kort, vad som funkar och inte funkar, hittills
by Elias Rudberg 24 Jun '25

24 Jun '25

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…

1 0

Välkomna på öppet möte nr 32 om att bygga egen e-leg-lösning, 23 juni klockan 18
by Elias Rudberg 22 Jun '25

22 Jun '25

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

1 0

Anteckningar från paneldiskussion om certifikat
by Christian Häggström 19 Jun '25

19 Jun '25

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

1 0

Taler och ID
by Mikael Odhage 09 Jun '25

09 Jun '25

Fann denna länk i min läsning apropå att Gnu Taler blivit myndigt: https://nlnet.nl/project/TALER-LookupService/ -- Vänliga hälsningar Mikael Odhage +46(0)709933651 Jabber/XMPP: odhagemikael(a)xabber.de Lite Fediversum: Friendica: https://libranet.de/profile/mikaelodhage/profile Bilder på: https://pixelfed.de/OdhageMikael Min publika nyckel hittas på hkp://keys.gnupg.net eller keys.gnupg.net

1 0

2025

2024

2023

2022

2021

Eleg-projekt