0-Day lek in de Blockchain

Dit artikel is gepubliceerd in de PvIB Magazine 2 van 2017. De Blockchain special.

Blockchain is niet meer weg te denken bij de huidige innovatieve trajecten binnen o.a. de overheid, zorg en financiële sector. Blockchain is een techniek waar velen hun heil in zien en wordt een basis om een aantal problemen op te lossen. Bijvoorbeeld problemen die we zien bij centrale toepassingen die we decentraal of distributed willen inzetten. Deze worden beheerd door één organisatie en gebruikt door meerdere organisaties. Overheid zou bijvoorbeeld een blockchain omgeving voor identiteiten (soort van DigID) kunnen outsourcen zonder dat ze de controle verliezen over het beheer van de identiteiten. Meerdere servers bij diverse organisaties die dan de identiteit van de burgers kunnen vaststellen maar de identiteiten worden door overheid beheerd. De basis van deze blockchain omgeving ligt bij de overheid en de overheid houdt de controle.

Met dat laatste heb ik gelijk de basis te pakken van de problemen die kunnen ontstaan als je nu een blockchain omgeving neer zet die 10 tot 15 jaar gaat draaien. De techniek is nog nieuw en niet volwassen genoeg om in te zetten voor systemen die langer dan 5 jaar mee moeten gaan. Waarom, dat heeft mede te maken met lekken in de hardware, software, gebruikte algoritmes en de mogelijkheid deze op te lossen. De standaard 0-Day lekken van deze wereld.

De vraag die we zeker gaan krijgen en ook beantwoord moeten krijgen, is ‘wat zijn de gevolgen van een gekraakte blockchain omgeving?

Een voorbeeld uit het verleden zijn de Root CA’s en de daarbij gebruikte sleutellengtes, algoritmes en levensduur. 512 bits sleutels en MD5 algoritme waren vroeger goed maar worden tegenwoordig niet meer als veilig gezien, Alle Root-CA’s die 512 bits sleutels en/of MD5 bevatten zijn uit de Root CA Trust lijsten gehaald. Terwijl er Root CA’s bij zitten die nu nog steeds een geldige einddatum hebben.

0-day in de Blockchain

In de software is al sinds jaar en dag bekend dat elk systeem wel eens een lek heeft. Lekken in software, data verlies, beschikbaarheid van systemen en andere problemen komen bij alle organisaties wel eens voor. Meestal zonder veel problemen maar soms, helaas, met het lekken van grote hoeveelheid zeer gevoelige gegevens. Bijvoorbeeld het lekken van gebruikers en versleutelde wachtwoorden van Yahoo en Linkedin.

De techniek van de blockchain kun je verdelen in een aantal onderdelen. Belangrijkste zijn: software, hardware, identificatie (gebruikers, IAM) en de gebruikte encryptie algoritmes. Op alle lagen kunnen lekken worden gevonden en moet er een oplossing doorgevoerd worden. Bij de software kun je updates doorvoeren en gebruikers zijn te verwijderen, al dan niet binnen een korte tijd. Bij lekken van gebruikersgegevens, kunnen deze geblokkeerd of gereset worden. Bij een hardware probleem is het vaak wat moeizamer maar niet onmogelijk om deze ook op te lossen. 0-Day lekken, en de daarbij gepaarde eventuele aanvallen, zijn dan op een standaard manier te detecteren en tegen te gaan.

Voor encryptie algoritmes is dat een ander verhaal en heeft meer impact voor een blockchain.

0-Day is het algoritme

Bij Blockchains zijn verschillende algoritmes vereist om authenticatie, versleuteling en signing door te voeren. Voor authenticatie wordt vaak asymmetrische encryptie (bv RSA of ECC) gebruikt, versleutelen wordt met symmetrische encryptie (bv AES) gedaan en voor signing is een hashing algoritme (bv SHA256) nodig.

Sleutellengte is een belangrijk onderdeel bij het gebruik van de encryptiealgoritmes. Langere sleutels worden vaak gezien als veilig en toekomst vast. Op dit moment worden RSA met 2048bits lengte, AES256 en SHA256 als veilig beschouwt.

Over 10 tot 15 jaar is de wereld heel anders dan nu en moet je rekening houden met compleet nieuwe technieken zoals Quantum Computers. Van de Quantum Computers weten we nu al dat deze de asymmetrische encryptie algoritmes kunnen breken. Bij error vrije Quantum Computers van 500 QuBits is het al mogelijk om RSA te kraken. Er bestaan nu al Quantum Computers van 20 QuBits. Al zijn deze Quantum Computers nog niet error vrij.

