Luciferscryptografie: Hoe ECDSA in een goedkope microcontroller te proppen

Als het gaat om het beschermen van data in IoT of goedkope hardware, botsen ontwikkelaars vaak tegen een muur. Probeer maar eens een volledige OpenSSL te deployen op een 8-bit AVR of zwakke ARM Cortex-M0. Waarschijnlijk past je firmware gewoon niet in het geheugen, en zelfs als dat wel het geval is, hou je geen resources over voor de hoofdapplicatielogica. Daar komt het micro-ecc-project goed van pas—het doet één ding, maar dat doet het verdomd goed.

Wat is het doel van dit project

micro-ecc is een compacte implementatie van ECDH (sleuteluitwisseling) en ECDSA (digitale handtekening) algoritmen in C. De auteur van het project, Ken MacKay, had duidelijk als doel om een bibliotheek te creëren die overal zou draaien waar er maar enige processor aanwezig is.

De belangrijkste truc hier is de volledige afwezigheid van dynamische geheugentoewijzing. Geen malloc en heap, alleen stack en statische opslag. Voor embedded systemen is dit cruciaal: je weet exact hoeveel geheugen cryptografie verbruikt op compiletijd, en je hoeft niet bang te zijn voor fragmentatie of runtime-lekken.

Wat de bibliotheek kan doen

De bibliotheek ondersteunt vijf standaard curves, waaronder de populaire secp256r1 (ook bekend als P-256) en de "Bitcoin" secp256k1.

De belangrijkste kenmerken zien er zo uit:

• Werkt op 8, 32 en 64-bit architecturen.
• Beveiligd tegen bekende side-channel attacks.
• Geschreven in pure C, maar er zijn assembly snippets voor AVR en ARM om maximale snelheid eruit te persen.
• Gedistribueerd onder de liberale BSD 2-clause licentie.

Trouwens, als je met Arduino werkt, is het project direct beschikbaar in de Library Manager. Geen handmatig downloaden nodig—zoek gewoon naar micro-ecc en voeg het toe aan je sketch.

Kleine code voor grote taken

De auteur beweert dat de code geoptimaliseerd is voor grootte. In de wereld van microcontrollers is dit vaak belangrijker dan pure snelheid. Als je maar één keer per maand een firmware-update handtekening hoeft te verifiëren, maakt het niet uit of het 100ms of 500ms duurt. Wat wel uitmaakt is dat de verificatiecode niet 80% van je flash-geheugen opeet.

Dat gezegd hebbende, er zijn optionele optimalisaties in de code. Bijvoorbeeld via uECC_OPTIMIZATION_LEVEL kun je de prestaties tunen. Maar wees voorzichtig: bij hoge optimalisatieniveaus voor ARM-platforms kan GCC specifieke flags nodig hebben zoals -fomit-frame-pointer, anders kan alles breken.

Wat het in code uitziet

De bibliotheek heeft een minimalistische interface. Om te beginnen kopieer je gewoon een paar bestanden naar je project en neem je het headerbestand op.

Curve-punten worden standaard weergegeven in niet-gecomprimeerde vorm zonder het 0x04 prefix. Als je elke byte wilt besparen bij verzending via radio, biedt de bibliotheek uECC_compress() en uECC_decompress() functies.

Waarvoor is dit bedoeld

Ik zie verschillende scenario's waarin micro-ecc simpelweg onmisbaar is. Ten eerste, apparaatauthenticatie. Bijvoorbeeld wanneer je sensor aan de server moet bewijzen dat het is wat het is, en geen namaak. ECDSA is perfect voor het genereren van zo'n handtekening.

Ten tweede, Secure Boot. Als je een aangepaste bootloader schrijft voor STM32 of een AVR, helpt micro-ecc om de handtekening van een nieuw firmware-image te verifiëren voordat het naar flash wordt geschreven.

Ten derde, als je wearable electronics of batterijgevoede sensoren maakt. Hoe minder CPU-cycli er aan berekeningen worden besteed, hoe langer het apparaat meegaat. Assembly snippets voor ARM en AVR komen hier goed van pas.

Enkele opmerkingen voor onderweg

Ondanks zijn genialiteit heeft het project zijn eigenaardigheden. De README is vrij beknopt, dus voor details over elke functie moet je in de uECC.h duiken. Documentatie leeft in de code comments.

Als je van plan bent om het project te bouwen op Windows, vergeet dan niet om de systeembibliotheek advapi32.lib te linken—die is nodig voor het werken met entropie. En voor AVR, zorg ervoor dat compiler-optimalisatie is ingeschakeld (-O1 en hoger), anders werkt de bibliotheek mogelijk niet correct vanwege stack-handling specifics.

Al met al is dit een geweldig voorbeeld van hoe een gespecialiseerde bibliotheek eruit zou moeten zien: een smalle focus, minimale afhankelijkheden en voorspelbaar gedrag. Als je hardware te zwak is voor TLS maar je hebt beveiliging nodig—micro-ecc verdient zeker een plekje in je src/lib.