- Eleg-projekt

Hur användare kan ha sin privata nyckel i en Yubikey, ykman piv generate-key, ykman piv generate-csr osv.
by Elias Rudberg 07 Jul '24

07 Jul '24

Hej eleg-projekt-listan! Här är ett sätt som verkar fungera för en användare som väljer att ha sin privata nyckel i en Yubikey. Baserat på bland annat de här två: "HTTPS client certificates using Yubikeys" - https://johanfagerstroem.github.io/2021/https-client-certificates-with-yubi… "cURL Authentication using certificates from smartcard" - https://qwerty1q2w.medium.com/performing-client-authentication-in-curl-usin… Vi tänker oss medborgaren Alice som kör Debian på sin dator. Alice vill få ett e-id utfärdat till sig och hon vill använda en Yubikey för sin privata nyckel. Alice installerar följande, vanliga debian-paket: sudo apt install opensc libengine-pkcs11-openssl gnutls-bin sudo apt install ykcs11 sudo apt install yubikey-manager sudo apt install yubico-piv-tool När yubikeyn sitter i datorn ska det gå att se den med följande kommando: ykman info Då visas serienummer mm. för Yubikeyn. Sen kan Alice skapa ett nyckelpar där den privata nyckeln skapas på yubikeyn: ykman piv generate-key 9a alice.pub Skapa certificate signing request (CSR): ykman piv generate-csr -s alice 9a alice.pub alice.csr Då skapas filen alice.csr som Alice ger till utfärdaren, som i sin tur utfärdar ett personligt certifikat till Alice (det gör utfärdaren med hjälp CA-programvaran som vi diskuterat tidigare). Alice får sen sin certifikat-fil från utfärdaren, i detta exempel heter filen eid_200007171717.crt.pem och 200007171717 är Alice personnummer i det här testet. Nu kan hon importera certifikat-filen in till yubikeyn: ykman piv import-certificate 9a eid_200007171717.crt.pem Sen är det klart, Alice har sitt certifikat och sin privata nyckel i sin yubikey. Nu kan Alice använda sitt certifikat för att ansluta till test-sidan https://eid-test-2.eliasrudberg.se/ Två varianter av hur det kan göras: med curl eller Firefox Alternativ 1: curl Kör först "p11tool --list-tokens" för att få fram vilken "URL" som gäller för yubikeyn, det ser ut såhär: $ p11tool --list-tokens [...] Token 1: URL: <här står URL-strängen> Label: PIV_II Type: Hardware token Flags: RNG, Requires login Manufacturer: piv_II Model: PKCS#15 emulated Serial: [...] Module: opensc-pkcs11.so Den där "URL" ser ut ungefär såhär: "pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=...;token=PIV_II" Anslut sedan med curl på följande vis, där $url är den URL som visades av "p11tool --list-tokens" ovan: curl -E $url https://eid-test-2.eliasrudberg.se/ --> då kommer en fråga om PIN-koden för yubikeyn: "Enter PKCS#11 token PIN for PIV_II:" och när man fyllt i den kommer man fram: Hej! personnummer = 200007171717 Den texten, "Hej! personnummer = 200007171717", är alltså det som testsidan https://eid-test-2.eliasrudberg.se/ svarar med, så det betyder att det hela fungerar. Alternativ 2: Firefox Inställningar i Firefox: Settings --> Privacy & Security --> Certificates --> Knappen "Security Devices..." --> Knappen "Load" --> Skriv ett valfritt Module Name och ange Module filename /usr/lib/x86_64-linux-gnu/libykcs11.so --> Starta om Firefox och kolla "Security Devices..." igen för att se att den nya syns där, med namnet du satte. När man sen går till https://eid-test-2.eliasrudberg.se/ i Firefox kommer en fråga om PIN-kod för yubikeyn och sen en ruta som säger: "This site has requested that you identify yourself with a certificate" och "Choose a certificate to present as identification" och en lista där det bara finns ett cert att välja, "Stored on Yubikey PIV #[...]". Väljer man det så fungerar sidan och visar det den ska, alltså "Hej! personnummer = 200007171717" Så det verkar fungera, både med curl och med Firefox. Hittills har bara jag själv testat det det här, alltså jag är "Alice" i testet och testar med en yubikey jag har på en dator jag har. Fler testare vore bra. Vi har några till yubikeys för test, jag kan skicka en till den som vill testa, säg bara till. Vad tror ni om det här, verkar ovanstående vettigt? Har jag tänkt fel någonstans eller missat något, finns enklare och/eller bättre sätt? Vad krävs för att kunna göra motsvarande med andra typer av "Hardware token" än just yubikey? / Elias

