Regula de bază tradițională conform căreia securitatea este „adecvată”, dacă ar necesita mai mult efort pentru a compromite un sistem decât ar putea câștiga atacatorul din acest lucru, devine, de asemenea, problematică odată cu creșterea conectivității. Un atacator ar putea avea puțin de câștigat în ceea ce privește accesul la funcția primară a unui sistem embedded, al cărui scop ar putea fi controlul a ceva, relativ, banal. Dar astfel de sisteme pot fi de neprețuit pentru cei rău intenționați, deoarece gateway-uri vulnerabile pot oferi acces la o infrastructură mai largă.
“În următorii cinci ani, eu văd securitatea ca o provocare majoră pentru industrie.” – Laurent Vera, STMicroelectronics
Problema securității a devenit multidimensională. Există problema securității IP; cum se protejează proiectul sistemului embedded împotriva furtului și copierii; adică pentru a preveni copierea programului și clonarea proiectului. Apoi, trebuie protejată funcționalitatea prevăzută a sistemelor; proiectul ar trebui să fie sigur împotriva acțiunilor de schimbare a modului de funcționare, în încercarea de a-l face să funcționeze într-un mod nedorit. Desigur, datele pe care sistemul este destinat, în primul rând, să le manipuleze, ar trebui să fie protejate împotriva copierii, la fel ca și detaliile (dacă sunt relevante) ale tuturor utilizatorilor sistemului. După cum s-a menționat mai sus, un atacator nu ar trebui să poată utiliza sistemul embedded ca punct de intrare pentru a obține acces la o infrastructură IT mai largă.
“Conectivitatea fiind omniprezentă, acum, securitatea datelor și a rețelelor sunt vitale.” – Jack Ogawa, Cypress Semiconductor
La toate acestea, s-a adăugat recent o nouă amenințare; posibilitatea furtului de cicluri de calcul dintr-un sistem (embedded sau altfel). Acesta este fenomenul „criptojacking”, în care un script este adăugat la funcționarea normală a sistemului țintă, iar în fundal rulează algoritmi de „minare” a cripto-monedei, raportând în liniște rezultatele sale prin orice port deschis pe care îl poate accesa și îmbogățindu-i pe autori. Efectele pot fi destul de insidioase; nu se fură date, nu se compromite confidențialitatea, nu se inițiază acțiuni rău intenționate: singurul efect este că ciclurile procesorului „lipsesc”. Pentru un sistem embedded, care trebuie să prezinte un răspuns în timp real sau aproape în timp real, problema este vizibilă ca o lipsă de performanță într-un moment critic. Anecdotic, acest lucru a fost văzut în principal implementat prin intermediul codului ascuns pe paginile web. Cu toate acestea, nu este dificil să ne imaginăm un sistem embedded dezvoltat în jurul unei distribuții Linux, lăsat din greșeală cu o conexiune la internet neprotejată, care ar putea fi găsită și exploatată. Într-un mod similar, sistemele cu conectivitate la internet sunt deschise pentru a fi preluate ca „roboți software”, devenind motoare ale atacurilor unei terțe părți.
“Avem nevoie, de asemenea, de cerificare. Astăzi, cerințele minime sunt definite de furnizorii de cloud, de exemplu, pentru autentificare. Acest lucru ar trebui să fie mai complex.” – Geoff Les, NXP
Figura 1. Izolare hardware în microcontrolerul PSoC™ 6 de la Cypress
Proiectanții de sisteme embedded sunt deja obișnuiți cu corul vocilor care declară că „securitatea este o problemă”. Mai puțin clar, este ceea ce ar trebui să facă exact în acest sens. Conținutul software al unui proiect embedded conține adesea părți de programe extrase dintr-o varietate de surse. Vor exista părți de program scrise special pentru proiect, dar și blocuri refolosite din experiențele anterioare. Pot exista segmente derivate de la furnizorii hardware-ului unui sistem – IP, cum ar fi driverele periferice pentru funcțiile on-chip: pot exista și blocuri de cod sursă deschisă (open source) importate într-un proiect. Cei care aduc argumente pentru verificarea amănunțită a integrității programului embedded, consideră că, cel puțin, toate secțiunile software-ului unei aplicații ar trebui să fie disponibile sub formă de sursă.
Mediul desktop a fost un câmp de luptă de mulți ani și, în acest spațiu, a evoluat un ecosistem pentru a contracara amenințările la adresa securității. Cel mai la îndemână exemplu este Windows și programul continuu de actualizări și corecții al Microsoft. Punctul esențial este acela că Microsoft își asumă responsabilitatea pentru robustețea continuă a produsului său, analizează amenințările pe măsură ce apar și furnizează patch-urile corespunzătoare. În spațiul embedded, nu există astfel de structuri de sprijin. Într-adevăr, întrucât codul din majoritatea proiectelor de sisteme embedded se implementează sub forma unui singur executabil binar, noțiunea de patch se aplică destul de greu. O actualizare completă (versiune) este singura opțiune, care în majoritatea cazurilor va necesita intervenția utilizatorului/operatorului, de obicei prin încărcarea unei noi configurații flash. Mecanismul pentru a face acest lucru devine, de asemenea, un aspect al proiectului care trebuie asigurat. Adică ar trebui să existe (cel puțin) o barieră robustă de conectare, care să ofere acces la un nivel de utilizator administrator, înainte ca sistemul să accepte o actualizare autentificată. Un furnizor care a subliniat acest aspect este STMicroelectronics, când a menționat că lucrează la un pachet pentru Secure Firmware Upgrade, ce va fi implementat în portofoliul său cu o gamă de scheme de codificare și autentificare.
Figura 2. Soluții la cheie ST STSafe
“Pentru IoT, securitatea este un activator major. În următorii cinci ani vom vedea o concentrare puternică pe securitate, cu o abordare particulară a securității pentru întregul ciclu de viață al produsului.” – Tom Pannell, Silicon Labs
Sunt multe recomandări pentru acțiunile care trebuie întreprinse, pentru a oferi un produs sigur în mod adecvat, dar o temă comună este să începeți cu elementele de bază și să nu ezitați să solicitați ajutor. Analizarea tuturor modurilor prin care un proiect ar putea fi vulnerabil, ar putea să aibă scăpări dacă este făcută doar de proiectant, mai ales dacă, într-o întreprindere mai mică, inginerii îndeplinesc deja mai multe sarcini cu privire la aspectele hardware și software ale produsului. Asigurarea bugetului pentru un consultant de specialitate extern poate aduce contribuții utile și (așa cum s-a menționat mai sus) este cel mai bine realizat în etapa de arhitectură a sistemului, mai degrabă decât ca un audit retrospectiv.
În ceea ce privește software-ul, respectarea standardelor acceptate ar trebui să parcurgă un drum lung pentru a oferi rezistență la metodele bine cunoscute de atac. Furnizorii de unelte software specializate oferă instrumente care utilizează tehnici precum analiză statică, ce sunt destinate a fi aplicate pe măsură ce software-ul este scris și dezvoltat, pentru a integra cerințele standardelor precum MISRA, JSF sau HIC ++. Programul care este conform cu aceste standarde ar trebui să fie rezistent la atacuri, precum ar fi forțarea fenomenului de stack overflow (adică programul încearcă să utilizeze mai multă memorie decât este disponibilă). Uneltele software implementează aceste precauții, totuși, deși o astfel de conformitate contribuie la asigurarea securității, nu este suficientă de la sine; este necesară, dar nu suficientă.
Figura 3. Privire generală asupra tehnologiei Arm Trustzone
Având în vedere cota de piață a microcontrolerelor bazate pe nucleu Arm în spațiul embedded, există o mare probabilitate ca în cadrul unui proiect să se utilizeze un nucleu Arm. Arm și-a extins tehnologia TrustZone pentru a acoperi microcontrolerele Cortex-M, pe lângă seria de nuclee Cortex-A. TrustZone creează un mediu de execuție de încredere, începând cu pornirea (boot-up) de încredere; acesta pune în practică conceptul de contexte paralele, de încredere și de neîncredere într-un singur sistem. Domeniile securizate și non-securizate sunt separate hardware, cu software-ul non-securizat blocat de la accesarea directă a resurselor securizate. Arm spune: „TrustZone pentru Cortex-M este utilizat pentru a proteja firmware-ul, perifericul și I/O, precum și pentru a oferi izolare pentru pornirea sigură, actualizarea de încredere și implementarea rădăcinii de încredere, oferind în același timp răspunsul determinist în timp real așteptat pentru soluțiile embedded.”
Microcontrolerele pentru sectorul embedded includ, de obicei, funcționalități pentru simplificarea implementării caracteristicilor de securitate, cum ar fi hardware optimizat pentru a rula algoritmi de criptare. Având aceeași importanță, producătorii de microcontrolere furnizează de obicei IP-ul software necesar pentru a îngloba această funcționalitate în structura unei aplicații. Concentrarea pe securitatea end-to-end (de la un capăt la altul) în IoT înseamnă asigurarea securității la nivelul cipului, la transmisia prin aer, la server și până în cloud. Securitatea într-un proiect (care include conectivitate fără fir) trebuie să fie continuă în verificarea identității și protecția cheilor, integritatea datelor și programul care stă la baza proiectului.
“O greșeală/bug poate fi o problemă de securitate … oamenii cred că este vorba de o eroare. Apare necesitatea de a simplifica securitatea.” – Jack Ogawa, Cypress Semiconductor
De asemenea, este posibil să ne concentrăm prea mult asupra subtilului, în detrimentul lumescului; multe exploit-uri (hacks și atacuri) sunt foarte simple. Accesul este acordat sau realizat deoarece oamenii uită pur și simplu să activeze securitatea sau utilizează o parolă implicită. „Lucrurile banale contează în ceea ce privește siguranța”, așa cum spune un observator.
Dacă produsul vostru are un mod de administrare sau întreținere protejat prin parolă, cel puțin asigurați-vă că fiecare unitate livrată are prestabilită o parolă unică și robustă. Apreciați că, deși proiectul vostru poate controla „doar” iluminatul sau poate monitoriza parametrii HVAC, acesta va avea acces și la sistemul IT corporativ al clientului. Tehnicianul care pune dispozitivul în funcțiune ar putea trece cu vederea acest lucru, iar, pe de altă parte, lăsarea instalării cu activare „pa55word” nu este ideală.
“Avem un set bogat de protocoale de securitate IP, pe care le introducem selectiv în familiile noastre de microcontrolere pe baza cerințelor aplicației.” – Andy Harding, Renesas Electronics
În multe privințe, acesta nu este un loc confortabil pentru inginer. Nu există o singură modalitate simplă de a evalua securitatea și de a identifica acțiunile corective „antiglonț”. Mecanismele pentru actualizări sunt fragmentare. Proiectanții creează sisteme care sunt implementate acum și care vor fi în funcțiune timp de un deceniu sau mai mult. Fără a fi prea alarmist, pot exista în zona legislativă minți pregătite să exploreze un nou domeniu al răspunderii pentru produse. În lumea conectată emergentă, câtă atenție la securitate ar putea fi considerată „necesară”, „adecvată” sau „suficientă”?
Cu toate acestea, ajutorul este la îndemână, iar producătorii de cipuri își dau seama că nu trebuie numai să furnizeze criptare și alte elemente hardware ale soluțiilor de securitate, ci trebuie să-și ajute clienții în realizarea unui pachet de securitate complet.
Autor:
Cliff Ortmeyer, Director Global de Marketing Tehnic
https://ro.farnell.com