”Mystisk” PIN-dialog i Net iD

Problemet löst i kommande Net iD 6.0. Se information på slutet av artikeln under rubriken ”Tänkbara lösningar”

Det finns några speciella scenarion där Net iD 5.x ger en ”mystisk” PIN-dialog som är ett slags blandning av den vanliga PIN-dialogen vid inloggning och den dialog som ges när man skriver under (signerar). Visst är de förvillande lika? Skillnaden är vilket certifikat som används och därmed vilken nyckel och således olika PIN-koder. Det enda som berättar att det är PIN1 som ska användas i bilden till vänster, och inte PIN2 som man kan förledas att tro, är texten: ”SITHS-kort (inloggning)”.

Bild 1.

PIN_sidebyside

Skälet till att denna ”hybrid” uppstår är att Net iD inte i alla lägen kan programmatiskt avgöra vad syftet med en viss operation är. Det innebär dock ingen säkerhetsrisk. Men det betyder förstås inte att det är oviktigt.

Det finns tre olika tillfällen då man kan se denna något missvisande dialog

1) Vid signering av e-post

e-postsignering sker med inloggningscertifikatet och därmed PIN1. (Inte med signeringscertifikatet som många tror)Tekniskt sett är det dock en signeringsoperation. I detta fall blir dialogen bedräglig på ett omvänt sätt mot ovanstående exempel. Här är det ju i ett ”signering-kontext” som det hela sker. Men det gäller att vara observant och ange PIN1, inte PIN2.

Notera att man INTE bör signera e-post med underskriftcertifikatet även om man lätt kan tro det. e-postsignering skall inte ses som en avtalsliknande operation. Särskilt inte signerade automatiska mottagningskvittenser som definitivt inte ska ses som att man accepterar ett översänt avtal.

2) PDF-signering med fel” certifikat

Man kan även få denna ”hybriddialog” när man signerar PDF-filer med inloggningscertifikatet. Vilket man förstås INTE bör göra då PDF-signering ofta handlar om att signera i syfte att frysa t.ex. en avtalstext eller annan viljeyttring. Här bör PDF-filen med hjälp av Adobe LifeCycle Desigen skapas på så vis att endast certifikat med KeyUsage satt till ”NonRepudiation (40)” kan användas för att skapa signaturer. På så vis blir PIN-dialogen automatiskt korrekt i alla avseenden.

3) Egenbyggd inloggningslogik

Det tredje scenariot där denna dialog kan dyka upp är när man i en Windows-applikation skriver sin egen inloggningslogik, eller ”ärver” den från Microsofts ramverk, som bygger på att Net iD ombeds signera ett hashvärde baserat på CALG_SHA1 istället för CALG_SSL3_SHAMD5.

Men innan vi utvecklar problemställningen ner på algoritmnivå måste frågan ställas

– Varför har Net iD olika dialoger för inloggning respektive underskrift?

Svaret är att vi vill bidra till att, utöver det grundapplikationen ger, tydligt visualisera skillnaden mellan inloggning och underskrift då underskrifter kan får rättsverkan på ett sätt som rena inloggningar sällan (aldrig) kan få. En underskrift kan röra ett avtal, ett intygande eller annan särskilt viktig transaktion.

Vi är heller inte ensamma om detta. Se här hur BankID visualiserar skillnaden

Bild 2.

bankid

Men det finns andra som valt en helt generisk PIN-dialog. T.ex. Microsoft:

Bild 3.

MS-PIN

Förutom att Microsofts dialog lämnar en del övrigt att önska rent språkligt (”provider”?) så lämnar man helt över till den applikation, som initierat det flöde som gör att PIN-dialogen visas, att förvissa användaren om vad det är frågan om.

Vi har här en skillnad, grovt tillyxat, mellan europeisk real-PKI och transatlantisk tillämpning. Det är tämligen vanligt i Europa att separera inloggning från underskrift genom att ha separata nycklar/certifikat/PIN för de två operationerna. Detta är dock inte platsen att vidare beskriva denna ”kulturskillnad”.

Nåväl, är metoden med separata PIN-dialoger (t.ex. Net iD/BankID) eller en generisk (t.ex. Microsoft) rätt?

