Tidsattacker i kod på applikationsnivå

Den vanliga operatorn för stränglikhet i de flesta programmeringsspråk avslutas så snart en skillnad hittas. Pythons == för bytes-objekt, C:s strcmp och Javas String.equals returnerar alla omedelbart när den första avvikande byten hittas. Vid normal strängjämförelse är detta en optimering, men vid jämförelse av hemliga värden som MAC-taggar eller lösenord skapar det en mätbar tidsbaserad sidokanal som läcker information.

En angripare mäter tiden det tar att jämföra en inskickad HMAC-tagg med det korrekta värdet. Att skicka in en HMAC där den första byten stämmer tar lite längre tid än en där den första byten är fel (en extra bytejämförelse). Genom att skicka in många värden med varje möjlig första byte och mäta svarstiderna kan angriparen identifiera den korrekta första byten. Processen upprepas byte för byte tills hela taggen har återställts.

Moderna tidsattacker över nätverk kan upplösa tidsskillnader på tiotals till hundratals nanosekunder över internet. En jämförelse av en HMAC på 32 byte, där varje korrekt byte lägger till cirka 10–100 ns bearbetningstid, ger en mätbar signal om tillräckligt många mätningar upprepas för att jämna ut nätverksjitter. I ett lokalt nätverk kan även skillnader på enstaka nanosekunder utnyttjas med tillräckligt många statistiska mätningar.

I Python är det osäkert att jämföra MAC-taggar med ==: uttrycket mac == submitted_mac ger True eller False beroende på var den första skillnaden finns. En angripare som skickar in tusentals specialanpassade taggar och mäter svarstiderna kan återställa den förväntade taggen byte för byte. Denna sårbarhet har förekommit i produktionssatta webbapplikationer som felaktigt implementerat jämförelser av sessionstoken eller API-nycklar utan konstanttidsfunktioner.

Python-funktionen hmac.compare_digest(a, b) jämför två bytes- eller strängvärden på konstant tid och tar lika lång tid oavsett var den första skillnaden finns. Den är implementerad i C för att säkerställa konstant tidsåtgång även med den extra overhead som tolkning av Python-bytecode medför. Använd alltid hmac.compare_digest när MAC-taggar, sessionstoken, API-nycklar eller andra värden där tidsinformation kan vara farlig ska jämföras.

OpenSSL tillhandahåller CRYPTO_memcmp(a, b, length) för jämförelse av minnesinnehåll på konstant tid. Till skillnad från memcmp bearbetar den alltid alla byte som anges av length, oavsett tidiga skillnader. Returvärdet är noll om värdena är lika och ett värde som inte är noll om de skiljer sig åt. Det är viktigt att alltid jämföra hela den förväntade längden: att jämföra värden med olika längd upp till den kortare längden kan fortfarande läcka längdinformation. Använd CRYPTO_memcmp i alla säkerhetskritiska jämförelser i C/C++-kod som använder OpenSSL.

Tidsattacker sträcker sig längre än till strängjämförelser. Bleichenbachers attack från 2006 mot RSA PKCS#1 v1.5-dekryptering visade en praktiskt användbar tidsbaserad oracle mot SSL/TLS-implementationer. Tidsåtgången för RSA:s privata nyckeloperation varierade beroende på om det dekrypterade värdet hade giltig PKCS#1-padding. Genom att skicka in tusentals specialanpassade chiffertexter kunde angripare återställa RSA:s privata nycklar. Detta motiverade RSA-OAEP och RSA-implementationer med konstant tidsåtgång.

AES-implementationer som använder uppslagstabeller, vilket är vanligt av prestandaskäl, kommer åt olika tabellposter beroende på nyckeln och klartexten. Cacheträffar och cachemissar skapar mätbara tidsskillnader som läcker information om vilka tabellposter som användes. Denna sidokanal kan avslöja AES-nycklar. Försvaret är att använda AES-implementationer som inte förlitar sig på uppslagstabeller, till exempel AES-NI-maskininstruktioner eller bitslice-baserade programvaruimplementationer.

Att skriva kod med konstant tidsåtgång kräver att ni undviker villkorliga förgreningar baserade på hemliga data (använd grenlös selektering med maskning), minnesåtkomstmönster som beror på hemliga data (undvik uppslagstabeller som indexeras med hemligheter) och operationer vars latens beror på hemliga värden (till exempel division på vissa processorer). Kompilatorer kan optimera bort konstruktioner med konstant tidsåtgång, så assemblerkod eller volatile-minnesåtkomster kan behövas i kritiska kodavsnitt.

Det bästa skyddet mot tidsattacker vid MAC-jämförelse är att använda AEAD-lägen (GCM, ChaCha20-Poly1305) och överlåta MAC-verifieringen till kryptobiblioteket. Biblioteksimplementationer utför verifieringen med konstant tidsåtgång internt. Om AEAD används korrekt (dekryptering misslyckas vid all manipulering och dekryptera aldrig innan taggen har verifierats) behöver ni aldrig jämföra MAC-taggar i applikationskod, vilket helt eliminerar tidsbaserade sårbarheter.

Testning av tidsbaserade sårbarheter kräver statistisk analys av fördelningar av svarstider. Verktyg som tlsfuzzer, skript för testning av tidsattacker och ramverket dudect hjälper till att upptäcka tidsskillnader i kryptografiska implementationer. Ett t-test av stickprov av svarstider för indata som borde ge samma tidsåtgång kan avslöja statistiskt signifikanta skillnader. Falska negativa resultat är möjliga; granskning av kod med konstant tidsåtgång är därför också nödvändig tillsammans med testning.

Sammanfattning av tidsattacker: strängjämförelser som avslutas tidigt läcker hemliga värden byte för byte genom skillnader i svarstid, vilket kan mätas över nätverk med tillräckligt många mätningar; använd hmac.compare_digest i Python och CRYPTO_memcmp i OpenSSL för jämförelser med konstant tidsåtgång; tidsattacker mot RSA-padding kan kompromettera privata nycklar (använd RSA med konstant tidsåtgång och OAEP); tidsattacker mot AES-uppslagstabeller läcker nyckelbitar (använd AES-NI eller bitslice-implementationer); verifiering i AEAD-bibliotek eliminerar behovet av MAC-jämförelser på applikationsnivå.