Architectuur voor het beveiligd over-the-air updaten van een automotive ECU

Door Osvaldo Romero, Systeem en Architectuur Engineer voor Automotive Microcontrollers, NXP Semiconductors

De functionaliteit van elektronische producten wordt hoofdzakelijk bepaald door de ingebedde software. Het is inmiddels gebruikelijk deze functionaliteit uit te breiden en te verbeteren nadat het product is geleverd en in gebruik is genomen. Dit gebeurt door het product via een communicatie-interface van software-updates te voorzien. Omdat dit op afstand gebeurt worden deze updates aangeduid als Over-The-Air (OTA).

Belangrijk voor dit verhaal is het onderscheid tussen software-updates en nieuwe software, zoals een applicatie. Apps zijn ontworpen als programma’s die door de hostsoftware worden uitgevoerd zonder de algemene functionaliteit van het product te veranderen. Software-updates kunnen de functionaliteit van het product fundamenteel veranderen. Als een app ervoor zorgt dat het product niet meer functioneert, kan het product meestal volledig worden hersteld door het opnieuw op te starten. Als een software-update beschadigd is of een bug bevat, kan het product niet meer werken en in dat geval is het onwaarschijnlijk dat een herstart het probleem verhelpt.

Veel elektronische consumentenproducten, zoals mobiele telefoons, tablets, smart-tv’s en set-top boxes, kunnen standalone apps draaien. Een veel groter deel van de met een netwerk verbonden apparaten is niet uitgerust om standalone apps te draaien en wordt ontworpen om OTA-updates van de software te accepteren. Hieronder vallen producten voor toepassingen in onder meer de industrie, de medische sector en de auto-industrie. Deze toepassingen, waar vaak hoge eisen worden gesteld aan de betrouwbaarheid, moeten een evenwicht zien te vinden tussen het gemak van OTA-updates en het risico van het permanent onbruikbaar maken van een apparaat (‘bricking’).

De OTA-architectuur

Om bricking van een apparaat ten gevolge van een mislukte OTA-update te voorkomen, moeten technici potentiële faalplekken identificeren en een systeemarchitectuur creëren waarmee dit kan worden ondervangen. De belangrijkste onderdelen van deze architectuur zijn:
• een telematica-eenheid, die in verbinding staat met de server die de update levert;
• een gateway (OTA-manager), die zorgt voor de lokale ontvangst en distributie van de update;
• een client, dat is het apparaat dat de update ontvangt.

De auto-industrie is het toepassingsgebied bij uitstek waar een uiterst betrouwbare werking een strikt proces vereist voor de implementatie van OTA-updates. Een ECU mag tijdens of na een OTA-update onder geen enkel beding vastlopen. Beveiliging is hier van cruciaal belang. Elke fase van het updateproces moet beveiligd zijn. Dit betekent in de regel dat encryptie en authenticatie moeten worden gebruikt met sleutels en certificaten, die zodanig beveiligd zijn opgeslagen dat er niet mee kan worden geknoeid.

Afbeelding 1: Voorbeeld van een OTA-architectuur die kan worden geïmplementeerd in een automotive toepassing.

In een typische workflow voor een OTA-update krijgt de telematica-eenheid een signaal dat er een nieuwe software-update klaarstaat. Hierop verifieert deze unit de bron en zet een beveiligde verbinding met de server op om het bestand te downloaden. Na ontvangst geeft de telematica-eenheid de software door aan de gateway, die deze gereed maakt voor de client. In de meeste gevallen kan de client, bijvoorbeeld een automotive ECU, de update zelf installeren door de in het niet-vluchtige geheugen opgeslagen software te overschrijven of te vervangen.

Bij veiligheidsgerelateerde toepassingen is deze laatste stap vaak het meest cruciale deel van het OTA-proces. Veelal moet de update worden geïnstalleerd zonder het proces te stoppen. Ook kan de client de update inplannen op een moment dat hij niet actief is. Links – of rechtsom: dit proces moet goed doordacht zijn.

Management van de OTA-update van de client

