Ondanks het toenemende aantal netwerkaanvallen op IoT-apparaten wordt firmwarebeveiliging vaak op een secundaire plaats geplaatst. Terwijl aanvallers de systeemstack binnendringen en zich richten op het opstartproces en de onderliggende hardwareconfiguratie, is de keuze van de geheugenarchitectuur een belangrijke beslissing geworden bij het opzetten van een verifieerbare vertrouwensketen.
Om de beveiliging van de firmware te garanderen, moet elk onderdeel daarom een encryptieverificatie ondergaan voordat het wordt uitgevoerd. Dit pad begint met een onveranderlijke bootloader, die verantwoordelijk is voor het laden en verifiëren van de hoofdfirmware. De geheugentechnologie die bij elke stap wordt gebruikt, kan er echter toe leiden dat de firmware kwetsbaar is voor ongeoorloofde wijzigingen.
Intern en extern flashgeheugen
De fysieke locatie van het niet-vluchtige geheugen dat wordt gebruikt om firmware op te slaan, is een van de meest kritische factoren in apparaatbedreigingsmodellen. Firmware-ingenieurs moeten een keuze maken tussen op de chip ingebouwde flash (eFlash) en externe flashmodules die zijn aangesloten via seriële interfaces zoals SPI of QSPI.
Embedded flash-geheugen wordt meestal rechtstreeks geïntegreerd in microcontrollers of SoC-chips. Deze architectuur biedt het hoogste niveau van fysieke beveiliging, omdat er geen externe bussen beschikbaar zijn die aanvallers kunnen manipuleren. Zelfs de toegang tot het interne flashgeheugen wordt geregeld door speciale registers en lock-bits.
Bovendien ondersteunt het ingebouwde flashgeheugen permanente leesbeveiliging. Door gespecialiseerde veiligheidszekeringen kort te sluiten, kunnen ontwikkelaars JTAG- of SWD-foutopsporingsinterfaces uitschakelen om te voorkomen dat hackers firmware-images wijzigen. Naarmate SoC's zich echter verplaatsen naar kleinere knooppunten, wordt deze technologie geconfronteerd met aanzienlijke schaalbaarheidsproblemen.
Extern flashgeheugen wordt daarentegen buiten de hoofdprocessor geplaatst en communiceert via een snelle seriële interface. Deze architectonische keuze maakt de opslagcapaciteit eenvoudig schaalbaar, maar vergroot ook het aanvalsoppervlak van het systeem. Alle gegevens die tussen de processor en het externe flashgeheugen worden verzonden, zijn inherent kwetsbaar voor bedreigingen zoals afluisteren, man-in-the-middle-aanvallen en fysiek geknoei.
Om deze risico's aan te pakken, moeten firmware-ingenieurs goede hardware- en softwarebeschermingsmaatregelen implementeren. Veel externe NOR-flashgeheugenapparaten zijn uitgerust met een fysieke schrijfbeveiligingspin. Wanneer de pin op een specifieke spanning wordt geplaatst, voorkomt de interne logica van de chip dat wis- of schrijfopdrachten worden uitgevoerd.
Afbeelding 1: Het W77Q32JWSSIR TR beveiligde seriële NOR-flashgeheugen van Winbond Electronics beschikt over complexe encryptiemogelijkheden voor communicatiekanalen. (Afbeeldingsbron: Winbond Electronics)
Als de gegevens echter wel kunnen worden gelezen, is het simpelweg vergrendelen van het flashgeheugen niet voldoende. Tijdens de uitvoering hebben aanvallers nog steeds toegang tot het adres en de databus. Deze kwetsbaarheid heeft geleid tot de ontwikkeling van gespecialiseerde veilige flash-apparaten, waaronder op hardware gebaseerde root of trust-mechanismen, gecodeerde communicatiekanalen en monotone tellers om rollback-aanvallen te voorkomen.
Als echter de verkeerde opslagarchitectuur wordt gekozen, zal het apparaat fundamentele defecten achterlaten die niet volledig kunnen worden verholpen door softwarepatches. Ontwerpen die firmware zonder codering of verificatie op externe EEPROM opslaan, zijn bijvoorbeeld altijd kwetsbaar voor hardwareaanvallers. Integendeel, het kiezen van een geheugen met buitensporige beperkingen kan de functionaliteit ervan beïnvloeden.
Daarom moeten ingenieurs de beste praktijken en ontwerptechnieken begrijpen om de firmwarebeveiliging te maximaliseren via geheugenarchitectuur.
Best practices voor veilig firmware-opslagontwerp
Bij het ontwerpen van een veilig firmware-opslagpad vanaf het opstarten tot runtime moeten firmware-ingenieurs de volgende principes volgen:
1. Op hardware gebaseerde vertrouwensbasis
De uitvoering moet altijd beginnen vanuit onveranderlijke geheugengebieden. Het opstart-ROM of de permanent beveiligde flashsector moet bijvoorbeeld code bevatten om alle andere firmware te verifiëren. Dit zorgt ervoor dat aanvallers de verificatie niet kunnen omzeilen door met het initiële wachtwoord te knoeien.
2. Gebruik gecodeerde handtekeningen
Configureer de veilige bootloader om alleen firmware-images uit te voeren die zijn ondertekend met vertrouwde privésleutels. Op deze manier kunnen aanvallers, zelfs als ze toegang hebben tot het geheugen en bits kunnen wijzigen, ongeautoriseerde code voorkomen. Als vertrouwelijkheid vereist is, kan de opgeslagen firmware worden gecodeerd.
3. Gebruik hardwarebeveiligingsfuncties
Als de systeemarchitectuur externe opslag gebruikt, moeten ingenieurs apparaten kiezen die hardwarebeveiliging ondersteunen, zoals ingebouwde wachtwoordbeveiliging of eenvoudige codering. Hoewel deze apparaten misschien niet zo robuust zijn als complete beveiligingscomponenten, voegen ze een extra beschermingslaag toe.
Figuur 2: Macronix ondersteunt MX25L3233FM2I-08Q 32 Mb serieel NOR-flashgeheugen met seriële randapparatuurinterface. (Afbeeldingsbron: Macronix)
4. Isoleer firmware en gegevens
Organiseer het geheugengebied en scheid de meest gevoelige code. Plaats in MCU kritische routine-instructies in een beveiligd geheugengebied. Zelfs firmware kan, indien ondersteund door hardware, bepaalde flashgeheugenbanken markeren als alleen uitvoerbaar of alleen-lezen.
5. Updateplan voor beveiligingsfirmware
Zorg ervoor dat het updateproces zelf wordt gevalideerd (bijvoorbeeld door te vereisen dat het updatepakket wordt ondertekend). Als het ontwerp externe opslag gebruikt voor tijdelijke updates, moeten dezelfde beveiligingsmaatregelen worden genomen als voor de hoofdfirmware-opslag.