Jag är böjd att svara att separata är ”rätt”. Trots att ovanstående dialog är uppenbart missvisande. Följ med nedan på en djupare teknisk förklaring och några skisser på möjliga lösningar.

Internet Explorer och TLS/SSL

Vi börjar med det uppenbara: Internet Explorer gör en TLS/SSL-förhandling mot en webbserver. Detta om något kommer att innebära att en challenge (hashvärde) kommer att behöva signeras med hjälp av kortet privata nyckel. ”Signeras” i syfte att göra en handskakning som en del i autentiseringen (inloggningen/legitimerandet).

I Net iDs tracefil kan vi se det hashvärde som ska signeras. 36 bytes ska det tydligen vara frågan om.

Bild 4.

36bytesSSLBlob_in_NetiDtrace

Kikar vi på raderna strax innan själv hashvärdet hittar vi detta:

Bild 5.

CALG_SSL3_SHAMD5

32776 omvandlat till HEX blir 0x00008008 och en titt på Microsofts algoritmförteckning ger oss informationen att detta är frågan om en CALG_SSL3_SHAMD5. Dvs. 36 bytes i form av en bytesekvens av 16 bytes med md5-hash samt 20 bytes med sha1-hash. (När man signerar md5 eller sha1 så skickar signerar man paketerad digest i en så kallad digest info som berättar vad det är frågan om, medan man för TLS/SSL signerar en blob)

Bild 6.

ms_CALG_SSL3_SHAMD5

Varför Microsoft inte vill att man använder CALG_SSL3_SHAMD5 i applikationer vet jag inte…
Men här är deras instruktion hur man gör ifall att man trots denna rekommendation vill skapa en egen CALG_SSL3_SHAMD5 hash:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa379865(v=vs.85).aspx

Jämför dessa:

MD5 Digest Info
30 20
30 0c
06 08
2a 86 48 86 f7 0d 02 05 // Object id för MD5
05 00
04 10
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX

SHA-1 Digest Info
30 21
30 09
06 05
2b 0e 03 02 1a // Object id för SHA-1
05 00
04 14
YY YY YY YY YY YY YY YY YY YY YY YY YY YY YY YY YY YY YY YY

SSL Blob
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
YY YY YY YY YY YY YY YY YY YY YY YY YY YY YY YY YY YY YY YY

Det vill säga, Net iD har en särskild hantering av algoritmen CALG_SSL3_SHAMD5. Trots att det rent tekniskt sett kan sägas vara som vilken signatur som helst så specialbehandlas just denna algoritm och skickar upp dialogen som nyttjar SAMSET:s språkbruk för inloggningar.

Bild 7.

ex_IE

Adobe Reader och en PDF-fil med ett avtal

Vi fortsätter med en annan form av signatur, en riktig signatur, utförd i akt och mening att teckna ett leveransavtal, begära personnummer till ett nyfött barn eller intyga på heder och samvete en uppgifts riktighet. Alltså, signatur med certifikatet som har KeyUsage satt till ”NonRepudiation (40)” och därmed PIN2.
I tracefilen ser vi:

Bild 8.

CALG_SHA1_trace_adobereader

Aha, inte längre ”Algoritm 32776” utan istället ”32772” som i HEX blir 0x00008004 och återigen kollar vi hos Microsoft:

Bild 9.

ms_CALG_SHA1

Ser man på, inte helt obekanta SHA1. Nåväl, inga problem med det, här var ju signaturen verkligen avsedd att skapas för att underteckna PDF-filen (PIN2). Dialogen nedan är alltså helt korrekt. Net iD behövde inte specialbehandla frågan som med CALG_SSL3_SHAMD5. Det hela var dock lätt att hantera då underskriften görs med ett nyckel som är av typen AT-SIGNATURE. hade det istället varit AT-KEYEXCHANGE hade det blivit fel liknande det beskrivet under kommande avsnitt;
”Applikation X (t.ex. ett Journalsystem)”

Bild 10.

ex_adobereader

Applikation X (t.ex. ett Journalsystem)

Nu blir det värre. Vi har nått fram till fall 3 som beskrevs i början, dvs en applikation med egen inloggningslogik eller logik baserad på t.ex. WCF. Det är nu det blir missvisande i Net iDs PIN-dialog. Vi har alltså att göra med enkelriktad SSL men klientautentisering på meddelandenivå:

