Renesas Electronics Corporation
Avtor: Giancarlo Parodi, glavni inženir za trženje izdelkov, Renesas Electronics
Dandanes ugnezdeni sistemi zaradi vse večje funkcionalnosti povezljivosti in kompleksnosti aplikacij nenehno povečujejo svoje pomnilniške zahteve. Številni mikrokontrolerji na trgu zagotavljajo gostoto pomnilnika v obsegu nekaj megabajtov, kar bi še pred desetletjem veljalo za več kot zadostno in varno za prihodnost za povprečno aplikacijo.
Po drugi strani pa je za vključitev še večje količine nevolatilnega pomnilnika potrebna precej velika površina silicija, kar znatno vpliva na ceno izdelka. Primerna alternativna rešitev je uporaba zunanjega pomnilnika, ki ga je mogoče kupiti v večjih količinah po primerljivo nižjih cenah in z več možnostmi gostote, običajno od nekaj do nekaj deset megabajtov.
Rešitev zunanjega pomnilnika ni primerna le za shranjevanje podatkov o aplikacijah, temveč tudi kode aplikacij, zato ni več skrbi glede časovnega načrta dobavitelja, da bi lahko izpolnil prihodnje potrebe. Po drugi strani pa je treba upoštevati nekatere dodatne vidike, kot sta zmogljivost kode, ki se izvaja iz zunanjega pomnilnika, in kako zaščititi aplikacijsko kodo pred kloniranjem ali spreminjanjem. Pri prvem problemu je rešitev uporaba pomnilnika s širokim vmesnikom, ki poveča fizično prepustnost zaporednih linij. Pomnilniki z osmerokotnim vmesnikom so ena najboljših izbir v smislu kompromisa med številom IO povezav in dosegljivim 2-kratnim izboljšanjem prepustnosti v primerjavi z dosedanjim quad-spi vmesnikom. Običajno takšni sodobni pomnilniki podpirajo tudi nekoliko višje delovne frekvence, tako da je izboljšanje zmogljivosti še večje.
Za zaščito vsebine pomnilnika je treba uporabiti kriptografske tehnike za šifriranje kode, saj bi se sicer napadalec zlahka povezal s pomnilnikom in z malo truda prebral shranjene informacije. Da bi se izognili zakasnitvam postopka dešifriranja, je treba uporabiti konstrukcijske rešitve, ki so hitre in se izvajajo v skladu s postopkom pridobivanja ukazov, kar pomeni, da so z vidika procesorja pregledne. Najnovejši Renesasovi MCU-ji, kot je serija RA8x1, implementirajo tako imenovano arhitekturo „dešifriranja v teku“ (DOTF), ki služi prav temu namenu. Konceptualni prikaz rešitve je prikazan na sliki 1. Načelo je zelo preprosto in temelji na standardu šifriranja/dešifriranja AES z uporabo načina števca (CTR), kot je določeno v dokumentu NIST SP800-38A. Načelo delovanja načina CTR je prikazano na sliki 2. V CTR načinu se niz števcev uporablja kot vhod za funkcijo blokovnega šifriranja, da se ustvari tajni izhod, ki se nato preko EX-OR vrat poveže z odprtim besedilom (ali šifrirnim besedilom) za šifriranje (ali dešifriranje) podatkov sporočila. Zaporedje števcev mora biti izbrano tako, da je vsak vhodni blok v nizu drugačen in edinstven. Ta zahteva velja za vsa „sporočila“ (tj. podatkovne elemente), ki se šifrirajo z istim ključem.
Dobra lastnost načina CTR je, da se lahko šifrirne funkcije, povezane s števcem, izvedejo vnaprej, neodvisno ena od druge, in ni treba čakati, da je na voljo podatkovni blok. To pomaga zmanjšati zakasnitve pri branju šifriranih podatkov iz okta pomnilnika, saj lahko generiranje izhodnega bloka poteka vzporedno. Prav tako je mogoče določen blok čistega besedila obnoviti neodvisno od katerega koli drugega bloka, kar je priročno za pridobivanje programskih podatkov, saj lahko procesor glede na potek programa zahteva branje kode na lokacijah, ki si ne sledijo po naslovih.
Parametre, ki se uporabljajo za opredelitev števcev, je treba skrbno izbrati, da se zagotovi njihova edinstvenost. Blok AES je velik 16 bajtov (128 bitov), zato mora biti tudi števec širok 128 bitov. Vsak šifrirani blok v pomnilniku je prav tako poravnan na 16 bajtov, zato se za ustvarjanje edinstvenega števca lahko uporabi združevanje začetne vrednosti in pomnilniškega naslova.
Začetna vrednost je v bistvu nonce (edinstveno naključno število, ki se uporabi enkrat), naslov šifriranega bloka, ki se bere, pa ima zamaskirane 4 LSB, da se ustvari vrednost števca po naslednji shemi: števec [127:0] = InitialValue [127:28] || (MemoryAddress [31:4] >> 4). Izvedba ima še nekaj zanimivih funkcij, ki so zelo koristne, saj omogočajo prilagodljivo in uporabniku prijazno rešitev. Prvič, aplikacija lahko določi naslovno mejo, za katero se bo uporabilo dešifriranje v teku ali pa se bo drugače zaobšlo, kot je prikazano na sliki 3.
To je zelo priročno, če želi aplikacija razdeliti vsebino Flash pomnilnika na kodo in druge podatke, pri čemer se koda dešifrira sproti, podatki pa se preprosto preberejo brez dešifriranja. Slednje aplikaciji omogoča tudi uporabo drugega ključa ali načina šifriranja za podatke in preprečuje deljenje ključa za šifriranje/dešifriranje kode aplikacije za več namenov.
Čeprav standard šifriranja AES predvideva najmanjšo poravnavo območja DOTF 16 bajtov, je glede na tipično organizacijo Flash pomnilnika meja raje postavljena na velikost sektorja ali bloka (najmanjša velikost Flash enote, ki se lahko izbriše med programiranjem). V izvedbi je meja DOTF nastavljiva na poravnavo naslovov 4KB; aplikacija se dejansko izogne temu, da bi imel pomnilniški blok shranjene podatke DOTF in podatke, ki niso DOTF, kar bi po nepotrebnem otežilo posodobitve na terenu in tovarniško programiranje. Pomnilniška Flash naprava je linearno preslikana v naslovni prostor MCU-ja, IP Octa pa poskrbi za izdajo ustreznih ukazov za branje, kar se običajno imenuje XiP (execute-in-place) način delovanja. Pri šifriranem območju se lahko vsak dostop do zahtevanih 16-bajtnih blokov učinkovito izvede z enkratnim izdajanjem zahtevanega naslova in nato s kontinuiranim branjem podatkov, s čimer se režijski stroški protokola OctaSPI zmanjšajo na minimum.
Drug pomemben vidik je, kako se obdeluje in nalaga dešifrirni ključ. V napravah, ki podpirajo DOTF, je namenski mehanizem AES implementiran znotraj IP, vendar se ključ za postopek dešifriranja naloži prek zasebne povezave vodila z varnim IP podjetja Renesas; s tem se prepreči uhajanje vrednosti ključa prek notranje povezave MCU vodila. Poleg tega so ključi, ki jih obdeluje Renesasov varni IP, tudi sami šifrirani, zato jih je mogoče varno shraniti v pomnilnik brez skrbi glede zaupnosti in celovitosti.
DOTF podpira 128-, 192- in 256-bitne ključe za največjo prilagodljivost in izbiro v prihodnosti, število različnih ključev, ki jih je mogoče uporabiti za dešifriranje določene slike, pa ni omejeno. Slednje pomeni, da lahko vsaka posodobitev ugnezdene programske opreme po želji uporabi drugačen ključ in da ni treba deliti istega ključa med različnimi MCU-ji. Pripravo nove slike je mogoče priročno opraviti brez povezave na varnem gostitelju, preden se posodobitev slike pošlje napravi na terenu ali pošlje šifrirana slika pogodbenemu proizvajalcu v programiranje. Začetni dešifrirni ključ ali „ključ za posodobitev ključa“ (za posodobitev dešifrirnega ključa na terenu) se lahko med proizvodnjo varno vnese v MCU. Vneseni ključi, bodisi na terenu bodisi v fazi proizvodnje, so vedno vezani na določeno enoto MCU, tako da je kloniranje onemogočeno.
Poleg tega so v IP zagotovljeni protiukrepi za zaščito pred napadi stranskih kanalov.
Vse operacije med izvajanjem pregledno opravi strojna oprema, zagotovljeni programski gonilniki pa poskrbijo za inicializacijo in nalaganje parametrov za DOTF operacijo (začetna vrednost, meje) in ključa, preden se operacija lahko začne izvajati.
Takšna rešitev bo koristila vsem MCU-jem, ki zahtevajo razširljivost pomnilnika in kompleksne zahteve aplikacij, kar razvijalcem MCU-jev zagotavlja zanesljiv načrt uporabe, hkrati pa varuje naložbe v programsko opremo. Za več informacij o družini RA MCU obiščite www.renesas.com/ra.
