Fick mitt nya ID-kort från posten igår, laddat med digitala certifikat för signering och krypto. Kan användas för inloggning, mail-signering, mail-kryptering, fil-kryptering etc. Rätt intressant faktiskt. Så nu kan ni skicka krypterade mail till mig. Certifikatet finns att hämta här.

Och den pyttelilla kreativa ådran i mig funderar genast på hur sådana här grejor skulle kunna användas i händelse av krig. Borde också kunna vara bra plot-element för en krigsnovell.

/J

Är det här en extragrej eller hänger det med alla nya ID-kort ?

Eller är det ID under VPl som du menar ?

Hmm...rättar mig själv. Tror jag iaf. Varför skulle det där finnas på ID-handlingarna under VPL ??

Rätt som det är får vi det säkert inopererat under huden med tillhörande GPS.
Ja det är spännande tidender som väntar...

Man får specifikt begära det. Hela kittet med kortläsare, programvara, ID-kort och certifikat kostar 995:-. Enbart ett "mjukt" cert (d.v.s. du får fil med privat nyckel) utan någonting annat kostar 87:-. Inte lika säkert men t.ex. RSV accepterar det för att du skall få göra ändringar i din deklaration.

Detta kommer att komma starkt i framtiden tror jag. Folk kommer att vilja kunna identifiera sig över nätet. Och "24-timmars myndigheten" kommer att behöva det. Och krånglet att få viktiga saker skickade via snigel-post (som t.ex. lösenord) avstår folk nog gärna ifrån när det går lika bra att få det direkt i mail-boxen eller webläsaren.

Mer info här:
http://www.posten.se/eid

/J

Kan man få det här inkört på körkortet också ?
För det är ju mindre smidigt med två kort än ett....

Tvivlar på det.

Det som verkigen stör dock är att man inte får nationalitet utsatt på kortet. Hade man fått det hade kortet funkat som pass i hela EU.

/J

Det stora problemet med PKI (Public Key Infrastructure), i vilket certifikat är en del, är det som på engelska kallas certificate revocation, d.v.s. annulering av certifikat som av någon anledning inte längre är giltiga. För att förklara vad detta är så krävs en kort introduktion om hur PKI fungerar:

Vanligtvis inom kryptografi så används så kallade "symmetriska nycklar" för att kryptera data. Samma nyckel som användes för att kryptera datan krävs för att man skall kunna dekryptera datan. Inom PKI så används även så kallade "assymmetriska nycklar" (exempelvis RSA-nycklar) för att kryptera data. Istället för en nyckel, så har man här ett nyckelpar, bestående av en privat nyckel och en publik nyckel. För att man skall kunna dekryptera data som krypterats med den privata nyckeln så krävs att man har tillgång till den publika nyckeln. För att man skall kunna dekryptera data som krypterats med den publika nyckeln så krävs att man har tillgång till den privata nyckeln. Den privata nyckeln hålls hemlig av sin ägare och skyddas vanligtvis med ett lösenord. Den publika nyckeln kan ges till vem som helst. Det är den publika nyckeln som är inbäddad i ett certikat, och vad certifikatet gör är att det knyter den publika nyckeln till en identitet.

Om Alice nu vill skicka data till Bob, så måste Alice på något sätt veta om det certifikat, och den där i inbäddade publika nyckeln, hon har fått från någon som påstått sig vara Bob fortfarande är giltigt. Det kan ju t.ex. hända att Charlie lyckades lura den som gav ut certifikatet att han är Bob, och därigenom kunde få ett certifikat utfärdat i Bobs namn men med Charlies publika nyckel. För att denna annulering skall fungera så krävs att den som skapat certifikatet publicerar en så kallad CRL (Certificate Revocation List), vilket är en lista över vilka av de utgivna certifikaten som är annulerade, och att Alices programvara kollar om certifikatet hon har fått finns med i denna lista. Tyvärr så sker inte båda dessa två saker i praktiken i dag i nästan något fall, och hela PKI-modellen stupar därmed säkerhetsmässigt. En alternativ modell, till den strikta hierarkiska modellen i en PKI, är den "web of trust" modell som används när man skickar mail med PGP (Pretty Good Privacy) baserade program, som t.ex. GNUPG. Om någon vill veta mer om PKI-relaterade saker, så skicka ett meddelande till mig. Jag arbetar för närvarande med att skriva programvara för att skapa, annulera och använda certifikat och följer även aktivt IETF PKIX maillistan, så jag har viss koll på området.