Bild 11.

CALG_SHA1_netid60

Ovanstående exempelapplikation med både server- och clientside har jag fått från den eminente utvecklaren Jonas Forsberg som arbetar på ett företag som bygger just Journalsystem. Exempelapplikationen kör enbart ”Message security” medan hans skarpa applikation kör ”TransportWithMessageCredential” men det fungerar exakt likadant i båda fallen så relevansen är 100%.

I tracefilen ser vi:

Bild 12.

CALG_SHA1_trace_journalsystem

32772 igen, dvs. samma som i exemplet ovan med Adobe Reader och ett avtalstecknande. Återigen är det 0x00008004 och CALG_SHA1.

Vilket elände att inloggningen i ett Journalsystem ska bete sig likadant rent kryptografiskt som ett avtalstecknande i Adobe Reader. För håll med om att SHA-1 hashar rent programatiskt ser rätt lika ut. (Dessutom ganska apjobbigt att räkna baklänges för att se om det döljer sig ett slumptal eller ett avtal bakom hashvärdet)

Men HALLÅ, utbrister vän av ordning:
– Borde inte Net iD basera PIN-dialogens utseende på vilket certifikat som valts. Såhär alltså:
KeyUsage=Oavvislighet (40) => ”Jag skriver under”
KeyUsage= Digital signatur, Nyckelchiffrering (a0) => ”Jag legitimerar mig”

Bra invändning! Det kräver ett tydligt svar:

Om det vore så väl att vi kunde gå på KeyUsage i certifikaten!
– Tänk om ingen använde PKI på ”fel” sätt.
– Tänk om ingen satte fel KeyUsage i sina certifikat.

Nej, skämt åsido. Detta är en balansgång mellan att ”hålla alla dörrar öppna” och att ”tvinga alla in i den rätta tron”.

Problemet är att Net iD redan gör allt vi kan för att försöka lista ut vad det är som egentligen ”ska göras”.

För dekryptering/import/export/generering osv. är det egentligen inget problem, utan problemen uppstår vid skapande av signaturer.

Net iD får en begäran att signera ”data” med en privat nyckel som tillhör ett certifikat. Samma certifikat kan användas till många olika syften, så den signaturbegäran Net iD får kan vara allt från att signera ett mail eller ett dokument och i vissa fall även att signera en serverchallenge.

Det sistanämda är det som sker i ovanstående exempelapplikation och det är faktiskt det mest ovanliga, eftersom det vanliga beteendet är att man aldrig använder en normal digestalgoritm för detta, t.ex. SHA-1/SHA-2, utan istället används SHA1+MD5, dvs CALG_SSL3_SHAMD5 som i TLS/SSL.

Anledningen till att denna algoritm i princip alltid används och ingen av de andra är av säkerhetsskäl. En server som begär signatur av en challenge, skulle i princip kunna begära signatur av ett dokument i fallet att challenge är en normal digest. Alltså borde det i konsekvensens namn faktiskt står ”Underteckna” i dialogen när en server begär att du ska ”Underteckna en challenge”. Använder man CryptoAPI finns hög-nivå funktionen CryptSignMessage, och det första argumentet är en struktur PCRYPT_SIGN_MESSAGE_PARA och i den strukturen anges hash (digest) algorithm.

Alltså, vi vågar inte hårdkoda in vad vi anser vara korrekt användning av certifikat, det skulle kunna ta hus i helvete någonstans hos våra kunder som inte i alla lägen lever enligt svensk PKI-praxis till punkt och pricka.

(Eller svensk och svensk, vi kan väl säga som så att inte alla rattar PKI som de som skolats på ”iD2 Technologies”)

Var det ett OK svar? Om inte, maila mig dina tankar om detta! jonas.oholm@secmaker.com

Jo just det, troligen drabbar denna sak alla applikationer (inte webbapplikationer) som baseras på Ineras säkerhetstjänster, f.d. BIF. I skrivande stund finns inga stora mängder system som baseras på ”Säkerhetstjänsterna” så det är svårt att bedöma för en extern betraktare. NPÖ och Pascal är ju webbapplikationer som kör dubbelriktad TLS/SSL och därmed CALG_SSL3_SHAMD5.

Tänkbara lösningar

Edit:
Se f) nedan. Problemet hanterat från Net iD 6.0.

