Hoe UART-communicatie op IoT-apparaten te beveiligen

Met cryptografische blokken die in MCU's zijn geïntegreerd, is het mogelijk geworden voor ontwikkelaars om elk communicatiekanaal te beveiligen, inclusief interfaces zoals UART die zelf geen beveiliging bieden.

Met het toenemende aantal spraakmakende inbreuken op gegevens en privacy in de Internet of Things (IoT)-systemen, zijn bedrijven en consumenten zich meer bewust van de noodzaak van beveiliging bij het kopen van verbonden producten. Het leveren van de beste producten of diensten is niet langer voldoende. Apparaten die onvoldoende beveiliging bieden, kunnen niet concurreren met apparaten die end-to-end beveiliging bieden.

Veel protocollen implementeren beveiliging binnen de standaard en zijn een ingebouwd onderdeel van elke controller. Ingebouwde apparaten die verbinding maken via een universele asynchrone ontvanger-zender (UART), zijn echter niet beschermd. UART is een van de eenvoudigste digitale communicatie-interfaces tussen apparaten. Het is een communicatieprotocol zonder ACK dat door elk apparaat kan worden gelezen als de baudrate bekend is.

Om te voorkomen dat gegevens worden gelezen of in het systeem worden geïnjecteerd, moet het communicatiekanaal worden beveiligd door de systemen die de gegevens verzenden en ontvangen. Dus zelfs als een indringer toegang krijgt tot het communicatiekanaal met de juiste baudrate, is het kanaal beschermd.

Symmetrische en asymmetrische beveiliging

Communicatiekanalen zijn vaak beveiligd met behulp van cryptografische algoritmen. In het algemeen kunnen cryptografische algoritmen worden geclassificeerd als symmetrisch en asymmetrisch. Met symmetrische sleutelalgoritmen delen de afzender en ontvanger één enkele geheime sleutel. De afzender versleutelt het bericht met behulp van de sleutel en deelt het versleutelde bericht met de ontvanger. De ontvanger gebruikt vervolgens dezelfde sleutel om het bericht te decoderen.

Het belangrijkste beveiligingsprobleem met algoritmen voor symmetrische sleutels is hoe de geheime sleutel veilig kan worden uitgewisseld tussen de afzender en de ontvanger. Als de sleutel tijdens de sleuteluitwisseling door een andere entiteit wordt vastgelegd, kan die entiteit ook berichten decoderen die door de afzender zijn verzonden. Het is dus van cruciaal belang dat de sleutel veilig wordt gedeeld met alleen de afzender en de ontvanger in algoritmen met symmetrische sleutels.

Om veilige symmetrische sleuteluitwisseling mogelijk te maken, worden asymmetrische sleutelalgoritmen gebruikt. Asymmetrische algoritmen gebruiken verschillende sleutels voor de coderings- en decoderingsprocessen. Hoewel deze sleutels verschillend zijn, zijn ze wiskundig gerelateerd. De symmetrische sleutel kan veilig worden uitgewisseld door deze te versleutelen met een asymmetrische sleutel en de ontvanger deze te ontsleutelen met de bijbehorende asymmetrische sleutel. Een nadeel van asymmetrische algoritmen is dat ze complexe wiskundige berekeningen met zich meebrengen en vaak rekenintensief zijn.

Voor het hoogste beveiligingsniveau wordt RSA-codering gebruikt als het asymmetrische sleutelalgoritme. Met RSA heeft een communicerende entiteit een openbare sleutel en een privésleutel. De openbare sleutel wordt, zoals de naam al doet vermoeden, openbaar gedeeld en is voor iedereen beschikbaar. Daarentegen is de privésleutel alleen in het bezit van de communicerende entiteit. Om een ​​bericht naar de entiteit te verzenden, versleutelt de afzender het bericht met behulp van de openbare sleutel van de entiteit. Dit versleutelde bericht kan alleen worden ontsleuteld met de privésleutel. Aangezien de privésleutel alleen beschikbaar is voor de beoogde ontvanger, zorgt dit ervoor dat alleen de ontvanger het bericht kan ontsleutelen.

Versleuteling met openbare en privésleutel

RSA gebruikt exponentiële berekeningen en de priemfactorisatie van zeer grote getallen, waardoor het zeer veilig maar ook rekenintensief is. Bovendien zou het implementeren van RSA in realtime - om latentie in communicatie te voorkomen - de systeemkosten verhogen omdat een verwerkingsengine met hogere prestaties nodig is. Veel embedded systemen hebben dit beveiligingsniveau niet nodig. In plaats daarvan kunnen ze een slanker coderingsalgoritme gebruiken, zoals Advanced Encryption Standard (AES), dat praktischer en kosteneffectiever is omdat er minder verwerkingsbronnen voor nodig zijn.

