Utökat skydd för WWW betalningar

Detta dokument beskriver en enkel metod att åstadkomma förstärkt förändringsskydd för betalningstransaktioner över Internet, som inte kräver särskild säkerhetsdosa eller kryptoprogramvara. Metoden blir på detta sätt mycket billig, och fungerar på alla plattformar som supportas av Netscape och MS Internet Explorer.

Styrkan i metoden är måttlig, vilket gör att den måste kombineras med andra riskbegränsande åtgärder för att vara effektiv. Men tillsammans med beloppsbegränsningar och befintliga skyddsmekanismer kan metoden utgöra ett fullgott skydd för sitt syfte.

Denna metod syftar inte till att ersätta riktigt starka skyddmetoder baserade på SmartCard teknologi, utan snarare till att överbrygga gapet i tid tills dess att SmartCard läsare är allmänt tillgängliga för bankens Internet kunder.

Bakgrund

Bankens nuvarande Internet applikation har stöd för insynsskydd och autentisering. Insynsskyddet åstadkoms genom kryptoprotokollet SSL, som i sin tur använder RSA och DES kryptering med 40 bit hemliga nycklar. Autentiseringen är baserad på engångskoder som distribueras till alla Nordbanken Direkt kunder, tillsammans med krypterade kakor som lagras i användarens browser. Kakornas kryptering är oberoende av och mycket starkare än SSL krypteringen.

Däremot finns fn inget direkt stöd för förändringsskydd eller återspelnings skydd, vilket behövs för att kunna genomföra betalningar från en WWW sida. Avsikten är att det inte ska vara möjligt att förändra en transaktion under transport från användaren till bankens system utan att vi upptäcker det. Det är dessutom bra om vi kan hindra transaktioner från att upprepas, och om vi kan få in en tydlig avsiktsförklaring i transaktionen: dvs, man ska inte kunna 'råka' skicka in en betalnings transaktion utan att verkligen ha avsikten att göra det.

Våra konkurrenter använder vanligtvis en säkerhetsdosa av något slag, antingen en challenge-response räknare eller en automatisk engångskodsgenerator. De koder som dosan genereras knyts till den pågående transaktionen på ett sätt som kan kontrolleras vid ankomsten till servern, vilket gör att förändringar längs med vägen kan upptäckas. Men hanteringen kring dosor är opraktisk, och representerar en betydande kostnad. För användaren är dosan ett svårhanterat bihang som försämrar användargränssnittet. Det blir många siffror som skall tryckas in, läsas av och matas in i formuläret.

En bra lösning skulle ge oss möjligheten att knyta information som bara en enskild kund kan veta om, till en pågående transaktion. För att åstadkomma detta krävs ett visst mått av beräkningar, och det är där som säkerhetsdosorna brukar komma in. Att bara ta in en engångskod räcker inte, eftersom dess information då inte är knuten till den pågående transaktionen. Vi behöver arrangera så att transaktionen bara kan genomföras om hemligheten som kunder ska känna till stämmer, och övriga fält stämmer mot någon sorts kontrolltal. Vi vill helst att beräkning av kontrolltal och knytning mot kundhemligheten ska kunna utföras utan separat utrustning eller installation av separat programvara.

Lösningen är att implementera den funktionalitet som vi kan finna i säkerhetsdosan i ett stycke programkod som kan köras i kundens browser. Med hjälp av programspråket JavaScript kan vi skriva rutiner som räknar fram kontrolltal utifrån pågående transaktion, och kombinerar detta med kundens hemlighet. JavaScript program skickas från bankens Internet server tillsammans med formuläret, och exekveras automatiskt vid ankomst till browsern.

Procedurbeskrivning

Proceduren för att skapa en signerad betalning genom ett WWW formulär är som följer:

1. Servern skickar ett formulär med inmatningsfält för
   • Mottagarkonto
   • Belopp
   • Kommentar
   Dessutom ingår ett dolt fält med ett tumavtryck, en sträng vars värde är beroende av ett sessions-id (klientens ip adress och portnummer) och en tidstämpel.

2. Låt användaren fylla i formuläret och signalera att han är klar genom att trycka på knappen "Skicka".

3. Beräkna en hash total på hela betalningstransaktionen.