Er zijn verschillende manieren om een OTA-update uit te voeren. Dit is afhankelijk van de grootte van het softwarebestand, het beschikbare niet-vluchtige programmageheugen en de aanwezige processoren. Welke methode ook wordt gebruikt, het is onvermijdelijk dat het product (zoals een ECU) na de update de nieuwe software moet beginnen uit te voeren. Dit betekent meestal dat vanaf een bekend punt moet worden begonnen. In de regel zal dit een herstart betekenen.

Sommige microcontrollers (MCU’s) faciliteren OTA-updates met functies die de verschillende opties kunnen ondersteunen. Deze ondersteuning begint met de bootloader, maar kan worden uitgebreid tot hardwaregerelateerde functies, zoals de wijze waarop het niet-vluchtige geheugen is gepartitioneerd of de mogelijkheid om ‘read-while-write’ uit te voeren, waarbij naar een bepaald geheugen wordt geschreven en van datzelfde geheugen wordt gelezen. Hierdoor kan de nieuw software worden opgeslagen terwijl het apparaat de bestaande software blijft uitvoeren.

Als de MCU van de toepassing geen geheugenblokken met ‘read-while-write’ ondersteunt, of als het softwarebestand zo groot is dat het meer dan de helft van de beschikbare geheugenruimte in beslag neemt, kan voor de OTA-update worden gekozen voor de ‘in-place’-methode. In dat geval stuurt de OTA-manager, die idealiter ten minste twee versies van de software bewaart, de update naar de client. Zodra de update is geverifieerd, draait de client het bootloader-programma om de in het niet-vluchtige geheugen opgeslagen programmacode byte-per-byte te overschrijven. De vorige kopie van de software wordt dan rechtstreeks in het geheugen overschreven.

Deze aanpak, waarbij de bekende, goed werkende software wordt verwijderd en wordt vervangen door de update, kent verschillende risico’s. Om die te ondervangen is het zaak dat er een goed beveiligingsprotocol is tussen client en manager om de geldigheid van de software te kunnen garanderen. Ook moet de client de status van de update kunnen registreren als geslaagd of mislukt.

 Dit is nodig, omdat er een onderbreking of fout kan optreden tijdens de overdracht van de update tussen de beheerder en de client. Met ‘in-place’-updates is er geen manier voor de client om terug te keren naar de vorige versie zodra de update is begonnen. Hij zou dan ofwel de laatst bekende goede softwareversie of de nieuwe update opnieuw moeten laden door bij het opstarten deze opnieuw aan te vragen bij de manager. De bootloader moet een dergelijke statuscontrole uitvoeren als onderdeel van iedere herstart.

Een andere manier om ‘in-place’-updates te implementeren is het gebruik van extern geheugen om de OTA-update op te slaan, en de nieuwe software in het programmageheugen op de chip te laden tijdens het opstarten of na een reset. Het nadeel van deze oplossing is dat er extra geheugen nodig is, waardoor meer systeemvermogen nodig is, er meer componenten op de PCB moeten worden geplaatst en de totale kosten toenemen.

Een alternatieve aanpak is de A/B-swap-methode. Hierbij is het systeem zo ingericht dat de software minder dan de helft van het beschikbare programmageheugen in beslag neemt. De nieuwe software wordt geladen in het deel van het geheugen dat niet wordt gebruikt door de actieve versie van de software. Na het laden en verifiëren start het systeem opnieuw op en begint het met de uitvoering van de nieuwe software. Hierbij is de vorige softwareversie opgeslagen in wat nu het ongebruikte deel van het programmageheugen is.

Deze aanpak heeft verschillende voordelen ten opzichte van de ‘in-place’-update. Ten eerste is er na de update de mogelijkheid om terug te vallen op de vorige software, die nog in het programmageheugen is opgeslagen. Omdat de nieuwe software in het vrije geheugen wordt opgeslagen, kan het apparaat bovendien gewoon blijven werken terwijl de update in het programmageheugen wordt geladen.

De belangrijkste systeemvereiste voor deze aanpak is dat er minstens tweemaal zoveel programmageheugen beschikbaar moet zijn dan strikt noodzakelijk is. De extra kosten voor die grotere geheugencapaciteit zijn veelal goed te verantwoorden door de voordelen van een betrouwbaardere software-update, zeker in het geval van veiligheidskritische toepassingen.