AES is een symmetrisch cryptografisch algoritme, wat betekent dat beide zijden van het communicatiekanaal een gemeenschappelijke geheime sleutel delen. De beperking van AES zoals hierboven vermeld, ligt in het veilig delen van de sleutel tussen de UART-zender en -ontvanger zonder deze bloot te stellen aan externe entiteiten. Om dit aan te pakken, kan RSA worden gebruikt om de AES-sleutel te versleutelen en veilig uit te wisselen. Omdat de gemeenschappelijke sleutel maar één keer hoeft te worden gedeeld, kan het communicatiekanaal de complexiteit en latentie van RSA dragen. Met andere woorden, de vertraging bij het verwerken van het RSA-algoritme heeft alleen invloed op de initiële sleuteluitwisseling, niet op elk bericht.

Veilige sleuteluitwisseling vindt plaats in verschillende fasen (Figuur 1). Ten eerste genereert de UART-ontvanger een RSA-sleutelpaar en deelt de openbare sleutel met de afzender. Het maakt niet uit of een andere entiteit de openbare sleutel ziet, omdat deze alleen wordt gebruikt om berichten te versleutelen die zijn bedoeld voor de UART-ontvanger. De afzender genereert vervolgens willekeurig een AES-sleutel en versleutelt deze met de openbare sleutel van de ontvanger. De ontvanger ontsleutelt de AES-sleutel met behulp van de RSA-privésleutel.

Figuur 1:Veilige uitwisseling van AES-geheime sleutel met openbare en privésleutels van RSA. (Bron:Infineon)

Omdat alleen de ontvanger toegang heeft tot de RSA-privésleutel, kan de versleutelde AES-sleutel alleen door de ontvanger worden ontsleuteld. Dit zorgt ervoor dat de AES-sleutel alleen bekend is bij de zender en de ontvanger en dat indringers met toegang tot het communicatiekanaal de sleutel niet kunnen achterhalen. Bovendien worden alle volgende berichten tussen zender en ontvanger versleuteld met de AES-sleutel, waardoor deze berichten ontoegankelijk zijn voor andere partijen die niet bedoeld zijn om ze te ontvangen. Dit elimineert ook de dreiging van man-in-the-middle-aanvallen (MIM), waarbij berichten worden gewijzigd nadat ze zijn verzonden maar voordat ze zijn ontvangen.

Firmware versus hardware

Het implementeren van beveiligingsalgoritmen in embedded apparaten met behulp van firmware brengt veel ontwerpuitdagingen met zich mee. Cryptografische algoritmen zijn van nature rekenintensief. Ze vergroten ook de geheugenvoetafdruk, voegen vertraging toe aan de verwerking en introduceren een aanzienlijke complexiteit voor systemen. Als gevolg hiervan zal het implementeren van beveiliging in firmware aanzienlijke CPU-cycli en MCU-bronnen verbruiken. Om te voldoen aan de real-time applicatievereisten, is bovendien een MCU met hogere prestaties vereist, waardoor de systeemkosten stijgen.

Een deel van de reden waarom zoveel MCU-bronnen worden gebruikt, is omdat MCU's verwerkingseenheden voor algemene doeleinden zijn. Om deze reden integreren veel MCU's hardware die speciaal is ontworpen voor cryptografische algoritmen. Met een geïntegreerde cryptografische engine kan een MCU realtime codering en decodering van gegevens bieden in een veel kleinere footprint en tegen lagere kosten in vergelijking met een MCU zonder op hardware gebaseerde cryptografische verwerkingsmogelijkheden.

De PSoC 6 MCU van Infineon is daar een goed voorbeeld van. Het heeft een speciaal cryptografisch blok dat hardwareversnelling van cryptografische functies biedt. Het cryptografische blok is flexibel en kan worden gebruikt om verschillende cryptografische algoritmen te ondersteunen om ervoor te zorgen dat de gegevens worden beschermd. Hierdoor kunnen ontwikkelaars beveiliging introduceren voor embedded IoT-apparaten met behulp van coderingsstandaarden zoals AES, DES, TDES en RSA en integriteitscontroles zoals beveiligd hash-algoritme ( SHA) en cyclische redundantiecontrole (CRC). Door op deze manier cryptografische functies van de MCU te ontlasten, is het mogelijk om op kosteneffectieve wijze beveiliging te introduceren in bijna alle embedded applicaties zonder dat een krachtigere processor nodig is.

Ware willekeurige getallen

Het beveiligen van een embedded systeem vereist echter meer dan alleen het versleutelen van communicatie. In het bijzonder moet de AES-sleutel die het systeem genereert willekeurig zijn. MCU's zijn echter deterministisch, dus de gegenereerde sleutels zouden ook deterministisch zijn, waardoor een hacker "brute kracht" kan gebruiken om door de verschillende mogelijke willekeurige zaden te bladeren en mogelijk de AES-sleutel af te leiden. Firmware heeft dus een manier nodig om echte willekeurige getallen te genereren om de willekeur van de AES-sleutel te garanderen, dus het kan niet brute-forced worden uitgevoerd.

