Uanset om det drejer sig om krypteret kode eller frit tilgængelige data, så vil en ekstern memory ofte være en fremragende partner til værtscontrolleren i embeddede designs
Artiklen har været bragt i Aktuel Elektronik nr. 3 – 2025 og kan læses herunder uden illustrationer
(læs originaludgaven her)
Af Giancarlo Parodi, principal product marketing engineer, Renesas Electronics
Memory-kravene i embeddede systemer vokser konstant som følge af kravene om mere funktionel konnektivitet og en øget kompleksitet på applikationsniveau. Mange af markedets mikrocontrollere (MCU’er) har en memory-kapacitet på en håndfuld Mbytes – og går vi et årti tilbage i tiden, ville det have været rigeligt samt nok til at fremtidssikre den typiske applikation. Integration af stadigt mere non-volatil memory kræver et stort siliciumareal, og det er selvfølgelig ikke gratis, så en større memory påvirker prisen betydeligt. En egnet alternativ løsning er at bruge en ekstern memory, der kan købes i store volumener til relativt lavere priser og med en lang række densiteter fra nogle få Bytes til dusinvis af Megabytes.
Den eksterne memory-løsning egner sig til mere end bare applikationsdata. Den kan også lagre applikationskode og dermed fjerne al tvivl om, hvilken leverandør der er i stand til at opfylde fremtidige behov. Der er dog visse forhold, som man er nødt til at lægge oven i sine betragtninger, såsom hvorvidt man kan udføre kodeeksekvering fra den eksterne memory – og hvordan man beskytter applikationskoden mod kloning eller modificeringer.
I det første problem er løsningen nok at bruge en memory med et bredt interface, hvilket øger det fysiske throughput for de serielle linjer. Memories med et oktalt interface (OctaSPI) er ét af de bedste valg med hensyn til tradeoffs mellem antallet af I/O-forbindelser samt en opnåelig faktor 2-forbedring i forhold til en typisk quad SPI-løsning. Den slags moderne memories supporterer også en lidt højere driftsfrekvens, så ydelsesforbedringen bliver endnu mere tydelig.
Hurtig ”dekryptering on-the-fly”
Beskyttelse af en memorys indhold kræver kryptografi af koden, da det ellers ville være alt for let for en hacker at forbinde sig til memoryen og udlæse den lagrede information. For at undgå latency i dekrypteringen skal man benytte designløsninger, der er hurtige og udført på samme måde som fetch-instruktioner – med andre ord på en måde, der er transparent for CPU’en. De nyeste Renesas MCU’er som RA8x1-serien har implementeret en såkaldt ”decryption-on-the-fly” (DOTF) arkitektur, der netop udfører denne opgave. En konceptual repræsentation af løsningen kan ses i figur 1.
Princippet er ret enkelt og er baseret på en AES-krypterings-/dekrypteringsstandard med en counter-mode (CTR) som specificeret i NIST SP800-38A. Princippet i CTR-metoden er vist i figur 2.
I CTR-tilstand bruges et sæt counters/tællere som input til en cifferblokfunktion, der genererer et hemmeligt output, der så bliver exclusive-OR’ed med en plaintext (eller ciffertekst) til kryptering (eller dekryptering) af data i beskeden. Sekvensen af counters skal vælges, så enhver input-blok i et sæt er forskellig fra andre og unik. Dette krav gælder alle ”beskeder” (som dataemner), der bliver krypteret med brug af den samme nøgle.
En fin egenskab ved CTR-metoden er, at de cifferfunktioner, der hænger sammen med counteren, kan eksekveres indledningsvis og indbyrdes uafhængigt – og uden at skulle vente på en ledig datablok. Det hjælper til at reducere latency under read-out af krypterede data fra oktal-memoryen, da generering af en output-blok kan ske parallelt. En given blok i klartekst kan ydermere hentes uafhængigt fra enhver anden blok, hvilket er praktisk, når man skal hente (fetche) programdata, der er afhængige af det programflow, processoren måtte spørge efter, for at læse kode på non-sekventielle adresselokationer.
De parametre, som definerer counterne, skal derfor vælges omhyggeligt for at sikre, at de er unikke. En AES-blok er 16 bytes (128 bits) stor, og derfor skal counteren også være 128-bits bred. Hver krypteret blok i memoryen er også alignet til 16 bytes og danner en unik counter som en serie af den initiale værdi og den memory-adresse, der kan anvendes.
Den initiale værdi, grundlæggende en ”nonce” (unikt éngangstal), og adressen for den krypterede blok, der bliver læst, har de fire (4) LSB’er (Least Significant Bits) maskeret for at danne en counter-værdi efter det følgende skema: counter [127:0] = InitialValue [127:28] || (MemoryAddress [31:4] >> 4).
Der er et par andre interessante funktioner i denne implementering, der er meget brugbare, når man skal danne en fleksibel og brugervenlig løsning. Først og fremmest kan applikationen definere en adresse-boundary, hvortil dekrypteringen on-the-fly (DTOF) vil blive brugt – eller i modsat fald blive bypassed – som vist i figur 3.
Partitionering mellem krypteret kode og ukrypterede data
DTOF’s adresse-boundary er meget praktisk, hvis man i applikationen vil partitionere flashens indhold mellem kode og andre data, så koden bliver dekrypteret on-the-fly, mens data blot bliver læst uden dekryptering. Sidstnævnte gør det også muligt for applikationen at anvende en anden nøgle eller krypteringstilstand for data, så man undgår at dele applikationskodens krypterings-/dekrypteringsnøgle til flere forskellige formål.
For definitionen af DOTF-området – selv om AES-krypteringsstandarden indikerer en minimum-alignment på 16 bytes med afsæt i en given, typisk organisering af flash-memoryen – så skal boundaryen placeres i en sektor eller en blokstørrelse (den mindste flash-unit størrelse, der kan slettes (erases) under programmering). I den implementering kan DOTF-boundaryen konfigureres til en 4KB adresse-alignment, og reelt skal applikationen alligevel undgå at have lagring af både DOTF- og non-DOTF-data i en memory-blok, hvad der i modsat tilfælde ville gøre opgraderinger i felten og fabriksprogrammering unødvendigt kompliceret.
Flash-memoryen bliver mapped lineært ind i den adressérbare plads i MCU’en, og Octa-IP’en sørger for at udstede de relevante read-kommandoer – typisk som en såkaldt XiP (eXcute-in-Place) operation. Ved enhver form for krypteret adgang til et områdes adspurgte 16-byte blokke med effektiv adgang én gang til den ønskede adresse – og en kontinuert udlæsning af data, reducerer man med OctaSPI-protokollens overhead til et minimum.
Endnu et vigtigt aspekt er håndtering og loading af dekrypteringsnøglen. I devices, der supporterer DOTF, er der en dedikeret AES-engine implementeret i IP’en, men nøglen til dekrypteringsprocessen bliver loaded over en privat busforbindelse til Renesas’ secure IP. På den måde undgår man lækager af nøgleværdien over den interne MCU-businterconnect. Desuden bliver de nøgler, som håndteres af Renesas’ secure IP selv krypterede, så de kan lagres sikkert i memoryen uden bekymringer om pålidelighed og integritet.
DOTF’s engine supporterer 128-, 192- og 256-bit store nøgler for maksimal fleksibilitet og fremtidssikring, og der er ingen grænser for antallet af forskellige nøgler, som kan bruges til dekryptering af et specifikt billede. Sidstnævnte peger på, at enhver firmware-opdatering om ønsket kan bruge en forskellig nøgle, og der er ikke behov for nøgledeling mellem forskellige MCU’er. Forberedelse af et nyt billede kan meget praktisk gøres offline på en sikker vært, før man sender en billedopdatering til et produkt i felten – eller til at sende det krypterede billede til en EMS-virksomhed for programmering af et nyt produkt. Den initiale dekrypteringsnøgle eller ”nøgleopdateringsnøgle” (for opdatering af dekrypteringsnøglen i felten) kan injiceres sikkert i MCU’en under produktion. Injicerede nøgler – uanset om det er i felten eller under produktion – er altid bundet op mod en specifik MCU, hvilket forhindrer kloning.
Endelig indeholder IP’en modforholdsregler, der forhindrer sidekanalsangreb.
Al runtime-operation bliver udført transparent af hardwaren, og de medleverede softwaredrivere sørger for at initiere og uploade parametrene for DOTF-driften (initial-værdi og boundaries) samt nøglen, før driften kan sættes i gang.
Alle MCU’er, der kræver mulig udvidelse af memoryen, og som følger komplekse applikationskrav vil have store fordele af den nævnte løsning, da den giver MCU-udvikleren bekvem adgang til en robust applikations-roadmap med en samtidig beskyttelse af investeringen i softwaren. For flere informationer om RA MCU-familien, se venligst: http://www.renesas.com/ra.
Billedtekster:
Figur 1: DOTF-arkitekturen.
Figur 2: CTR-metoden. (Kilde: NIST SP800-38A).
Figur 3: DOTF-boundaries.