4. Ta in personnummer, PIN och en engångskod från användaren.

5. Personnummer, PIN, engångskod och serverns tumavtryck krypteras genom en enkel kryptofunktion (XOR, till exempel) med hashtotalen som nyckel.
   Detta bildar en transaktionssignatur.

6. Klienten skickar nu in betalningsstransaktionen tillsammans med transaktionssignaturen till servern.

7. Servern räknar fram en hashtotal på betalningstransaktionen och använder den för att dekryptera transaktionssignaturen.

8. Tumavtrycket verifieras. Det ska vara både korrekt och oanvänt.

9. Transaktionssignaturens personnummer verifieras mot kakan.

10. PIN och engångskod verifieras mot IMS.

11. Stämmer allting så genomförs betalningen, annars avvisas den.

Motiveringar

Varför hashberäkning ?


Vi vill få fram en sträng med en fix längd som vi kan använda som nyckel i en krypteringsoperation i nästa steg. Beräkningen av en hashtotal syftar till att skapa en sträng med en fix längd, vars innehåll beror på alla relevanta tecken i transaktionen. Om vi bara använde transaktionsposterna som de är skulle endera längden variera beroende på antalet betalningar, eller så skulle vi få stora sjok med blanktecken i nyckeln.

Varför tumavtryck ?


Vi vill binda transaktionen i tiden, och upptäcka ett enkelt återspelnings försök. Med tumavtrycket kan vi dessutom visa upp en transaktions referens för kunden i samband med att den sker, vilken kunden sedan kan använda för att referera till den vid eventuella problemsituationer.

Varför ta in en engångskod ?


Vi vill vara säkra på kundens avsikt, och genom att kräva en engångskod blir det omöjligt att lura en legitim kund till att göra en överföring som han inte är medveten om. Engångskoden förutsätter dessutom tillgång till en kodkarta som är knuten till kontot, vilket ytterligare bekräftar autentiseringen och försvårar gissning. Det räcker med en engångskod för att uppnå detta, och för den som gör en betalning per månad räcker då den vanliga kodkartan i drygt två år.

Varför en så svag kryptering som XOR ?


Avsikten är inte i första hand att insysnskydda de uppgifter som lämnas av kunden, det sköter det underliggande SSL kryptot om. Avsikten är snarare att kombinera hashtotal och kunduppgifter så att de beror av varandra, och så att en eventuell modifikation av kryptodatat i överföringen påverkar båda. XOR uppfyller kraven, och är enkelt att implementera i klienten.
Om vi vänder på ordningen och tar in personnummer, PIN och engångskod innan betalningstransaktionen är färdig så skulle vi lika gärna kunna låta alltihopa ingå i hashberäkningen och hoppa över XOR steget. Det skulle dock bli opraktiskt ur användarperspektiv.

Räcker det här då ?


Inte i sig självt. Men givet att denna metod kombineras med ett antal andra säkerhetsmått så kan vi tänkas uppnå en tillfredsställande säkerhetsnivå, något som en separat riskbedömning måste ta ställning till. De faktorer som arbetar i kombination med denna metod är

• Hård autentisering genom kakor. Kakan måste vara giltig under en betalningstransaktion, vilket förutsätter att användaren måste känna till PIN kod och ha tillgång till endera engångskoder eller browser med befintlig kaka.
• SSL kryptering. Transaktionen är insynsskyddad genom nätverket.
• Spårbarhet. Transaktionen loggas på applikationsnivå av såväl WWW servern, applikationen i Unix miljö och applikationen i IMS miljö. IMS transaktionen QU0001 som anropas för att verifiera PIN och engångskoder håller en egen databas med anrop, och kan användas för såväl uppföljning som avgränsning eller utspärrning.
• Beloppsbegränsning. Förslagsvis 20.000:- per betalning, och 50.000:- totalt under en månad.

Genomförande

En praktisk implementation av denna skyddmekanism kräver uppskattningsvis tre manveckors arbete. Resurserna som behövs är en erfaren JavaScript programmerare, en erfaren Unix systemprogrammerare och en samordnare.

Det vore möjligt att få fram testbara resultat på två kalenderveckor, om övrig arbetsbelastning medger det.