Om dit te doen, moet het cryptografische blok een True Random Number Generator (TRNG) bevatten. In het cryptografische blok PSoC 6 heeft de TRNG bijvoorbeeld zes ringoscillatoren die fysieke ruisbronnen leveren. De ringoscillatoren bevatten temperatuurgevoelige inverters die jitter introduceren in het signaal van de ringoscillator. Dit signaal geeft de MCU toegang tot een echte willekeurige nummerbron om de willekeurigheid van de AES-sleutels die het genereert te garanderen.

Om bijvoorbeeld een sleutel van 16 bytes te genereren, wordt 16 keer een willekeurig getal gegenereerd en aan eerdere nummers toegevoegd. Dit zorgt voor de mogelijkheid van 2^128 sleutels. Het is meer dan genoeg om te voorkomen dat de "AES"-sleutel brute-forced of geraden wordt.

Sommige crypto-aanvallen zijn gericht op het analyseren van vastgelegde communicatie. Met voldoende middelen kan elke sleutel uiteindelijk worden verbroken. Om deze mogelijkheid aan te pakken en de algehele beveiliging van het communicatiekanaal te vergroten, wordt bij elke herstart de AES-sleutel gegenereerd. Dit is een eenvoudige maar effectieve maatregel om de beveiliging van embedded systemen te vergroten. Kortom, zelfs als een sleutel wordt geïdentificeerd door een indringer, zal de sleutel waarschijnlijk niet meer in gebruik zijn tegen de tijd dat deze kan worden misbruikt.

Veiligheid met vertrouwen

Op dit moment kan het verleidelijk zijn om de UART-interface als veilig te beschouwen. UART is echter een communicatieprotocol zonder ACK. Dit betekent dat het protocol geen mechanisme heeft om ervoor te zorgen dat een door de ontvanger ontvangen bericht a) zowel compleet als b) niet beschadigd is.

Een laatste beveiligingsfase is vereist om de integriteit van het bericht te bevestigen. Een effectieve methode om dit te bereiken is om het SHA-algoritme te gebruiken om het bericht te hashen. Een bericht door een cryptografische hashfunctie zoals SHA laten lopen, produceert een hash, een uitvoer met een vaste lengte. Omdat hashfuncties onomkeerbare eenrichtingsfuncties zijn, is de enige manier om het bericht te identificeren dat een bepaalde hash heeft gegenereerd, een poging tot brute force-zoektocht van alle mogelijke invoer.

Figuur 2:Een hash-functie zorgt voor de integriteit van communicatie tijdens veilige sleuteluitwisselingen en berichtoverdrachten. (Bron:Infineon)

Voordat een bericht wordt verzonden, wordt de hash van het gehele bericht aan het bericht toegevoegd (Figuur 2). Het bericht plus hash wordt vervolgens versleuteld met de AES-sleutel. Op deze manier kan de hash dienen als integriteitscontrole. De ontvanger berekent, na het ontsleutelen, de hash van het bericht dat het ontsleuteld heeft. De ontvanger vergelijkt vervolgens de ontvangen hash en de berekende hash. Als ze hetzelfde zijn, is het bericht niet gewijzigd. Als de hashes echter niet overeenkomen, geeft dit aan dat de integriteit van het bericht is aangetast. Dit kan gebeuren omdat een hacker heeft geprobeerd het bericht te wijzigen of omdat er een fout is opgetreden tijdens de verzending. In ieder geval is de communicatie mislukt.

Merk op dat het communicatiekanaal verder kan worden versterkt voor authenticiteit door het bericht te ondertekenen met de privésleutel van de afzender. Het ondertekende bericht kan worden geverifieerd met behulp van de openbare sleutel van de afzender om te verifiëren dat alleen de afzender het bericht kan hebben verzonden. Anders gezegd, geen enkele andere partij kan de afzender nabootsen, omdat ze niet de privésleutel van de afzender hebben, waardoor de authenticiteit van de berichten wordt gegarandeerd. Bekijk voor meer ideeën de Community Code-voorbeelden, die veel projecten van andere ingenieurs bevatten.

Het implementeren van beveiliging is een noodzakelijke overweging geworden bij het ontwerp van embedded IoT-systemen. Het is van cruciaal belang dat elk aangesloten apparaat veilig is en dat gebruikersgegevens worden beschermd tegen compromittering. Met cryptografische blokken die in MCU's zijn geïntegreerd, is het voor ontwikkelaars mogelijk geworden om elk communicatiekanaal te beveiligen, inclusief interfaces zoals UART die zelf geen beveiliging bieden.

—Harigovind A en Rakshith MB zijn senior applicatie-ingenieurs bij Infineon Technologies.

>> Dit artikel is oorspronkelijk gepubliceerd op onze zustersite, EDN .