Den sista tiden har det kommit flera intressanta artiklar om säkerhet i inbyggda system och system på chip (SoC). Har läst igenom artiklarna och tänkte nu tipsa och kommentera.

I artikeln Start your crypto engine—cryptographic acceleration in SoCs pÃ¥ EE Times sidoplats om inbyggda system Embedded.com beskrivs olika sätt att accelerera kryptofunktioner för att säkra kommunikationen till och frÃ¥n sitt chipsystem. Problemet artikeln tar upp är att behovet av att skydda kommunikationen för inbyggda system snabbt har ökat. Skälet till detta beror som jag ser det pÃ¥ tvÃ¥ saker:

1. Allt fler inbyggda system kopplas upp mot publika nät – Internet, detta för att göra det enklare för legitima användare att utnyttja, styra och övervaka systemet.


2. Det direkt ekonomiska värdet som systemen utgör har ökat – vi har i dag elmätare, betalautomater, kortläsare, bensinpumpar och allt möjligt tillgängligt pÃ¥ nätet, maskiner som om dom gÃ¥r att hacka direkt kan ge ekonomiska vinster till skurken.

Tyvärr innebär kraven på ökad säkerhet att det inbyggda systemet behöver bättre prestanda och ny funktionalitet. Detta kostar pengar och frågan är hur man tillför detta på bästa och billigaste sätt.

Artikeln berättar att prestandabehovet för 3DES-krypering på en 32-bits processor är ca 30 MIPS/Mbps, för AES-128 är det 10 MIPS/Mbps. För en ARM-processor som går i 66 MHZ innebär det att med kommunikation på en Mbps är halva processorkapaciteten förbrukad. Använder du en PIC, en AVR eller annan mindre 8- eller 16-bit processor har du knappast ens den mängden resurser totalt.

Skall du använda IPsec, SSL eller andra kompletta IT-säkerhetsstandarder krävs även stöd envägsfunktioner för signaturer och assymetriska krypton för nyckelutbyte. Detta ställer stora krav pÃ¥ utrymme för programkod och stöd för relativt avancerade bitoperationer och matematik. För att fÃ¥ in detta i sitt system pÃ¥ ett effektivt sätt som inte sänker produkten kommersiellt krävs alltsÃ¥ nÃ¥got slags anpassat stöd – avlastning helt enkelt.

Artikeln tar upp tre metoder:

1. Utökning av processorns instruktionsuppsättning med applikationsanpassade instruktioner.


2. Enklare slavenhet.


3. Avancerad co-processor.

Artikeln avfärdar snabbt det första alternativet då detta innebär assemblerkodning för att använda instruktionerna. Dock är det så att de företag som erbjuder processorer med stöd för utökning av instruktionsuppsättningen, exempelvis Tensilica, Altera och ARC automatiskt anpassar sina programutvecklingsmiljöer, vilket drastiskt reducerar behovet av assemblerprogrammering. Vidare är det fortfarande ganska vanligt att utvecklare av inbyggda system kodar små, specifika funktioner i assembler så jag anser inte det vara ett speciellt stort krav.

Alternativ tvÃ¥ är det jag ser som vanligast. Det normala systemet utökas med en kryptomodul som exempelvis implementerar AES. Sedan är det upp till processorn att via register skriva in nycklar och data och rycka i spakarna sÃ¥ att kryptomodulen krypterar eller dekrypterar efetr behov. Ett bekymmer med detta, vilket artikeln tar upp, är att om läsning och skrivning av register för att styra och övervaka kryptomodulen tar mycket tid blir vinsten av att använda kryptomodulen inte sÃ¥ stor. Tar det exempelvis Ã¥tta skrivningar för att sätta upp modulen och man kör kryptering med AES-128 tar körningen troligen 12 cykler (en cykel per varv med samtidig nyckelexpansion ). I detta fallet är chansen stor att man inte tjänade mer än fyra cykler – och dÃ¥ skall skrivningarna utföras pÃ¥ en cykel.

Sista alternativet är att använda en mer komplex co-processor. Co-processorn innehÃ¥ller funktionalitet för att självständigt hantera en kedja av operationer – kryptering, autenticiering, paketering etc. Det enda processorn behöver göra är att ge co-processorn en pekare till en struktur i minnet som anger var i minnet data finns, operationer som skall utföras och sedan arbetar co-processorn självständigt. Mycket smidigt och detta är pÃ¥ samma sätt som fristÃ¥ende co-processorer frÃ¥n exempelvis Broadcom och Hifn arbetar.

Det som artikeln inte tar upp för fall tre är att detta samtidigt innebär att om systemets minne är en gemensam resurs för huvudprocessorn och co-processorn finns det helt plötsligt en resursdelningproblematik i systemet. Om co-processorn använder DMA för att flytta data kan dessa accesser blockera huvudprocessorns accesser. Systemet har gått ifrån ett enkelt system med statisk accesstid till ett system med stokastisk accesstid. Som konsekvens måste du kanske flytta in interruptrutinerna till ett för huvudprocessorn privat minne. Din systemdesign blev plötsligt mycket besvärligare.

Och det är kanske det som är kontentan av artikeln (fast författarna inte skriver det): Skall du börja säkra upp kommunikationen för ditt system på chip kommer systemdesignen att påverkas på ett eller annat sätt. Säkerhet ställer helt enkelt nya krav, och det är inte bara blint spika fast säkerhetsfunktionerna på den befintliga konstruktionen.