Timing-angreb i kode på applikationsniveau

Den almindelige operator til strenglighed i de fleste programmeringssprog afslutter, så snart der findes en uoverensstemmelse. Python's == på bytes-objekter, C's strcmp og Java's String.equals returnerer alle straks, når den første forskellige byte findes. Ved normal strengsammenligning er dette en optimering, men ved sammenligning af hemmelige værdier som MAC-tags eller adgangskoder skaber det en målbar tidsbaseret sidekanal, der lækker oplysninger.

En angriber måler den tid, det tager at sammenligne et indsendt HMAC-tag med den korrekte værdi. Det tager en smule længere tid at indsende et HMAC, hvor den første byte stemmer, end et hvor den første byte er forkert (én ekstra bytesammenligning). Ved at indsende mange værdier med hver mulig første byte og måle svartiderne kan angriberen identificere den korrekte første byte. Processen gentages byte for byte, indtil hele tagget er gendannet.

Moderne timingangreb over netværk kan skelne mellem tidsforskelle på ti til flere hundrede nanosekunder via internettet. En 32-byte HMAC-sammenligning, hvor hver korrekt byte tilføjer cirka 10-100 ns behandlingstid, giver et målbart signal, hvis der foretages tilstrækkeligt mange gentagne målinger til at udjævne netværksjitter. På et lokalt netværk kan selv forskelle på én nanosekund udnyttes med tilstrækkeligt mange statistiske målinger.

I Python er det usikkert at sammenligne MAC-tags med ==: if mac == submitted_mac returnerer True eller False afhængigt af placeringen af det første mismatch. En angriber, der indsender tusindvis af manipulerede tags og måler svartiderne, kan gendanne det forventede tag byte for byte. Denne sårbarhed har optrådt i webapplikationer i produktion, hvor sammenligning af sessionstokens eller API-nøgler fejlagtigt blev implementeret uden funktioner med konstant køretid.

Pythons hmac.compare_digest(a, b) sammenligner to byte- eller strengværdier med konstant køretid, så det tager lige lang tid, uanset hvor det første mismatch forekommer. Funktionen er implementeret i C for at sikre konstant køretid, selv når fortolkning af Pythons bytekode medfører ekstra omkostninger. Brug altid hmac.compare_digest til at sammenligne MAC-tags, sessionstokens, API-nøgler eller andre værdier, hvor timingoplysninger kan være farlige.

OpenSSL leverer CRYPTO_memcmp(a, b, length) til hukommelsessammenligning med konstant køretid. I modsætning til memcmp behandler den altid alle length-byte, uanset om der opstår et tidligt mismatch. Returværdien er nul, hvis værdierne er ens, og ikke-nul, hvis de er forskellige. Det er vigtigt altid at sammenligne den fulde forventede længde: Hvis værdier med forskellig længde sammenlignes ud fra den korteste længde, kan der stadig lækkes oplysninger om længden. Brug CRYPTO_memcmp i alle sikkerhedskritiske sammenligninger i C/C++-kode, der bruger OpenSSL.

Timingangreb rækker længere end strengsammenligning. Bleichenbachers angreb fra 2006 på RSA PKCS#1 v1.5-dekryptering viste et praktisk timingorakel mod SSL/TLS-implementeringer. Tiden for RSA-operationen med den private nøgle varierede afhængigt af, om den dekrypterede værdi havde gyldig PKCS#1-padding. Ved at indsende tusindvis af manipulerede chiffertekster kunne angribere gendanne private RSA-nøgler. Det førte til RSA-OAEP og RSA-implementeringer med konstant køretid.

AES-implementeringer, der bruger opslagstabeller (almindeligt af hensyn til ydeevnen), tilgår forskellige tabelposter afhængigt af nøglen og klarteksten. Cache-træf og cache-fejl skaber målbare tidsforskelle, som lækker oplysninger om, hvilke tabelposter der blev tilgået. Denne sidekanal kan afsløre AES-nøgler. Forsvaret er at bruge AES-implementeringer, der ikke er afhængige af opslag i tabeller, f.eks. AES-NI-hardwareinstruktioner eller bitopdelte softwareimplementeringer.

Skrivning af kode med konstant køretid kræver, at du undgår betingede forgreninger baseret på hemmelige data (brug forgreningsfri udvælgelse med maskering), hukommelsesadgangsmønstre, der afhænger af hemmelige data (undgå opslagstabeller indekseret med hemmeligheder), samt operationer, hvis latenstid afhænger af hemmelige værdier (f.eks. division på visse processorer). Kompilatorer kan optimere konstruktioner med konstant køretid væk, så assemblerkode eller volatile-hukommelsesadgange kan være nødvendige i kritiske sektioner.

Det bedste forsvar mod timingangreb på MAC-sammenligning er at bruge AEAD-tilstande (GCM, ChaCha20-Poly1305) og overlade MAC-verificeringen til det kryptografiske bibliotek. Biblioteksimplementeringer udfører selv verificering med konstant køretid. Hvis du bruger AEAD korrekt (dekrypteringen mislykkes ved enhver manipulation, og du dekrypterer aldrig før tagget er verificeret), behøver du aldrig sammenligne MAC-tags i applikationskode, hvilket helt fjerner timing-sårbarheden.

Test af timing-sårbarheder kræver statistisk analyse af fordelinger af svartider. Værktøjer som tlsfuzzer, testscripts til timingangreb og dudect-frameworket hjælper med at opdage tidsforskelle i kryptografiske implementeringer. En t-test af stikprøver af svartider for input, der burde give samme timing, kan afsløre statistisk signifikante forskelle. Falske negative resultater er mulige; en kodegennemgang med fokus på konstant køretid er også vigtig sammen med test.

Opsummering af timingangreb: Strengsammenligning med tidlig afslutning lækker hemmelige værdier byte for byte via forskelle i svartider; det kan måles over et netværk med tilstrækkeligt mange målinger; brug hmac.compare_digest i Python og CRYPTO_memcmp i OpenSSL til sammenligning med konstant køretid; timingangreb på RSA-padding kan kompromittere private nøgler (brug RSA med konstant køretid og OAEP); timingangreb på opslagstabeller i AES lækker nøglebits (brug AES-NI eller bitopdelte implementeringer); og bibliotekernes AEAD-verificering eliminerer behovet for sammenligning af MAC-tags på applikationsniveau.