Vem var Alice nu igen??

Snällasnälladödamigintejagskaaldriggöraomdet

Det vet väl alla. Det är hon som gett namn åt den här.

Intressant, intressant.

Någon som kan göra en kort jämförelse mellan Föreningssparbankens och Handelsbankens m.fl:s BankID, Nordeas Nordea Certifikat och Postens eID?

Jag funderar på att skaffa något av dem, inte för att jag (ännu) har någon särskild nytta av sådant, främst för att jag tycker det är kul att prova ny teknik. Vilken av dessa elektroniska ID-handlingar har någon framtid? Nordeas är väl för "litet" för att lyckas?

Vilket är mest användbart idag?

Jag lutar väl mest åt Postens eID, mest bara för att det även är en fysisk ID-handling. Vore ju tufft att kunna använda det som passerkort och allt-möjligt-som-lovas-i-stora-tomma-ord.

Men det blir väl som vanligt: ännu ett kort i plånboken att lägga till körtkortet, patientkortet, betalkortet, passerkortet, SAS-biljettlöst-resande-kortet, lokaltrafikens månadskort + värdekort, MedMera-kortet, Ica-kortet, Studentlegget, OKQ8-kortet, Apotekskortet, SvenskaSpel-kortet och alla andra onödiga rabatt/medlemskort som man i slutändan aldrig har med sig när man behöver det. Ja, jävlar, ju mer tekniken går framåt desto mer har vi kvar att vandra.

För den som undrar vad som finns i ett certifikat så följer här en människoläsbar (eller kanske rättare sagt; datasäkerhetsfanatikerläsbar) utskrift av J-Stars certifikat (namn och mailadress ändrade):



Några kommentarer:

1. Certifikatet är i PKCS (Cryptographic Message Syntax Standard ) #7 [1] format. Det hade varit praktiskt att även få certifikatet i PEM (Privacy Enhanced Mail) [2] format.

2. De listar en URI (Uniform Resource Identifier) [3] till en CRL (se tidigare inlägg ovan). En URI kan förenklat ses som en mer generell form av en URL (Uniform Resource Locator) [3]. URIn till CRLen är:



Detta är bra. Då krävs bara att den som ska använda certfikatet har programvara som hämtar CRLen. Detta är, som jag tidigare nämnt, ovanligt i praktiken. Dessutom uppstår två nya problem med Postens lösning:

2.2 URIn anger en adress till ett LDAP (Lightweight Directory Access Protocol) [4] katalog. Jag skulle gärna sett att man även kunde hämta CRLen från en HTTP (Hypertext Transfer Protocol) [5] server, d.v.s. en webserver.

2.3 Är man paranoid, som jag är, så kan man anmärka på att CRLen hämtas över en osäker (okrypterad) länk. Jag skulle gärna se att CRLen kunde hämtas över en SSL [6] eller TLS [7] säkrad uppkoppling istället för en ren TCP [8] uppkoppling.

3. Nyckellängden på RSA-nyckeln är 1024 bitar. Detta motsvarar ungefär en nyckellängd på 80 bitar för en symmetrisk nyckel, och är i mitt tycke för vissa tillämpningar för kort redan i dagsläget (för att inte tala om läget om tio år). Postens privata RSA-nyckel som signerat J-Stars certifikat är som tur är på 2048 bitar.

4. Certifikatet innehåller bara namn och emailadress. Hur är det meningen att, i första hand, myndigheter ska kunna knyta nyckeln till rätt identitet? Jag skulle vilja ha med personnummer i certifikatet.

5. Posten har i certifikatet kodat in begränsningar om hur det får användas:



Detta kan oftast kringsgås i praktiken, men det är ändå småaktigt gjort av dem i mitt tycke.

[1]
http://www.rsasecurity.com/rsalabs/pkcs/pkcs-7/

[2]
http://www.rfc-editor.org/rfc/rfc1421.txt
http://www.rfc-editor.org/rfc/rfc1422.txt
http://www.rfc-editor.org/rfc/rfc1423.txt
http://www.rfc-editor.org/rfc/rfc1424.txt

[3]
http://www.w3.org/Addressing/

[4]
http://www.rfc-editor.org/rfc/rfc2251.txt

[5]
http://www.rfc-editor.org/rfc/rfc2616.txt


[6]
www.netscape.com/eng/ssl3/

[7]
http://www.rfc-editor.org/rfc/rfc2246.txt

[8]
http://www.rfc-editor.org/rfc/rfc793.txt

Jag skulle vilja säga Postens eID just eftersom Posten är en utfärdare inte bara av digitala ID utan också även fysiska sådana också.

Jag vet dock inte hur bankID funkar. Är det med smart-card det också?

/J

Kommentarer till kommentarer.

2) Det riktigt taskiga är inte bara att Postens LDAP server inte använder sig av SSL... utan den är vidöppen för alla att söka i. Det är ap-kass därför att det lämnar hela katalogen vidöppen för spammare att samla adresser. Jag kommer att skicka kommentarer till Posten om detta och föreslå att användaren själv skall kunna styra hur/om certen publiceras.

4) (Omkastat för bättre sammanhang). Detta är bara mitt S/MIME-cert för just den mail-adressen du har fått. På kortet finns plats för fler cert. Just nu finns där 7 cert:

- Autentiserings + krypto cert som har mitt personnummer + namn.
- Signerings cert, också det med personnummer + namn.
- 4 S/MIME cert för mina 3 mail-adresser (råkade begära en dublett).
- Postens rot-cert.

Ett problem som är just nu är att programmet tillåter inte att jag tar bort cert från kortet. Det är dumt eftersom det är lätt att begära S/MIME-cert (görs över nätet med auth-certet som identifiering).

3) Auth + sign + enc certen gäller i 5 år. S/MIME-certen bara i två år. Sedan förnyas de... och då kan nyckellängden utökas. Jag kan dessutom begära nya S/MIME-cert närhelst jag vill.

5) Som sagt, det är enbart S/MIME-certet du har fått. De andra certen har (kanske) andra rättigheter. Vad använde du för program för att skriva ut certet så där?

Känner du fr övrigt till någon utility som gör att man kan signera vanlig klartext och sedan publicera den (typ här på SoldF) med cert-info och så vidare så att någon annan kan mata in hela texten i programmet och se att texten är ordenligt signerad?

/J

Åhhh..shite!

Jag vill bara tillägga att jag inte fattar nött av det där tekniska mumbo jumbot!

Ok.... snabblektion i elektroniska certifikat-

Du är på din grupperingsplats. Telefonen ringer. Någon ger dig en order. Ett antal frågor duker upp:
- Hur vet du att den som ringer är den han/hon utger sig för att vara? Det kanske är en spetsnäsa som lurar dig?
- Hur vet du att ingen avlyssnat ordern på vägen? Bush och hans NSA-pojkar kanske sitter och lyssnar?
- Hur vet du att ingen ändrat ordern? Saddam kanske har pillat på ordern för att få dig att skjuta på civila?

Vi har samma problem över Internet. Att kunna identifiera sig är inte det lättaste faktiskt. Meddelanden kan lätt avlyssnas och ändras på vägen.

Elektroniska certifikat är en speciell slags fil som fungerar som ett ID-kort. De är gjorda så att de skall vara mycket svåra att förfalska (det går om du har extremt mycket datorkraft). Dessa certifikat kan man använda till följande:

