În prezent, cerințele de memorie ale sistemelor embedded cresc constant, ca urmare a creșterii nivelului de conectivitate și a complexității aplicațiilor. Multe microcontrolere de pe piață oferă o densitate a memoriei de ordinul a câțiva megabytes, care în urmă cu doar un deceniu ar fi fost considerată mai mult decât suficientă și sigură pentru aplicații de nivel mediu. Pe de altă parte, integrarea unei cantități și mai mari de memorie nevolatilă necesită o suprafață de siliciu destul de mare, ceea ce are un impact semnificativ asupra costului produsului. O soluție alternativă acceptabilă este utilizarea memoriei externe, care poate fi achiziționată la prețuri comparabil mai mici și cu mai multe opțiuni de densitate, de obicei, pornind de la câțiva la zeci de megaocteți.
Soluția de memorie externă este adecvată nu numai pentru a stoca datele, ci și codul aplicației, eliminând, prin urmare, orice preocupare cu privire la foaia de parcurs a furnizorului pentru a putea satisface nevoile viitoare. Pe de altă parte, trebuie luate în considerare și alte aspecte, cum ar fi performanța codului care se execută din memoria externă și modul de protejare a codului de aplicație împotriva clonării sau modificării.
Referitor la prima problemă, soluția constă în utilizarea unei memorii cu o interfață amplă, care crește debitul fizic pentru liniile seriale. Memoriile cu o interfață octală oferă una dintre cele mai bune opțiuni în ceea ce privește compromisul dintre numărul de conexiuni IO și îmbunătățirea de 2x a ratei de transfer în comparație cu vechea interfață quad-spi. În mod normal, aceste memorii moderne suportă și frecvențe de operare ușor mai mari, astfel încât îmbunătățirea performanței este și mai semnificativă.
Figura 1: Arhitectura DOTF. (Sursă imagine: Renesas)
Protejarea conținutului memoriei necesită utilizarea tehnicilor de criptografie pentru criptarea codului, deoarece, în caz contrar, ar fi ușor pentru un atacator să se conecteze la memorie și să citească informațiile stocate, cu un efort minim. Pentru a evita latențele procesului de decriptare, este necesar să se utilizeze soluții de proiectare, care să fie rapide și realizate în conformitate cu procesul de preluare a instrucțiunilor, cu alte cuvinte transparente din perspectiva CPU. Cele mai recente microcontrolere de la Renesas, cum ar fi seria RA8x1, implementează o așa-numită arhitectură DOTF (decryption on the fly) care servește exact acestui scop. O reprezentare conceptuală a soluției poate fi analizată în figura 1.
Principiul este destul de simplu și se bazează pe standardul de criptare/decriptare AES, utilizând modul CTR (Counter Mode), așa cum se specifică în NIST SP800-38A. Principiul de operare în modul CTR este prezentat în figura 2.
Figura 2: Modul CTR. (Sursă imagine: NIST SP800-38A)
În modul CTR, se utilizează un set de contoare ca intrare pentru o funcție de cifrare în bloc, pentru a genera o ieșire secretă care este apoi combinată cu textul original (sau cu textul cifrat) printr-o operație “exclusive-ORed” pentru a cripta (sau decripta) datele mesajului. Secvența de contoare trebuie aleasă astfel încât fiecare bloc de intrare din set să fie diferit și unic. Această cerință este valabilă pentru toate “mesajele” (adică seturile de date) care sunt criptate folosind aceeași cheie.
O proprietate interesantă a modului CTR este că funcțiile de criptare asociate contorului pot fi efectuate în avans, independent unele de altele și nu trebuie să aștepte ca blocul de date să fie disponibil. Acest lucru contribuie la reducerea latenței în timpul citirii datelor criptate din memoria octa, deoarece generarea blocului de ieșire poate fi efectuată în paralel. De asemenea, un anumit bloc de text original (plaintext) poate fi recuperat independent de orice alt bloc, ceea ce este convenabil pentru preluarea datelor programului, deoarece, în funcție de fluxul programului, procesorul poate solicita citirea codului în locații de adrese nesecvențiale.
Parametrii utilizați pentru definirea contoarelor trebuie să fie aleși cu atenție pentru a asigura unicitatea acestora. Un bloc AES are o dimensiune de 16 octeți (128 biți); prin urmare, contorul trebuie să aibă, de asemenea, o lățime de 128 biți. Fiecare bloc criptat din memorie este, de asemenea, aliniat la 16 octeți (bytes), iar pentru a crea un contor unic se poate utiliza o concatenare a unei valori inițiale și a adresei de memorie.
Valoarea inițială este, în esență, un nonce (număr unic, aleatoriu, utilizat o singură dată), iar adresa blocului criptat care se citește are cei 4 biți LSB mascați, pentru a crea valoarea contorului conform următoarei scheme: counter [127:0] = InitialValue [127:28] || (MemoryAddress [31:4] >> 4).
Există câteva alte caracteristici interesante în implementare, care sunt foarte utile pentru a face din aceasta o soluție flexibilă și ușor de utilizat. În primul rând, aplicația poate defini o limită de adresă pentru care va fi utilizată decriptarea “on the fly” sau va fi ocolită, după cum se arată în figura 3.
Figura 3: Limitele DOTF. (Sursă imagine: Renesas)
Acest lucru este foarte convenabil în cazul în care aplicația dorește să împartă conținutul flash între cod și alte date, unde codul este decriptat din mers, iar datele sunt citite pur și simplu fără a fi decriptate. Aceasta din urmă permite, de asemenea, aplicației să utilizeze o altă cheie sau un alt mod de criptare pentru date și evită partajarea cheii de criptare/decriptare a codului aplicației în scopuri multiple.
În ceea ce privește alinierea zonei DOTF, chiar dacă standardul de criptare AES implică o aliniere minimă de 16 bytes, având în vedere organizarea tipică a unei memorii flash, limita va fi plasată mai degrabă pe un sector sau dimensiunea unui bloc (dimensiunea minimă a unității de memorie flash care poate fi ștearsă în timpul programării). În implementare, limita DOTF este configurabilă pentru o aliniere a adreselor de 4KB; de fapt, aplicația trebuie, oricum, să prevină existența unui bloc de memorie care să stocheze atât date DOTF, cât și date non-DOTF, ceea ce ar complica inutil actualizările pe teren și programarea în fabrică.
Dispozitivul de memorie flash este mapat liniar în spațiul adresabil al microcontrolerului, iar Octa IP se ocupă de emiterea comenzilor de citire corespunzătoare. Acest mod de operare se numește, de obicei, XiP (execute-in-place). Pentru zona criptată, orice acces la blocurile de 16 octeți solicitate poate fi realizat eficient prin emiterea, o singură dată, a adresei necesare și apoi prin citirea continuă a datelor, reducând astfel la minimum supraîncărcarea protocolului OctaSPI.
Un alt aspect important este modul în care este gestionată și încărcată cheia de decriptare. În dispozitivele care acceptă DOTF, există un motor AES dedicat implementat în cadrul IP-ului, dar cheia pentru procesul de decriptare este încărcată printr-o conexiune de bus privată la IP-ul securizat Renesas; astfel se evită scurgerea valorii cheii prin interconectarea internă a busului microcontrolerului. În plus, cheile gestionate de IP-ul securizat Renesas sunt ele însele criptate, astfel încât acestea pot fi stocate în siguranță în memorie fără probleme de confidențialitate și integritate.
Motorul DOTF acceptă chei de 128-, 192- și 256- biți pentru flexibilitate maximă și opțiuni de viitor, neexistând nicio limită privind numărul de chei diferite care pot fi utilizate pentru decriptarea unei anumite imagini. Acest lucru presupune că orice actualizare de firmware poate utiliza o cheie diferită, dacă se dorește, și nu este necesar să se partajeze aceeași cheie între microcontrolere diferite. Pregătirea noii imagini se poate face offline, pe o gazdă securizată, înainte de a trimite actualizarea imaginii către un dispozitiv de pe teren sau de a trimite imaginea criptată către un producător contractual pentru programare. Cheia inițială de decriptare sau o “cheie de actualizare a cheii” (pentru actualizarea cheii de decriptare pe teren) poate fi injectată în siguranță în microcontroler în timpul producției. Cheile injectate, fie pe teren, fie în faza de producție, sunt legate întotdeauna de microcontrolerul în cauză, astfel încât clonarea este împiedicată.
În plus, IP-ul oferă contramăsuri de protecție împotriva atacurilor prin canale laterale.
Toate operațiunile în timpul rulării sunt efectuate transparent de hardware, iar driverele software furnizate au grijă să inițializeze și să încarce parametrii pentru operațiunea DOTF (valoarea inițială, limitele) și cheia, înainte ca operarea să poată începe.
Toate microcontrolerele care necesită extinderea memoriei și cerințe complexe pentru aplicații vor beneficia de un astfel de tip de soluție, care asigură dezvoltatorului microcontrolerului o foaie de parcurs solidă pentru aplicații și, în același timp, protejează investiția în software. Pentru mai multe informații despre familia de microcontrolere RA, vă rugăm să vizitați pagina: www.renesas.com/ra.
Autor: Giancarlo Parodi,
Principal Product Marketing Engineer
Renesas Electronics Europe | https://www.renesas.com