Utvecklare som bygger inloggningslösningar kan överväga att:

a)

Formatera sin challenge precis som om det rörde sig om en TLS/SSL-förhandling i en webbläsare. Net iD fungerar som vi sett ovan som så att just den sorts datastruktur som används vid TLS/SSL triggar den i sammanhanget ”rätta” PIN-dialogen.
(I fallet med Journalsystem X var det lättare sagt än gjort eftersom WCF inte alls tillhandahöll den möjligheten. Minns att MS inte ville att CALG_SSL3_SHAMD5 skulle användas i applikationer. (Spontant känns det som hål i huvet, men jag kanske förbiser nåt…?)

b)

I applikationens eget gränssnitt tillhandahålla ett fält för inmatning av PIN-kod där det kan står precis vad som helst.
De som inte utvecklar utan mer pysslar med att konfigurera eller beställa saker kan kan fundera på om man ska:

c)

Via Net iDs funktion [Dynamic Strings] ändra ordalydelserna i PIN-dialogerna så att ”allt täcks”
(Inte så bra förslag, det blir varken hackat eller malet)

d)

Sluta använda Net iDs CSP och bara köra MS Base CSP (med sin generiska PIN-dialog) och lämplig Minidriver (Net iD)
(Intressant förslag men kan i praktiken kräva att MS Base CSP kan behöva en tillputsning avseende t.ex. multipla PIN-koder och PINPAD. Jo, Minidriverspecifikationen medger upp till åtta PIN-koder men det är ännu inte implementerat i MS Base CSP)

e)

Kanske kunde Net iD kodas om så att man i konfigurationen kunde ange om en viss ”Calling application” kunde styra PIN-dialogens utseende? Tja, Net iD är ju inte omedveten om vem ”som vill oss något” redan idag:

[2384:2396] 00.00.00.000 Helper – Calling application: ‘C:\Program\Internet Explorer\iexplore.exe’
[4340:5860] 00.00.00.016 Helper – Calling application: ‘C:\Program Files (x86)\Adobe\Reader 10.0\Reader\AcroRd32.exe’
[6208:5164] 00.00.00.015 Helper – Calling application: ‘C:\Projects\Melior\MainDev\J\PROG\Debug\Melior.exe’
[0664:1860] 00.00.00.000 Helper – Calling application: ‘C:\WINDOWS\system32\winlogon.exe’

Typ såhär:
[Dialog]
Advanced=1
NoUserInterface=plugin-container.exe
AppsToAlwaysUsePIN1LanguageNoMatterHashAlgoritmUsed=melior.exe;klara.exe;app.exe;program.exe

AppsToAlwaysUsePIN1LanguageNoMatterHashAlgoritmUsed=melior.exe;klara.exe;app.exe;program.exe

f)

Eller så kommer vi på någon annan angreppsvinkel utan oacceptabla biverkningar….
Vilket vi alltså har gjort!

Vi valde att göra en justering som innebär att alla signaturbegäran med CALG_SHA1 (0x00008004) hanteras på så sätt att dialogen ”Öppna” används. Det hela är implementerat på så vis att det bara gäller för nycklar av typen AT-KEYEXCHANGE. Det är bra eftersom man även vid underskrift av t.ex. PDF-filer med nonrep-certifikat använder CALG_SHA1, men i det fallet är det en AT-SIGNATURE nyckel som används och då blir det rätt.
Vi ska se om det går att putsa lite till på dialogen så att det blir riktigt bra (utan att samtidigt påverkar andra sammanhang negativt)

CALG_SHA1

En positiv bieffekt är vid signering av PDF:er med nyckel som har AT-KEYEXCHANGE. Då kommer dialogen att använda ordet ”Öppna” istället för att bli lika bedräglig som ovan beskrivet.

ex_adobereader_netid60_side-by-side

Med utmärkt högaktning
/Jonas Öholm, Senior PKI Architect, SecMaker AB

P.S – Som om det inte vore nog…

Det finns faktiskt en variant på PIN-dialog i Net iD: Öppna
Den kommer väl till pass t.ex. när certifikat ska skrivas till kortet efter en lyckad enrollment. Då är det inte fråga om någon hash eller inloggning utan att helt enkelt ”Öppna” kortet för skrivning

netid_open