Del 3: Krypto i praktiken

Den här delen handlar om praktiska detaljer kring att använda krypto som verktyg i praktiken.

 

3.1 Mål med krypto

Det finns fyra mål med kryptering som man oftast brukar prata om: integritet, korrekthet, autenticitet och oförnekelsebarhet. Dessa fyra nivåer utgör en sorts skala på krav i stigande ordning som kan ställas på ett kryptosystem (eg. framförallt system för kommunikation). Integritet innebär att utomstående inte kan läsa informationen och är således det enklaste kravet att uppfylla för ett kryptosystem. Korrekthet innebär att information inte har kunnat ändrats av någon utomstående. Det har visat sig att om man vill kryptera information vill man antagligen också vara säker på att informationen inte har ändrats under hantering/överföring. I moderna system idag använder man alltid metoder för att säkerställa korrekthet tillsammans med kryptering. I äldre protokoll kan skyddet vara bristfälligt. Autenticitet är ett lite högre krav och handlar om att säkerställa att sändaren av information är den man förväntar sig. Utöver att informationen inte har ändrats vill man dessutom vara säker att sändaren av informationen verkligen är den korrekta personen. Detta innebär att man måste kunna knyta användare till krypteringsnycklar, vilket ställer betydligt högre krav på system. Oförnekelsebarhet är det skarpaste kravet och handlar om att sändaren inte ska kunna förneka samband med informationen i efterhand. Detta kräver reglering av hur nycklar kan eller får lämnas vidare till tredje person och är ett ytterligare svårare krav att uppnå.

 

3.2 Säker kryptering

Det är mycket viktigt att förstå att det inte är kryptering i sig som når säkerhetsmålen, utan hur metoden används. Bara för att ett system använder sig av en viss typ av krypto betyder inte det per automatik att säkerhetsmålen uppnås. Krypto är bara ett verktyg som kan användas för att nå säkerhetsmål, dvs om krypteringen är implementerat korrekt och används på rätt sätt. Detta innefattar både krav på implementering av krypteringsalgoritmer, hur dessa används i system och protokoll, hur slumptal för krypteringsnycklar genereras, programvarusäkerhet, men också hur användarna använder kryptosystemen och vilka som har tillgång till krypteringsnycklar. Säker kryptering är alltså en bred process som innefattar många olika parter, både systemarkitekter, utvecklare, användare, systemtekniker och de som sätter säkerhetspolicys för användning.

Alla komponenter i ett kryptosystem, ända från algoritmens implementation till användarens beteende kan utgöra den svagaste länken i kedjan, och problemet är att en obehörig som försöker ta sig igenom krypteringen kan vara ihärdig och fortsätta försöka tills det lyckas (persistent attacks). För att få en säker kryptering och vara säker att alla försöken misslyckas måste därför hela kedjan vara minst lika stark.

 

3.3 Problem och risker med kryptering

I teorin är det lätt att skapa ett perfekt kryptosystem, men i praktiken finns det många fler aspekter som måste vägas in i designen av ett kryptosystem, vilket leder till system som många gånger designas svagare än vad de borde.

 

3.3.1 Lösenord

Ett av det absolut vanligaste problemet med kryptering är att lösenord används med för låg kvalité för att ge säker kryptering idag. Om ett dåligt lösenord används kan man knäcka krypteringen relativt enkelt. För system som använder lösenord för kryptering finns det många gånger färdiga program som kan laddas ned på internet för att knäcka lösenorden. Det är inte heller helt ovanligt idag att dessa program är betalprogram som erbjuds mot en kostnad.

En lista med samtliga lösenord som förekommit ur samtliga lösenordsläckor på internet de senaste åren (åtskilliga miljoner unika lösenord) kan testas på en vanlig PC på några få sekunder om ingen nyckelderiveringsalgoritm används (ex pbkdf2). Används en sådan algoritm beror tiden enbart på antalet iterationer i algoritmerna, men det är oftast bara en tidsfråga innan ett lösenord hittas.

 

3.3.2 Transportkryptering