In de tabel worden de verschillende OTA-aanpakken met elkaar vergeleken.

Tabel 1: Eigenschappen en voordelen van de verschillende OTA-aanpakken.

MCU-ondersteuning voor OTA-updates

De S32K3 familie microcontrollers van NXP is ontworpen om OTA-functionaliteit in veeleisende toepassingen mogelijk te maken. De architectuur is gekwalificeerd voor de auto-industrie en heeft een dual-bank on-chip flashgeheugen dat ‘read-while-write’ ondersteunt. Ontwerpteams kunnen afhankelijk van de applicatie-eisen de ‘in-place’- of A/B-swap-methode implementeren voor het uitvoeren van software-updates.

Het on-chip geheugen en de processorsubsystemen handelen het herschikken van de adressering af die in de A/B-swap-modus nodig is bij het overschakelen van het ene geheugenblok naar het andere. Fabrikanten hoeven daarvoor hun software niet aan te passen, wat de ontwikkeling van een OTA-procedure vergemakkelijkt. Bovendien kunnen delen van het flashgeheugen, zoals de bootloader, worden vergrendeld om te voorkomen dat kritieke code wordt gewist of overschreven.

Een ander belangrijk kenmerk is de optie voor een multicore-architectuur. Hierdoor kan één Arm Cortex-M7 kern vanuit het ene deel van het flashgeheugen de software blijven uitvoeren, terwijl een tweede Arm Cortex-M7 kern in het andere deel van het flashgeheugen de download, verificatie en opslag van de nieuwe software afhandelt.

Zoals eerder beschreven, is een van de voordelen van de A/B-swap-methode dat de oudere versie van de software nog steeds in het geheugen wordt bewaard. Dit betekent betekent dat bij een probleem met de nieuwe softwareversie de MCU snel terug kan gaan naar de vorige versie. De S32K3x4 heeft bijvoorbeeld meerdere banken van 1 Mbyte programma flashgeheugen en 128 Kbyte data-flashgeheugen. De OTA-indicatoren worden gebruikt om het actieve blok te identificeren, dat de versie van de software bevat die op dat moment wordt uitgevoerd (zie afbeelding 2).

Afbeelding 2: Implementatie van een A/B-swap-OTA in de S32K3 MCU.

Voor de beveiliging van de datatransfer is de S32K3-familie voorzien van een Hardware Security Engine (HSE). Dit functionele blok biedt versleuteling en ontsleuteling via zowel symmetrische als asymmetrische coderingen, waaronder AES-128/256 en RSA. Deze functies worden gebruikt om de communicatie tussen de client en de OTA-manager te beveiligen, bijvoorbeeld door een willekeurig getal te genereren dat bij elke transactie wordt gedeeld tussen de client en de manager.

Een client op basis van de S32K3 kan veilig communiceren met een OTA-manager via CAN, LIN of Ethernet. De MCU bevat ook hardwarefuncties voor OTA-ondersteuning, waaronder OTA-indicatoren, een monitor om communicatieverlies tijdens uitwisseling van software op te sporen en te registreren, en de mogelijkheid om op basis van de status van de OTA-indicatoren naar een vorige softwareversie terug te grijpen.

  

Afbeelding 3: De 32K3x4-gebaseerde OTA-oplossing van NXP.

Conclusie

Alomtegenwoordige connectiviteit heeft OTA-updates tot standaardpraktijk gemaakt. In veiligheidskritische toepassingen, zoals de auto-industrie, moet het gebruik ervan echter met grote zorgvuldigheid gebeuren. Er zijn veel uitdagingen, zoals het waarborgen van een betrouwbare werking tijdens een update, het garanderen van end-to-end beveiliging tijdens het updateproces en het bieden van een robuuste manier om te voorkomen dat de client wordt gebrickt.

Deze uitdagingen kunnen worden overwonnen door de meest geschikte hardware te gebruiken. Wanneer hardware en software zo zijn ontworpen dat zij synergetisch werken, wordt het beheer van OTA een stuk eenvoudiger en kan elke toepassing van de voordelen ervan profiteren.