Varning för hårdkodade nycklar

2017-10-25
Ett faktum som i kryptosammanhang torde vara lika självklart som att inte glömma bort att andas har visat sig vara faktum. Nämligen att man inte ska använda hårdkodade kryptonycklar.

Ett faktum som i kryptosammanhang torde vara lika självklart som att inte glömma bort att andas har visat sig vara faktum. Nämligen att man inte ska använda hårdkodade kryptonycklar.

Ett forskarteam från University of Pennsylvania och Johns Hopkins University har påvisat att ett antal tillverkare, i diverse kryptoimplementationer, visat det otroligt usla omdömet att dels använda PRNG:s baserade på ANSI X9.31 och som lök på laxen valt att hårdkoda seeds i källkod och/eller lagra dem i persistent minne. Detta är alltså de seeds som man stoppar in i sin PRNG för att få ut pseudoslumptal.

Bland tillverkarna som hittills avslöjats finns bland annat Fortinet, Cisco, BeCrypt, DeltaCrypt och TechGuard. Exempel på produkter som berörs inkluderar VPN-gateways, TLS-implementationer och FIPS 140-2-certifierad kryptomodul. Gällande FIPS 140-2-certifierade kryptomoduler bör man notera att dessa moduler har certifiering från innan 2016, innan NIST förbjöd användning av X9.31.

Utifrån detta faktum har man alltså förbestämt alla möjliga nycklar som överhuvudtaget kan genereras i berörda kryptoimplementationer eftersom en deterministisk PRNG alltid matar ur sig samma pseudoslumptal när man stoppar in samma seed. Genom att gräva ut dessa hårdkodade seeds genom att kika i källkod eller via reverseengineering av t.ex. FortiOS 4, firmware på berörda kryptomoduler eller berörda applikationer kan man alltså återskapa alla nycklar som är möjliga utifrån kombinationen av PRNG och de hårdkodade seeds:en.

Man har med andra ord lämnat öppet mål för parter som önskar dekryptera data som berörda kryptoimplementationer var avsedda att skydda. Detta utan att några stora resurser eller ansträngningar krävs, dessutom i snudd på realtid eftersom alla möjliga nycklar kan genereras och göras kända i förväg.

Fenomenet har fått det lite lustiga namnet DUHK — Don’t Use Hard-coded Keys vilket ju passar bra på denna typ av total galenskap.

För den mer intresserade kan man läsa igenom teamets rapport här: https://duhkattack.com/paper.pdf

Vi rekommenderar alla organisationer som använder produkter som berörs av detta att ta en dialog med leverantören och uppgradera/patcha produkter där det finns uppgraderingar/patchar tillgängliga. I fall när detta ej är möjligt bör man betrakta sådana kryptoimplementationer som verkningslösa.

Kontakta Certezza Support vid frågor,
E-post: support@certezza.net
Telefon: 08-791 92 00