Transportkryptering betyder att informationen krypteras från en nod under överföringen till nästa, och inte hela vägen till mottagaren. Detta är en vanlig metod för kryptering på internet idag där informationen kan överföras krypterat till mottagaren men samtidigt hanteras i klartext av flera mellanhänder under vägen. Det kan finnas olika orsaker till denna konstruktion, en kan vara att det oftast blir enklare eftersom de färdiga protokoll som är inbyggda i webbläsaren kan användas, en annan att mellanhänder kan ha kvav på sig att undersöka innehållet. Ett vanligt problem är att användare inte förstår skillnad mellan en helt krypterad anslutning och en anslutning som är krypterad flera delsträckor med olika nycklar som de inte själva kontrollerar.

 

3.3.3 Nyckeldeponering (key escrow)

En något sämre tillämpning av asymmetrisk krypto är att bygga in så kallade bakdörrar genom nyckeldeponering (key escrow). Ordet sämre använder jag eftersom deponeringen oftast inte är frivillig utan påtvingad av systemen. Exempelvis i system med symmetrisk kryptering som diskkryptering eller liknande. Syftet är oftast att göra det möjligt för rättsvårdande myndigheter att kunna ta del av informationen trotts att den är krypterad. En publik krypteringsnyckel distribueras och lagras i programvaran, sedan krypteras en kopia av lösenord eller krypteringsnycklar med denna nyckel och lagras tillsammans med den krypterade informationen. De som har tillgång till nyckelns privata motsvarighet kommer sedan kunna ta sig runt krypteringen, dvs oftast tillverkaren av systemet.

Ett problem med det här typen av bakdörrar är att det har visat sig mycket svårt att hålla den privata nyckeln till bakdörren hemlig, läcker nyckeln ut blir all kryptering med systemet värdelös. Samtidigt brukar företag förneka både existensen av dessa bakdörrar och tystar ned när det väl händer att dessa nycklar läcker ut på internet. Detta innebär därför ett extra risktagande för användarna av dessa system. En läckt nyckel tyvärr kan ej tas tillbaka igen, varpå skadan av ett lekage kan få katastrofala följder.

 

3.3.4 PKI & Falska certifikat

I teorin är ett PKI en väldigt bra lösning på problemet med MITM-attacker, men i praktiken har det visat sig att MITM-attacker är ett betydligt svårare problem att lösa än man först kunnat tro. Idag är falska certifikat ett ganska stort problem. Orsaken är att det ställs väldigt högra krav på ett CA för att ett PKI ska fungera bra. De allra flesta som vill ha en publik nyckel signerad via ett CA är helt legitima personer, vilket innebär att när det väl dyker upp ett försök att få en falsk nyckel signerad är det viktigt att stoppa detta försöket bland högen av helt legitima ansökningar, och antagligen utan att krångla till det allt för mycket för de legitima användarna. Dessutom måste man kunna stå emot de felaktiga försöken så pass exakt att flera upprepade försök kommer att misslyckas. Annars är en MITM-attack ändå möjlig att genomföra och det går att forcera kryptering eller förfalska signaturer. Detta har visat sig vara en mycket svår avvägning i praktiken som oftast väger över till kundernas nytta av att få ett certifikat enkelt. Ytterligare ett problem är att CA’t måste vara väldigt noga med sin egen säkerhet eftersom det har visat sig att intrång hos CA är en vanlig källa till falska CA och därmed forcerad kryptering eller förfalskade signaturer. Oftast består ett PKI av väldigt många olika CA, och som användare tvingas man oftast till att lita på samtliga CA för att PKI:et ska fungera bra.

 

3.3.5 Programvarusäkerhet & kvalité

Ett krypteringssystem är helt värdelöst om programmerarna som utvecklade systemet glömde kryptera informationen eller av misstag råkar använda samma krypteringsnyckel varje gång. Misstag som det här är dessvärre allt för vanliga. Det är också allt för vanligt att krypto implementeras fel så att de säkerhetsmål som har sats för ett system inte uppnås. Det blir därför omöjligt att separera kvalitetsaspekten från säker kryptering. För att vara säker på att programvaran använder krypto rätt måste det finnas rätt kompetens under utvecklingen för att göra denna typ av system och tid för att se över att allt är rätt och fungerar. Att implementera krypto är generellt sett väldigt svårt och det finns många fallgropar man kan gå ned sig i som programutvecklare om man inte vet vad man gör eller saknar kunskap om vad som kan gå fel. Det är därför viktigt hur krypteringssystemet är utvecklat och att man redan tidigt under utvecklingsprojektet avsatt den tid och de resurser som behövs för att systemet ska bli säkert.

 

Tillbaka till Krypteringsguiden.