Krypto och säkerhet i en övervakad värld

Uppdaterad 2013-09-13 om CryptoAPI.

Efter nattens nya avslöjanden om NSAs avlyssning har det kommit mycket frågor om vad som stämmer, vad som kan vara knäckt, vad man kan lita på och hur man kan skydda sig.

Eftersom det trots alla avslöjanden saknas mycket konkret information om vilka algoritmer, protokoll, produkter och tjänster som på olika sätt är svagare än förväntat är det fortfarande klart förvirrande. Men jag tycker att den analys och de rekommendationer som Bruce Schneier publicerat är bra.

En av de stora frågorna är huruvida SSL/TLS faktiskt är säkert. Forskaren Matthew Green har publicerat en bra analys väl värd att läsa. Han och Bruce är relativt samstämmiga i att algoritmerna, inte minst AES är bra. Även om NSA har kryptologer som hittar sätt att reducera styrkan hos AES med ett antal bitar är det inte det som är det konkreta problemet (det är faktiskt det dom förväntas arbeta med).

Nej problemet är att man nu säger att man på olika sätt attackerar implementationerna av ex SSL/TLS. Antingen hittar svagheter som sedan utnyttjas eller mer tveksamt tvingar leverantörerna att införa svagheter. Det vill säga man avsiktligt gör oss alla mer sårbara än nödvändigt, för dessa sårbarheter kan hittas och utnyttjas inte bara av NSA och deras kompisar.

De vanligaste implementationerna av SSL är troligen Microsofts CryptoAPI samt OpenSSL. Den första är stängd för granskning kräver avtal för att få rätt att granska koden och kan därför inte ges samma tilltro som en öppen och fri lösning där alla när som helst kan granska, modifiera, bygga och sedan kommunicera sina observationer och erfarenheter.

OpenSSL är öppen kod, men har en historik med mycket svagheter (som dock högst troligt inte är avsiktliga) vilket visar att säkerheten och tilliten inte med nödvändighet är fantastiskt bara för att koden är öppen. Men just nu är OpenSSL, GnuTLS, Nettle, Sodium och liknande öppna bibliotek antagligen det bästa vi kan använda.

Vad gäller hårdvara är det svårare. Vi kan nog utgå ifrån att en normal processor generellt utför sina beräkningar på ett korrekt och förväntat sätt. Även instruktioner för kryptoacceleration som Intels AES-NI ger verifierbart korrekt kryptering och dekryptering. Däremot vet man inte vad som faktiskt sker med nyckeln som används förutom det förväntade beteendet.

Än mer problematiskt blir det med inbyggda slumptalsgeneratorer som Intels nya RdRand (Bull Mountain). Den går knappast i dagsläget att lita på och använda direkt för nyckelgenerering. Att använda RdRand som en av flera entropikällor som sedan matar en PRNG man litar på bör fortsatt kunna fungera.

En intressant sak som kom fram i natt var att misstankarna om bakdörren i NISTs slumptalsgenerator Dual_EC_DBRG antagligen bekräftades. Detta visar vikten av att standarder utvecklas i en öppen process och att alla detaljer in en specifikation går att härleda. Det är bland annat därför det Kinesiska strömkryptot för mobilsystem ZUC är svårt att lita på eftersom det innehåller konstanter och detaljer som inte går att härleda.

Det enkla vi kan göra är att använda öppna implementationer av algoritmer som tagits fram i en öppen process. Och kan vi välja en längre nyckel så gör det. Det kostar väldigt lite för dig som användare men gör det mycket svårare för motståndaren oavsett vem det är. Och tänk igenom på vilka verktyg du använder för att generera och lagra nycklar. Att använda 1024 bitars RSA-nycklar för egen kommunikation eller i certifikat känns i dag som fel.

Avslutar med ännu en länk. Denna gången till en chatt med säkerhetsexperten Jakob Schlyter på Kirei som tänker bra och klokt.

10 reaktioner på ”Krypto och säkerhet i en övervakad värld

  1. Matt Green verkar inte alldeles förtjust i OpenSSL :) ”Unfortunately while OpenSSL is open source, it periodically coughs up vulnerabilities. Part of this is due to the fact that it’s a patchwork nightmare originally developed by a novice who thought it would be a fun way to learn C.”

    Har du någon uppfattning om koden i NaCL eller Sodium har bättre kvalitet och mindre buggar? Är det mogna bibliotek?

  2. Hehe, det var en bra rant. Vad tror du om Apples API:er till telefoner och annat då? Lågnivåfunktioner som de i Common Crypto går ju att verifiera med andra verktyg. Det borde väl vara ”säkert” att använda dem. Eller ska man oroa sig för saker som t.ex. att en kopia av nyckeln sparas undan någonstans utan användarens vetskap?

  3. Problemet som jag ser det är inte att verifiera att funktionerna gör rätt, utan att verifiera att dom inte dessutom gör något annat. I det här läget är det iaf för mig svårt att sätta mycket tillit till icke-öppna lösningar.

  4. Pingback: iNSAne | Arkeoblog
  5. Hej, din sista mening där. RSA verkar ju tveksamt idag, men tycker du vi satsa på längre nycklar än 1024 bitar?

  6. Jag anser inte att RSA som sådan är tveksam. Problemet med RSA är att säkerheten skalar långsamt med nyckellängden. Ja, jag tycker att använda RSA-nycklar på 1024 bitar år 2013 är fel. De allra flesta system stödjer minst 2048 bitar.

    Alternativ till RSA är ex ECC. ECC skalar mycket bättre säkerhetsmässigt med nyckellängden. Problemet med ECC (och varför ECC är det man i dag är tveksam till) är att ECC är standardiserat med några stycken specifika kurvor. Hur dessa kurvor valts är inte öppet och spårbart. Det finns öppna kurvor som DJB:s Curve25519. Men dessa finns inte med i certifikat, TLS etc.

Kommentera

E-postadressen publiceras inte. Obligatoriska fält är märkta *