1 0

Funderingar om hur OpenPGP-kort kan användas, gpgsm, openssl, pkcs11
by Elias Rudberg 05 Jul '24

05 Jul '24

Hej eleg-projekt-listan! När det gäller hur man som användare kan använda OpenPGP-kort (kan vara i form av yubikey eller annat) för sin privata nyckel, finns ju två delar: (1) Skapa certificate signing request (CSR) som sedan ges till utfärdaren. (2) Använda det personliga certifikatet, när man väl fått det från utfärdaren. När det gäller (1) går det att använda kommandot gpgsm på följande sätt: gpgsm --armor --output mycsr.pem --gen-key vilket då skapar filen mycsr.pem kopplad till den privata nyckeln man har i sitt OpenPGP-kort. ( se https://security.stackexchange.com/questions/82284/create-certificate-witho… ) Det är ett sätt att lösa (1) alltså, frågan är sen hur man kan göra (2). I det enklare fallet när man har sin privata nyckel på fil, då kan man ju använda curl med --cert och --key såhär, som nämnts i tidigare mejl här på listan: curl --cert my_eid.crt.pem --key my_eid.key.pem https://example.org Men när den privata nyckeln är i ett OpenPGP-kort går det ju inte, då fungerar förstås inte "--key my_eid.key.pem" (eftersom någon sån privat-nyckel-fil inte finns) utan man behöver göra på något annat sätt. "man curl" säger bland annat följande: ----- --key <key> (TLS SSH) Private key file name. Allows you to provide your private key in this separate file. For SSH, if not specified, curl tries the following candidates in or‐ der: '~/.ssh/id_rsa', '~/.ssh/id_dsa', './id_rsa', './id_dsa'. If curl is built against OpenSSL library, and the engine pkcs11 is available, then a PKCS#11 URI (RFC 7512) can be used to specify a private key located in a PKCS#11 device. A string beginning with "pkcs11:" is interpreted as a PKCS#11 URI. If a PKCS#11 URI is provided, then the --engine option is set as "pkcs11" if none was pro‐ vided and the --key-type option is set as "ENG" if none was provided. ----- Det där med "specify a private key located in a PKCS#11 device" kanske är relevant. Ett nästa steg kan vara att läsa på mer om hur det fungerar. Den som har erfarenhet av såna saker, som att använda gpg eller openssl med pkcs11 eller liknande, eller känner till andra bättre sätt att göra det här, får mycket gärna hjälpa till! / Elias

1 0

Nytt test med nginx+gunicorn+flask som kan använda personnumret från klient-certifikatet
by Elias Rudberg 30 Jun '24

30 Jun '24

Hej alla på eleg-projekt-listan! Vi håller ju på med att ta fram en "proof-of-concept" för att kunna visa hur en fri e-legitimation kan utfädras och användas. Vi har en CA-programvara för utfäraden som kan användas för att skapa certifikat, och vi vill också kunna visa exempel på hur en "förlitande part" kan funka. Nu finns en lite annorlunda test-sida som exempel på hur en "förlitande part" kan fungera, alltså en webbsida där det krävs ett klient-certifikat (e-leg) för att komma in på sidan och där sidan kan använda information från certifikatet (som personnummer för användaren som anslutit). Det är en server som kör Debian GNU/Linux och använder programvarorna nginx, gunicorn och flask, på följande vis. I nginx-konfigurationen finns då bl.a. de här raderna: --------------------------------------------------------- # Here, specify the CA certificate from the issuer ssl_client_certificate /home/elias/ca-cert/issuingca.crt.pem; ssl_verify_client on; location / { if ($ssl_client_verify != "SUCCESS") { return 401; } proxy_redirect off; proxy_set_header X-EID-CERT $ssl_client_escaped_cert; proxy_pass http://127.0.0.1:8000; } --------------------------------------------------------- där filen issuingca.crt.pem är certifikatet för utfärdaren, som vi alltså har skapat med vår CA-programvara. Förlitande part behöver få det certifikatet från utfäraden och installera det på sin server. Raden med "proxy_pass" betyder att man skickar vidare till applikationen som finns på port 8000 och "proxy_set_header X-EID-CERT $ssl_client_escaped_cert" betyder att klientcertifikatet skickas vidare dit i form av en header med namnet "X-EID-CERT". Sen körs gunicorn (körs som en systemd-tjänst) som lyssnar på port 8000 och som kör en Flask-applikation såhär: /usr/bin/gunicorn eid-flask-app:app och själva applikationen är ett litet python-program som ser ut såhär: --------------------------------------------------------- from flask import Flask from flask import request from cryptography import x509 from cryptography.hazmat.backends import default_backend from urllib.parse import unquote app = Flask(__name__) @app.route('/') def hello(): cert = request.headers.get('X-EID-CERT') cert_unquoted = unquote(cert) cert_decoded = x509.load_pem_x509_certificate(bytes(cert_unquoted, 'utf-8'), default_backend()) cert_subject=cert_decoded.subject oid = x509.ObjectIdentifier("1.3.6.1.4.1.55594.1.3.121") attrs = cert_subject.get_attributes_for_oid(oid) personnummer = attrs[0].value return 'Hej! personnummer = {}\n'.format(personnummer) --------------------------------------------------------- Python-programmet använder alltså headern 'X-EID-CERT' med klientcertifikatet som nginx skickade vidare och plockar därifrån fram personnumret som finns i ett visst fält i certifikatet. Nu gör programmet inget mer än att skriva personnumret vilket inte är så spännande, men poängen är att programmet kan implementera vilken funktionalitet man vill, programmet körs för en identifierad användare och kan göra olika saker beroende på peronnumret. Till exempel kan programmet visa information som bara just den personen ska få se, eller ge tillgång till funktioner som just den personen ska få använda. Det verkar fungera, kan testas med curl: $ curl --cert eid_200007777777.crt.pem --key eid.key.pem https://eid-test-2.eliasrudberg.se/ Hej! personnummer = 200007777777 Texten "Hej! personnummer = 200007777777" som visas har alltså skapats av sista raden i python-programmet. Det går även att testa i webbläsare om användaren först lägger in sitt klientcert webbläsaren. Filerna finns i git-repot här: https://codeberg.org/DFRI-eID/go-eid-test-ca/src/branch/main/nginx-test Vad tror ni om det här, är den här sortens test ett vettigt sätt att visa hur en fri och öppen e-legitimation skulle kunna fungera? / Elias PS Alla som vill testa är välkomna att höra av sig till mig. PS2 Nästa möte är 2024-07-22 klockan 18

1 0

Sammanfattning av öppet möte nr 18 om att bygga egen e-leg-lösning, 24 juni 2024
by Elias Rudberg 27 Jun '24

27 Jun '24

Sammanfattning av öppet möte nr 18 om att bygga egen e-leg-lösning, 24 juni 2024: - Implementation av en första version av CA-programvara för utgivaren Nu finns funktionalitet för att spara i databas och återkalla certifikat, och skapa revokeringslista utifrån det. Vi diskuterade några detaljer kring det, som i vilken katalog databas-filen som default bör skapas. Vi diskuterade också en del kring var gränsen ska dras för vilken funktionalitet som behöver finnas i en första proof-of-concept. - Fortsättning av test med nginx Har inte hunnit något mer här sedan sist, nästa steg är fortfarande att kunna få fram och använda information från klient-certifikatet, t.ex. få test-webbsidan att säga "Hej <personnummer>" där personnumret som visas kommer från certifikatet som användaren anslutit med. - OpenPGP-kort, hårdvarunycklar osv, hur har testningen gått? Testanvändare har fått hårdvarunyckel att kunna testa med, vi hoppas på resultat från det snart. - Beskrivningar av arbetsflöden för utfärdande, användning, återkallande osv. Arbetet med vanliga frågor och svar (FAQ) mm fortsätter. - Arbetsfördelning Som tidigare. - Slutbetänkandet av Utredningen om säker och tillgänglig digital identitet har kommit Slutbetänkandet av den utredningen har alltså kommit nu (SOU 2024:45) och den handlar mest om den "digitala identitetsplånbok" som snart ska behöva finnas i varje EU-land. Delbetänkandet som kom i oktober (SOU 2023:61) handlade om statlig e-legitimation som sen ska kunna användas i kombination med den "digitala plånboken". Positivt är att EU-förordningen 2024/1183 som ligger med som Bilaga 2 i slutbetänkandet innehåller skrivningar om att det ska vara öppen källkod. - När blir nästa möte? Nästa möte blir måndagen 2024-07-22 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

Slutbetänkande av Utredningen om säker och tillgänglig digital identitet, publicerat 17 juni 2024
by Elias Rudberg 23 Jun '24

23 Jun '24

Hej! Utredningen om säker och tillgänglig digital identitet (särskild utredare Henrik Ardhede som var med på SamNet-konferensen) blev klar nyligen, slutbetänkandet "Kompletterande bestämmelser till EU:s reviderade förordning om elektronisk identifiering" finns här, en pdf på 394 sidor, publicerat 17 juni 2024: https://www.regeringen.se/rattsliga-dokument/statens-offentliga-utredningar… När det gäller tidsplan nämns att en "digital europeisk identitets-plånbok" ska finnas senast i december 2026: "Som tidigare redovisats förutsätter den reviderade eIDAS-förordningen att det finns tillgång till minst en digital europeisk identitets-plånbok i varje medlemsland. Detta krav ska vara uppfyllt inom 24 månader från och med ikraftträdande av genomförandeakter som fastställer de tekniska specifikationerna för identitetsplånboken och dess certifiering. Givet att rättsakterna antas i tid och i anslutning därtill publiceras i Europeiska unionens tidning, ska europeiska digitala identitetsplånböcker finnas tillgängliga senast i december 2026." I bilaga 2 finns "EUROPAPARLAMENTETS OCH RÅDETS FÖRORDNING (EU) 2024/1183" där det står om öppen källkod: "(33) Transparensen i europeiska digitala identitetsplånböcker och tillhandahållarnas ansvarsskyldighet är viktiga faktorer för att skapa social tillit och få till stånd acceptans för ramverket. De europeiska digitala identitetsplånböckernas funktionssätt bör därför vara transparent och i synnerhet medge kontrollerbar behandling av personuppgifter. För att uppnå detta bör medlemsstaterna lämna ut källkoden för programvarukomponenter i användartillämpningen av europeiska digitala identitetsplånböcker, inbegripet dem som rör behandling av personuppgifter och uppgifter om europeiska digitala identitetsplånböcker, inbegripet dem som rör behandling av personuppgifter och uppgifter om samhället, inbegripet användare och utvecklare, att förstå hur koden fungerar samt revidera och granska koden. Detta skulle öka användarnas förtroende för ekosystemet och bidra till de europeiska digitala identitetsplånböckernas säkerhet genom att göra det möjligt för vem som helst att rapportera sårbarheter och fel i koden. På det hela taget bör detta ge leverantörerna incitament att leverera och upprätthålla en mycket säker produkt. I vissa fall kan dock offentliggörandet av källkoden för bibliotek, kommunikationskanaler eller andra element som inte finns på användarenheten begränsas av medlemsstaterna, av vederbörligen motiverade skäl, särskilt med hänsyn till den allmänna säkerheten." Det kan alltså finnas undantag från kravet på öppen källkod, men undantag verkar bara gälla "källkoden för bibliotek, kommunikationskanaler eller andra element som inte finns på användarenheten". Förhoppningsvis betyder det att allt som installeras på användarenheten måste ha öppen källkod. / Elias

2 1

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

23 Jun '24

Hej! Välkomna till distans-möte nummer 18 om hur vi kan bygga en egen decentraliserad lösning för fri och öppen e-legitimation. Vi fortsätter med kravspecifikation, design och implementation av de olika komponenter som kommer behövas. Tid: måndag 24 juni 2024 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: - Implementation av en första version av CA-programvara för utgivaren - Fortsättning av test med nginx - OpenPGP-kort, hårdvarunycklar osv, hur har testningen gått? - Beskrivningar av arbetsflöden för utfärdande, användning, återkallande osv. - Arbetsfördelning - Slutbetänkandet av Utredningen om säker och tillgänglig digital identitet har kommit 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 om du har frågor eller funderingar inför mötet. Välkomna! Vänliga hälsningar Projektets styrgrupp genom Elias

1 0

Sammanfattning av öppet möte nr 17 om att bygga egen e-leg-lösning, 29 maj 2024
by Elias Rudberg 01 Jun '24

01 Jun '24

Sammanfattning av öppet möte nr 17 om att bygga egen e-leg-lösning, 29 maj 2024: - Implementation av en första version av CA-programvara för utgivaren Den senaste koden med databas för utfärdade certifikat ska testas, bl.a. testa hur revokeringslista kan skapas och användas. Jobb med att snygga till koden och förtydliga med kommentarer osv fortsätter. - Fortsättning av test med nginx Test-sidan https://lab.joxaren.se fungerar om ens certifikat är inlagt. För att testa, följ instruktion i separat mejl till e-postlistan [1]. Nästa steg när det gäller nginx-testet med mTLS är att få sidan att kunna använda information (personnummer) från det personliga certifikatet för den person som anslutit. Har inte hunnits med ännu. Alla som vill hjälpa till med den delen är mycket välkomna. Fler testpersoner skulle vara bra också, hör av dig om du vill testa. - OpenPGP-kort, hårdvarunycklar osv, vilka varianter kan och bör vi pröva? Några möjliga alternativ: - OpenPGP-kort för kortläsare - Yubikey eller liknande - Tillitis TKey Den som har något av ovanstående kan testa på egen hand. Vi har också några stycken Yubikey och TKey som de personer som vill testa kan få använda, de kan lånas ut till olika personer efter behov. Obs att Tillitis TKey kan kräva lite mer jobb, se tidigare mejl till e- postlistan om det [2]. Vi diskuterade att det kan verka förvirrande att det finns så många olika alternativ, men att det i grunden är bra att det går att göra på olika sätt, så länge man följer specifikationen. Senare kan vi kanske välja en metod som "huvudmetod". - Beskrivningar av arbetsflöden för utfärdande, användning, återkallande osv. Senaste versionen av "vanliga frågor och svar" (FAQ) med schema.org- FAQ-stöd visades och diskuterades. - Arbetsfördelning Olika typer av arbete som pågår, olika personer gör olika delar: - fortsatt utveckling av CA-programvara för utgivaren - testa senaste CA-programvaran inkl. skapa och använda revokeringslista - fortsättning med nginx-testet - fortsatt jobb med beskrivningar av användningsfall och FAQ osv. - Övrig fråga: tidsplan? Vi diskuterade vad som är en rimlig uppskattning av när vår proof-of- concept kan förväntas vara klar i någon sorts lite mer officiell första version. Tidigare har "hösten 2024" nämnts, men med tanke på att allt sker ideellt och vi inte vet hur mycket tid olika personer kommer att ha, kanske "under 2025" är mer realistiskt? Svårt att säga, vi diskuterade det lite fram och tillbaka. I vilket fall som helst går det snabbare om fler hjälper till, den som tycker det går långsamt uppmuntras att vara med så blir vi klara snabbare! :-) - När blir nästa möte? Nästa möte blir måndagen 2024-06-24 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] https://mailman.dfri.se/mailman3/hyperkitty/list/eleg-projekt@lists.dfri.se… [2] https://mailman.dfri.se/mailman3/hyperkitty/list/eleg-projekt@lists.dfri.se…

1 0

Välkomna på öppet möte nr 17 om att bygga egen e-leg-lösning, 29 maj klockan 20
by Elias Rudberg 28 May '24

28 May '24

Hej! Välkomna till distans-möte nummer 17 om hur vi kan bygga en egen decentraliserad lösning för fri och öppen e-legitimation. Vi fortsätter med kravspecifikation, design och implementation av de olika komponenter som kommer behövas. Tid: onsdag 29 maj 2024 klockan 20: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: - Implementation av en första version av CA-programvara för utgivaren - Fortsättning av test med nginx - OpenPGP-kort, hårdvarunycklar osv, vilka varianter kan och bör vi pröva? - Beskrivningar av arbetsflöden för utfärdande, användning, återkallande osv. - Arbetsfördelning 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 om du har frågor eller funderingar inför mötet. Välkomna! Vänliga hälsningar Projektets styrgrupp genom Elias

1 0

Decentralized Identifiers (DIDs) v1.0 för FOSS e-elegitimation?
by Mattias Axell 15 May '24

15 May '24

Hej, Jag har tjattat med en kontakt som kan vara intresserad av att använda https://www.w3.org/TR/did-core/ - kan det vara något för att bygga FOSS decentraliserad e-legitimation. Kan det vara något att göra en Proof of Concept med? Kanske personen eller kollega kommer in här med intro. Jag är också med i https://www.w3.org/community/nordic-data/ som Internetstiftelsen.se startat. I sin linda men kanske en bra koppling till just Internetstiftelsen som borde gilla https://www.w3.org/TR/did-core/ Är det någon som varit i kontakt med DIGGs utredare ännu? Känns som att det vore intressant att ta del av utredningen tittar på för underlag, vilka de pratar med. Det här projektet bör väl ha kontakt med den personen? Mvh, Mattias -- DFRI.se Mastodon: https://mastodon.social/@dfri

7 14

BankID på olika operativsystem
by Hampus Rydh 12 May '24

12 May '24

Hej! Jag hade fått uppfattningen båda av tidigare sökning på internet och från projektet att BankID inte fungerar på något operativsystem förutom iOS och Android. Nu hittade jag en diskussion från 2019 på ett forum där flera personer verkade lyckas använda BankID med hjälp av andra operativsystem. Jag tror inte det påverkar vårt projekt något speciellt, men det kanske är interessant. https://forum.fairphone.com/t/lineage-os-och-mobilt-bankid-in-sweden/50240 Vänliga hälsningar, Hampus Rydh

1 0

2025

2024

2023

2022

2021