Naast de Quantum Computers is het kraken van een algoritme ook op huidige machines een mogelijkheid. In verleden hebben we dat gezien bij de voorloper van SHA1, het MD5 algoritme. Maar ook RSA met sleutels die kleiner zijn dan 1024 bits zijn met de huidige systemen niet meer veilig.

Een 0-day lek op een algoritme is dan niet meer een vraag of dat gebeurd, maar meer wanneer deze in praktijk ontdekt gaat worden! Dat kan wel eens eerder zijn dan we nu denken en ik vermoed dat dit tussen 2020 en 2025 op asymmetrisch algoritmes uitgevoerd wordt. Dat is al met 3 tot 8 jaar.

Met deze wetenschap is het ontwikkelen van een blockchain voor meer dan 10 jaar een risico indien je deze opzet met de algoritmes zoals RSA of ECC. Bij het ontwikkelen van nieuwe blockchain omgevingen moet je dus na gaan denken hoe je met 0-day aanvallen op de algoritmes om gaat.

Het On-The-Fly veranderen van algoritme is een eis die je mee moet nemen voor het bouwen van de software van de blockchain. Een eis die nu nogal nieuw en klinkt, maar met 5 jaar een standaard gaat worden. Lessons-learned uit het verleden is de basis voor een gedegen Blockchain omgeving.

Risico’s bij kraken

De vraag die we zeker gaan krijgen en ook beantwoord moeten krijgen is ‘wat zijn de risico’s van een gekraakte blockchain omgeving’. Een aantal risico’s heb ik hierna beschreven.

Bij lekken op het level van de software en identificatie (IAM), is het in het ergste geval mogelijk om veranderingen aan te brengen en deze te laten tekenen door een sleutel van de blockchain. Gevolg is dat er een identificatie of transactie uitgevoerd kan worden waarvoor niemand een goedkeuring heeft gegeven. Voorbeeld wat kan gebeuren is de DAO hack uit 2016. Toen is er een soort lek in het smartcontract misbruikt om miljoenen weg te sluizen naar derden. Dit was blockchain technisch volkomen legaal en kon daardoor gewoon uitgevoerd worden.

Misbruik van lekken op hardware niveau is stuk moeizamer. Hackers kunnen de blockchain uit de lucht halen maar echt nieuwe transacties uitvoeren is een ander verhaal. Vaak worden lekken in hardware gebruikt als opstapje naar software om daar aanvallen uit te voeren. Daarnaast is de support voor hardware vaak maximaal 5 jaar en dan wordt deze niet meer door de leverancier ondersteund. Vervangen moet dus wel mogelijk zijn en wordt nu al veelvuldig uitgevoerd bij systemen die langer dan 5 jaar moeten draaien.

Het kraken van het algoritme is van hele andere aard. Hiermee kun je een al gesigneerde transactie veranderen en mogelijk smartcontract-acties opstarten. Ook dit zal het blockchain zien als legaal gebruik want het is netjes digitaal ondertekend en voldoet technisch aan alle eisen. Als je een blockchain hebt opgezet waar identificatie en authenticatie (bv DigID) wordt bepaald, is het mogelijk om massaal identiteiten te misbruiken. Met DigID kun je dan aanvragen bij Belastingdienst kunnen uitvoeren. Die is een algemeen probleem dat op alle IAM systemen van toepassing is.

Conclusie

Met de huidige technieken in algoritmes is het nog niet mogelijk een Blockchain te bouwen die Post Quantum Compliant is. Een Post-Quantum signing algoritme is nog niet beschikbaar, al zijn er wel ontwikkelingen gaande.

Een van de oplossingen om toch van start te gaan, is de omgeving zodanig te ontwikkelen dat de gebruikte algoritmes te vervangen zijn. Indien er dan een Post-Quantum compliant algoritme beschikbaar komt, zal deze in een bestaande Blockchain gebruikt kunnen gaan worden. 

Met dit in het achterhoofd moet je dus goed moeten nadenken over wat je met de blockchain wilt doen en voor hoelang deze in productie blijft draaien. Is dat minder dan 5 jaar, dan is het geen probleem deze neer te zetten en de techniek van Blockchains verder te onderzoeken. Wil je iets neerzetten dat na 2025 nog moet draaien, is nadenken over het vervangen van de algoritmes een vereiste!

Tevens is het nodig na te denken of alle identiteiten of transacties in de blockchain opnieuw bepaald en ondertekend moeten worden. Wil je dat doen, dan is het een grote verandering in de huidige manier van denken over hoe een blockchain moet worden opgezet.

Al met al, is het opzetten van een goede blockchain niet iets wat je even snel kunt doorvoeren. Een team met gedegen kennis van blockchain en encryptie is een vereiste om een omgeving voor lange termijn veilig neer te zetten.