- Att identifiera sig. Mottgaren kan vara säker på att du är du.
- Att signera meddelanden. När detta har skett så kan mottagaren med säkerhet få veta: 1) Vem det kommer ifrån. 2) Att meddelandet inte har ändrats på vägen.
- Kryptera meddelanden. Den som vill skicka ett meddelande till mig använder sig av mitt öppna certifikat och krypterar meddelandet med detta. Sedan är det bara jag som kan öppna det meddelandet. Ingen annan kan läsa det, även om de lyckas fånga upp det på vägen.

Ett certifikat har två delar: en öppen (brukar kallas "Den publika nyckeln) och en hemlig ("Den privata nyckeln"). Den publika nyckeln skall delas ut till alla som jag vill kommunicera med. Den privata nyckeln skall hållas jättehemlig. Ingen annan än jag få ha tillgång till den.

Den publika nyckeln används av andra för att:
- Jämföra med det cert som följer med signerade meddelanden.
- Kryptera meddelanden som skall till mig.

Den privata nyckeln används för att:
- Signera mina meddelanden.
- Dekryptera meddelanden som krypterats med den publika nyckeln.


Certifikat utfärdas av någon och i mitt fall är det av Posten. Detta står i mina cert. För att kontrollera det så kan man jämföra en viss del på certifikaten med Postens så kallde rot-certifikat. Och om man då litar på att Posten gjort ett bra jobb, då vet man att mina cert är ok. Posten är i det här fallet en så kallad Certificate Authority (CA). Och om man beslutat sig för att Posten är en bra CA, då laddar man hem rot-certifikat och installerar på datorn. Då kommer datorn i fortsättningen att automatiskt kunna kolla alla cert som Posten utfärdat.


Vet inte om detta hjälpte eller bara ökade förvirringen. Men nu har jag försökt i alla fall.

/J

Jag är tyvärr inte förvånad.





Kommandoradsprogrammet openssl som följer med OpenSSL. Jag vet inte om det även fungerar under Microsoft Windows, men jag misstänker det. Kommandot jag använde är:

Cynics'R'Us har talat. Sant är att Posten är nybörjare som CA... men de försöker och supportpersonalen är vänliga och mottagliga. Om du kolla deras hemsida för detta...

http://www.posten.se/eid

...och rotar runt bland dokumenten där så ser du att ambitionen finns där och de har potential att bli bra på detta. De behöver konstruktiv feedback från kunderna för att uippnå detta. Och där kan folk som du och jag göra en hel del för att hjälpa dem. Jag tror att det är i allas intresse att Posten blir riktigt bra på detta så att vi får en stabil och pålitlig CA i Sverige, håller du inte med?

Tack för tipset om OpenSSL.

/J

Många år av datorer i allmänhet, och datasäkerhet i synnerhet, har satt sina spår...



Problemet är att varje gång jag börjar tro på PKI, så räcker det att jag läser några inlägg på IETF PKIX listan för att jag ska återgå till mitt normalläge. För den som vill få sina PKI-drömmar krossade rekommenderas:

http://www.cs.auckland.ac.nz/~pgut001/pubs...s/x509guide.txt

Mer läsvärt finns på:

http://www.cs.auckland.ac.nz/~pgut001/

Så vad är lösningen tycjker du? Bitch & Moan... eller jobba vidare tills det blir någon ordning på saker?

/J

Jag är optimistisk realist. Jag har själv designat, och designar just nu, system som bygger på PKI, så helt emot kan jag knappast anses vara. Detta innebär dock inte att jag inte kan anse att en del av teknologierna, och deras standarder, i det är dåliga. En del av se dåliga sakerna kommer, bland annat på grund av politiska och ekonomiska skäl, inte att fixas hur mycket man än kämpar som enskild person. Ett allmänt problem är att ITU haft ett finger med i spelet, något som alltid resulterar i extremt överkomplicerade och oläsbara standarder som oftast kostar hutlöst mycket att köpa. Har du läst standarderna för X.509v3 med anhang? Har du läst PKCS-standarderna? Läs dem och försök sedan konstruera system som fungerar ihop de övrigas system. Gråt. Bara för att jag är optimist i grunden så innebär det inte att jag måste tycka att allting är bra. Vi kommer att få leva länge med de standarder som finns inom PKI i dagsläget, och det är bara att bita ihop och försöka gilla läget för oss som utsätts för dem dagligen.

Jag har för övrigt just skickat mail till kundtjänst med förslag på förbättringar, däribland det du nämnde.

/J

Lite mer PKI-problem att fundera på:

Alice får ett certifikat utgivet av CAn Bob från någon som påstår sig vara Charlie. Hur ska Alice kunna veta att/hur Bob verifierat Charlies identitet innan Bob skapat ett certifikat åt den som påstår sig vara Charlie? Det finns, som jag ser det, två praktiska lösningar på detta problem:

1. Bob publicerar sin verifikationsregler på sin WWW-site och Alice läser dem där.

2. Bob publicerar sina verifikationsregler inbakat i de utgivna certifikaten.

Av dessa så sker 1 ibland i dag, medan jag inte sett 2 ske i dag. Båda har följande problem:

1. Alice måste på något sätt måste kunna läsa verifikationsreglerna. Tänk om Alice inte förstår språket reglerna är skrivna på? Tänk om Alice programvara inte stödjer utläsning av reglerna ur certifikat? Jag vet inte om 2 ens stöds i standarderna i dag.

2. Alice måste ta sig tid och ork att läsa verifikationsreglerna. Hur många människor kommer att göra detta i praktiken?

3. Om Alice läser reglerna så måste hon bilda sig en uppfattning om hur pålitliga de är i praktiken. Detta kan t.ex. medföra saker som att Alice måste ha detaljkunskaper om posthanteringen eller ID-handlingssystemen i ett visst land, för att kunna avgöra hur säkra dessa är.

Nästa problem uppstår när Alice ska avgöra om det går att lita på Bob. Certifikat handlar i grund och botten om att koppla samman en identitet och en publik nyckel. CAns uppgift är att agera betrodd mellanhand som utför denna koppling. Frågan är då hur mycket CAn är beredda att lägga bakom sitt ord om att en viss specifik koppling mellan en identitet och en publik nyckel är korrekt? Ingen CA jag känner till tar något som helst ekonomiskt ansvar för eventuella felaktiga identitet<->nyckel kopplingar den gjort. Detta är lite intressant eftersom det är just själva pålitligheten i kopplingen som CAn egentligen tar betalt för. Så vad alla CAs i dag säger är: "Betala oss för att vi garanterar en korrekt koppling mellan en identitet och en publik nyckel. Men vi tar absolut inget som helst ansvar för att denna koppling är korrekt." Motsägelsefullt? Det enda CAn förlorar vid en felakktig koppling som blir känd är en del av sitt anseende, vilket i och för sig inte är helt obetydligt med tanke på vad branschen ifråga livnär sig på.

Edit: Säg att CAn Bob upptäcker att den gett ut ett felaktigt certifikat i Charlies namn, och inkluderar detta i sin CRL. Alice ska till att använda dettta certifikat, och hennes programvara ska nu se om certifikatet finns med i CRLen som publicerats av Bob. Vad händer nu om den som lurat till sig det felaktiga certifikatet utsätter Bobs CRL-publiceringstjänst (eller varför inte Alice sida) för en DoS (Denial of Service) attack, så att Alice inte kan se om certifikatet finns med i CRLen? Kommer den helt vanliga personen Alice i praktiken ändå att använda certifikatet?

Mindre detalj... det jag väntar på är då folk börjar lämna sina kort i läsarna när de går på lunch/fika... eller börjar låna varandras kort och berättar vilket PIN man har för det.

/J

Jag väntar på första rättsfallet där någon hävdar att en digital signatur är förfalskad. Man får inte glömma att bara för att min privata nyckel signerat något, så betyder det inte att jag gjort signaturen. Det betyder bara att någon med tillgång till min privata nyckel gjort signaturen. Exemplet du nämner är ett bra argument mot "multikort", vilka i ett kort kombinerar flera olika funktioner, som t.ex. passerkort, betalkort, telefonkort och nyckellagringskort.