One-time pad (OTP) mag dan perfecte encryptie leveren, het is ook een methode die nauwelijks nog toepassing heeft, omdat zij onpraktisch en ook niet onomstreden is. Een ding staat buiten kijf: OTP is de oplossing voor een hardnekkig probleem. Het tweede gedeelte in een serie van drie over het toepassen van OTP tegen het lekken van sleutels uit end-point hardware.
Hoe informatie subtiel door is te geven, toont het volgende voorbeeld aan.
Wie bang is dat een applicatie een 256-bit sleutel doorgeeft, bijvoorbeeld via netwerk of een bestand, zoekt naar iets wat in elk geval 256 bit groot is. Een sleutel hoeft echter niet volledig te worden overgedragen om hem toch te weten.
Een 256-bit sleutel is een getal ergens in een reeks tussen 0 en 2256-1. Dat is echt een heel erg groot getal. Zo groot zelfs dat het niet eens mogelijk is alle tussenliggende getallen te noemen. Of de sleutel in de bovenste helft van het hele gebied zit of in de onderste helft, het is precies 1 bit aan informatie. Dit is het meest linker bit van de hele sleutel. Dit is een erg belangrijk bit, want de helft van de security verdampt daarmee
Als je het nu zou willen kraken dan heb je nog maar 2255 combinaties te proberen. Het meest rechter bit zegt of het getal even of oneven is. Samen is dit goed voor een kwart van de security. Dat lijkt een flinke reductie maar het getal is nog steeds te groot om te kraken. Er zijn nu verschillende opties. Je kunt dus doorgaan met het bit voor bit laten lekken van de sleutel. Al naar gelang de snelheid van doorgeven van het side-channel kan dat wel even duren voor je voldoende bits van de sleutel hebt.
Een andere methode is een checksum te sturen van het nog te doorzoeken gebied. Daarmee geef je niet de volledige informatie van de sleutel door, maar zeg je wel iets over het resterende deel. Dit kan het kraken van de volledige sleutel makkelijker maken.
Afhankelijk in welk soort geheugen de sleutel staat maakt de hardware zelf een checksums van de sleutel. Secure elements (of hardware security module) zijn hardwarecomponenten die gebruikt worden om sleutels te bewaren. Deze zouden tegen lekken moeten beschermen maar worden niet altijd gebruikt.
Overheden of hackers die dit soort side-channels maken, letten er op dat de sleutel niet volledig wordt opgeleverd maar dat er nog een stukje zoekwerk over blijft. Je weet namelijk nooit wie een side-channel ontdekt. Het is niet de bedoeling dat een andere hackergroep er ook gebruik van kan maken. Daarom blijft er een altijd een stukje zoekwerk over zodat alleen staten met voldoende resources de rest kunnen kraken. Kwaadaardige aanpassingen zijn altijd goed verborgen met minimale sporen.
Zoeken naar de heilige graal
Het is dus de bedoeling geen sleutels te hebben die je heel lang bewaart, maar alleen vluchtige sleutels. Gelukkig kan TLS, het huidige standaardprotocol voor encryptie van https-internetverbindingen, hier goed mee omgaan. In plaats van RSA kan TLS gebruik maken van Diffie-Hellman of elliptisch curve. Hierbij worden willekeurige getallen als tijdelijke sleutel gebruikt. Dit is nu min of meer ook de standaard in browsers. Als je de volgende keer naar de site gaat, gebruik je een ander random nummer.
Een TLS-sessie waarin je een specifieke sleutel gebruikt duurt driehonderd seconden of langer. Een side-channel moet dus in ieder geval elke vijf minuten genoeg informatie uitspugen om mee te kunnen lezen. Als de sessietijd korter zou zijn, zou het moeilijker worden sleutels te laten lekken en is het in elk geval ook moeilijker om alle sleutels te kraken van een aantal sessies achter elkaar. Bij elk sessie begin wordt er een handshake uitgevoerd. Daarbij worden de gemeenschappelijk gedeelde sleutels gemaakt. Dit is een noodzakelijk begin van elke internetverbinding. Deze handshake is echter traag en resource-intensief. Een korte sessietijd is mogelijk maar zal nadelige impact op de snelheid van de verbindingen hebben. Daarnaast is TLS in hoge mate configureerbaar. Je kunt het dus instellen, maar je kunt het ook weer zo veranderen. Een aantal parameters is ook onderhandelbaar bij de handshake. Een aantal bekende exploits tegen TLS maakt misbruik van het feit dat deze TLS-instellingen onderhandelbaar zijn. Bijvoorbeeld een cipher suite kiezen met een lagere security. Dit bij elkaar opgeteld, maakt dat het technisch misschien wel mogelijk is een TLS-verbinding te maken met zeer frequent wisselende sleutels, maar zodra dit sterk ten laste gaat van de snelheid is het snel duidelijk dat dit soort verbindingen niet gekozen gaat worden. Dit is zeker het geval als het bestaan van side-channels ook nog eens in twijfel wordt getrokken.
Dit is hoe het werkt met security. Listige telecomapparatuurfabrikanten met een niet te stillen informatiehonger hebben op dit punt dus gewonnen. Er is daarom een inherent veilige manier van verzenden nodig die niet onderhevig is aan het lekken van informatie en ook geen concessies doet aan de snelheid.
Heilige graal gevonden
Er bestaat inderdaad een manier die bestand zou zijn tegen het lekken van gegevens in een onveilige omgeving. Deze manier is zelf echter omgeven met mysteries en is ook nog eens omstreden.
Deze inherent veilige manier heet OTP (One-Time-Pad). Deze bestaat gek genoeg al meer dan honderd jaar. Bij OTP wordt er niet gebruik gemaakt van een algoritme maar van ruis. Er wordt ook geen sleutel gebruikt zoals wij die kennen. Het versleutelen wordt gedaan met een kaart met ruis, het ontsleutelen wordt gedaan met een andere kaart met exact dezelfde ruis. Nadat de actie is voltooid, wordt de kaart verbrand. Vandaar de naam One-time Pad. Deze manier is wiskundig onbreekbaar omdat er geen systeem aan ten grondslag ligt. Elke mogelijke ontsleuteling van een gecodeerd bericht is exact even waarschijnlijk. Er zit geen systeem in. Een sleutel kan niet lekken of gebroken worden omdat er gewoonweg geen sleutel is. OTP werd in het verleden gebruikt als er echt veel op het spel stond. Zo gebruikte de Amerikaanse president Kennedy OTP in 1962 tijdens de Cuba-crisis om met de Sovjet-partijleider Chroesjtsjov te onderhandelen. Omdat we weten wat er toen op het spel stond, mag je stellen dat wij dankzij het gebruik van OTP tijdens de Cuba-crisis nog leven. Meer: de reden dat dit artikel niet in het Duits is opgesteld, is omdat OTP ook tijdens de Tweede Wereldoorlog werd gebruikt door de geallieerden.
Moeten blijven aftappen
De reden dat OTP het verschil maakt is tweeledig. Enerzijds is de versleuteling onbreekbaar maar het is veel belangrijker dat er geen sleutel is die kan lekken. Er is alleen een grote hoeveelheid ruis. Het subtiel laten lekken van enkele bits is dus totaal zinloos. Wie de versleutelde gegevens wil decoderen zal dus alle ruis moeten stelen. Dit betekent dat men alle ruis continu moet blijven aftappen. Je mag niet een bit missen. In deze vorm moet een datadiefstal zulke groteske vormen aannemen dat het bijna makkelijker is om de videostream van gedecodeerde berichten van het beeldscherm te kopiëren. Dit laatste is even grotesk. OTP introduceert een onhandigheid die subtiel lekkende side channels onmogelijk maakt. Eenvoudig geformuleerd: er kan niet meer iets kleins bestaan dat subtiel kan lekken.
Er is nog een andere eigenschap die OTP geschikt maakt. Een eigenschap die minder voor de hand ligt. Het probleem met ingewikkelde technieken is niet de techniek zelf maar de implementatie en de toepassing ervan. Die is vaak slordig. Tijd is geld en zodra het werkt is het in het bedrijfsleven al vaak goed genoeg. OTP is daartegen eigenlijk simpel: je kunt er minder fouten mee maken.
