„Marcaje” hardware. File Hardware Fila Hardware pe magistrala de date

Instrumentele convenabile de gestionare de la distanță economisesc multă energie administratorilor de sistem - și în același timp prezintă un risc imens de securitate atunci când nu pot fi dezactivate de hardware folosind un jumper sau comutarea de pe placa de sistem. Blocul Intel Management Engine 11 din platformele moderne Intel este tocmai un astfel de pericol - este inițial nedeconectabil și, în plus, unele mecanisme de inițializare și funcționare ale procesorului sunt legate de acesta, astfel încât o dezactivare dură poate duce pur și simplu la o inoperabilitate completă a sistemului. Vulnerabilitatea se află în tehnologia Intel Active Management (AMT) și, cu un atac reușit, vă permite să obțineți control deplin asupra sistemului, așa cum a fost raportat în mai anul acesta. Dar cercetătorii de la Positive Technologies.

Procesorul IME în sine face parte din System Hub Chip (PCH). Cu excepția sloturilor de procesor PCI Express, toată comunicația dintre sistem și lumea exterioară trece prin PCH, ceea ce înseamnă că IME are acces la aproape toate datele. Înainte de versiunea 11, un atac împotriva acestui vector era puțin probabil: procesorul IME își folosea propria arhitectură cu setul de instrucțiuni ARC, care era puțin cunoscut dezvoltatorilor terți. Dar în versiunea 11, au jucat o glumă proastă cu tehnologia: a fost transferată în arhitectura x86 și a fost folosit un sistem MINIX modificat ca sistem de operare, ceea ce înseamnă că studiile efectuate de terțe părți despre codul binar au devenit mult mai ușoare: atât arhitectura, cât și sistemul de operare sunt bine documentate. Cercetătorii ruși Dmitry Sklyarov, Mark Ermolov și Maxim Goryachy au reușit să descifreze modulele executabile ale versiunii 11 a IME și să înceapă un studiu aprofundat al acestora.

Intel AMT este evaluat cu 9,8 din 10 pentru vulnerabilitate. Din păcate, dezactivarea completă a IME pe platformele moderne este imposibilă din motivul de mai sus - subsistemul este strâns legat de inițializarea și pornirea procesorului, precum și de gestionarea alimentării. Dar puteți elimina toate elementele inutile din imaginea de memorie flash care conține module IME, deși este foarte dificil să faceți acest lucru, în special în versiunea 11. Proiectul me_cleaner, un utilitar care vă permite să eliminați partea comună a imaginii și să lăsați doar componente vitale, se dezvoltă activ. Dar să facem o mică comparație: dacă în versiunile IME până la 11 (înainte de Skylake) utilitarul a șters aproape totul, lăsând aproximativ 90 KB de cod, atunci în prezent este necesar să economisiți aproximativ 650 KB de cod - și apoi, în unele cazuri, sistemul se poate opri după o jumătate de oră, de când blocul IME intră în modul de recuperare.

Cu toate acestea, există unele progrese. Grupul de cercetători menționat mai sus a reușit să utilizeze un kit de dezvoltare, care este furnizat chiar de Intel, și include utilitare Flash Image Tool pentru configurarea parametrilor IME și un semnalizator Flash Programming Tool care funcționează printr-un controler SPI integrat. Intel nu pune aceste programe la dispoziția publicului, dar nu este dificil să le găsești pe Internet.

Au fost analizate fișierele XML obținute cu acest kit (conțin structura firmware-ului IME și descrierea mecanismului curelei PCH). Un bit numit „reserve_hap” (HAP) părea suspect din cauza descrierii „High Assurance Platform (HAP) enable”. O căutare pe web a dezvăluit că acesta este numele unui program de platformă de mare putere asociat cu NSA SUA. Activarea acestui bit a indicat faptul că sistemul a intrat în modul Alt Disable. Blocul IME nu a răspuns la comenzi și nu a răspuns la influențele sistemului de operare. Există, de asemenea, o serie de nuanțe mai subtile care pot fi găsite în articolul de pe Habrahabr.ru, dar noua versiune a me_cleaner a implementat deja suport pentru majoritatea modulelor periculoase fără a seta bitul HAP, ceea ce pune motorul IME în starea „TemporaryDisable”.

Ultima modificare a me_cleaner lasă doar modulele RBE, KERNEL, SYSLIB și BUP chiar și în versiunea 11 a IME, nu au găsit un cod care să vă permită să activați sistemul IME în sine. În plus față de acestea, puteți utiliza bitul HAP pentru a vă asigura că utilitarul poate face acest lucru. Intel a analizat cercetarea și a confirmat că o serie de setări IME sunt într-adevăr legate de nevoile guvernamentale pentru o securitate sporită. Aceste setări au fost introduse la cererea clienților guvernului SUA și au suferit o validare limitată și nu sunt acceptate oficial de Intel. De asemenea, compania neagă introducerea așa-numitelor uși din spate în produsele sale.

Pe scurt, afirmă următoarele (în continuare, în text, redarea mea subiectivă liberă).

Se presupune că marile corporații din întreaga lume, inclusiv Apple, Amazon și altele ca acestea, au comandat servere scumpe de top de la SuperMicro de mulți ani. Acesta din urmă mânca din astfel de volume de comenzi, propriile fabrici nu mai puteau face față. Apoi a oferit producția unei anumite cantități de plăci de bază subcontractanților ei chinezi.

Oamenii politici chinezi au venit la aceiași subcontractanți și le-au făcut o ofertă care nu poate fi refuzată. Ca, haideți, băieți, la cererea noastră, la cererea noastră, veți instala în plus încă un cip nedocumentat ma-a-a-a-a-scarlet pe plăcile de bază. Dacă da, vă vom aduce bani suplimentari, dar dacă nu o faceți, vă vom scoate afacerea cu diferite cecuri. Drept urmare, plăcile de bază „modificate” în acest fel au fost vândute în întreaga lume, iar unele dintre ele au ajuns și în marile companii americane din primul eșalon, bănci și agenții guvernamentale.

A trecut ceva timp. Una dintre diviziile Amazon, o anumită companie numită „Elements”, s-a ocupat de securitatea soluțiilor sale în domeniul procesării în masă a fluxurilor video. Printre altele, au comandat un audit de securitate hardware al unei anumite firme canadiene. Și aici au fost descoperite cipuri nedocumentate ascunse cu pricepere implantate în plăcile de bază. Care nu sunt atât de ușor de găsit. Pentru că, în primul rând, sunt foarte mici și gri. În al doilea rând, se deghizează în cuplaje obișnuite de lipit sau condensatoare cu cip. În al treilea rând, în ultimele revizuiri au început să fie ascunse chiar în grosimea textolitului, astfel încât să fie vizibile doar pe raze X.

Dacă credeți textul, atunci prin intermediul microcodului încorporat, cipul spion prin modulul BMC îl „ping” periodic pe unul dintre „păpușarii” anonimi, de la care primește instrucțiuni suplimentare de acțiune. Și se presupune că chiar adversarul menționat mai sus poate descărca „de unde” un cod, care este apoi injectat direct în nucleul sistemului de operare care rulează sau în codul aplicației.

Ei bine, urmează ulterioare despre cât de mare este o gaură în securitate, ce fel de capre sunt acești chinezi, care sunt îndrăzneala și obrăznicia lor, nu se poate avea încredere în toate caprele, „acum vom muri cu toții” și atât. Raționamentul interesant din punct de vedere tehnic se încheie aici.

În general, sunt un mare sceptic în viață. Fără a nega geniul chinezilor, unele momente personal mi se par destul de nerealiste. Să o luăm exact așa, pe furiș din partea inginerilor și a conducerii, și să facem modificări la designul plăcii de bază la nivelul producătorului, fără a perturba performanța acesteia? Și dacă, cu cunoștințele conducerii, atunci cum a fost motivat să expună toate acele afaceri atât de mari la un risc reputațional atât de grav? Injectați codul în sistemul de operare și în aplicații? Ei bine, cu Windows, este în regulă, sunt gata să cred cu un scârțâit. Dar în Linux, unde nu știi dinainte cine l-a construit și cum? Exercitați activitate de rețea fără degete? Care, dacă se dorește, poate fi detectat și filtrat. Ca să nu mai vorbim de faptul că administratorii normali nu expun niciodată BMC-urile „pentru a-și arăta fundul gol pe internet”, iar administratorii buni îi aruncă, în general, într-un VLAN separat fără posibilitatea de a accesa oriunde.

Ei bine, din nou, recent, unele manii și paranoia spionaj acerbe au progresat în rândul americanilor. Și au decis, de asemenea, să se certe cu China. Deci obiectivitatea și imparțialitatea articolului original este o mare întrebare. Pe de altă parte, nu înțeleg prea bine de unde obțin subiecte atât de frumoase. În 2011, revista tabloidă „Ksakep” a scris despre aceleași marcaje chinezești la nivelul microcodului în unitatea flash BMC. Articolul respectiv miroase și la delir paranoic, dar nu există fum fără foc. Sau se întâmplă?

În general, împărtășiți-vă părerea în comentarii. Este deosebit de interesant să-l auzi pe tovarășul kvazimoda24 cu privire la posibilitatea de a integra un fel de microcircuite spion în grosimea PCB-ului.

Nu sunt un profesionist în domeniul securității informațiilor, domeniul meu de interes sunt sistemele de calcul performante. Am ajuns la subiectul securității informațiilor destul de accidental, iar acest lucru va fi discutat în continuare. Cred că această poveste fictivă va ilumina mai bine problemele asociate cu hardware-ul de virtualizare decât o declarație de fapt uscată. Chiar înainte de anunțul oficial al noilor procesoare Intel cu suport pentru virtualizarea hardware (la începutul anului 2007), am conceput să folosesc aceste cipuri pentru a crea un singur sistem de calcul bazat pe mai multe servere, care ar deveni o singură unitate de calcul cu o arhitectură SMP pentru sistemul de operare și programele de aplicații. Pentru a face acest lucru, a fost necesar să scrieți un hipervizor compact cu funcționalitate non-standard, a cărui caracteristică principală nu ar fi împărțirea resurselor unei singure unități de calcul între diferite sisteme de operare, ci, dimpotrivă, unificarea resurselor mai multor computere într-un singur complex, care ar fi controlat de un singur sistem de operare. În același timp, sistemul de operare nici măcar nu a trebuit să ghicească că nu avea de-a face cu un singur sistem, ci cu mai multe servere. Hardware-ul de virtualizare a oferit o astfel de oportunitate, deși inițial nu a fost destinat să rezolve astfel de probleme. De fapt, nu a fost încă creat un sistem în care hardware-ul de virtualizare ar fi folosit pentru calculul de înaltă performanță și chiar în acel moment eram, în general, un pionier în acest domeniu. Hipervizorul pentru această sarcină, desigur, a fost scris de la zero. Era fundamental important să rulăm sistemul de operare deja pe o platformă virtualizată, astfel încât, de la primele comenzi ale încărcătorului de sistem de operare, totul să funcționeze într-un mediu virtual. Pentru a face acest lucru, a trebuit să virtualizăm modelul real și toate modurile de operare a procesorului și să începem virtualizarea imediat după inițializarea platformei înainte de a încărca sistemul de operare. Deoarece sistemul de virtualizare în acest scop s-a dovedit a fi non-standard și arăta ca un modul software compact complet autonom (dimensiunea codului nu mai mare de 40-60 Kb), limbajul nu a îndrăznit cumva să-l numesc hipervizor și am început să folosesc termenul „hyperdriver”, deoarece este mai precis a transmis esența scopului funcțional al sistemului. Echipamentul serial cu hardware de virtualizare nu era încă disponibil în acel moment, cu toate acestea, datorită cooperării cu Craftway, am avut acces la eșantioane de pre-producție de procesoare și plăci de bază cu suport de virtualizare, care nu au fost încă lansate oficial (așa-numitele eșantioane, pe care Intel le oferă cu amabilitate parteneri de afaceri). Prin urmare, lucrările au început să fiarbă la acest echipament „eșantion”. Mockup-ul a fost asamblat, hyperdriver-ul a fost scris, totul a funcționat conform intenției. Trebuie să spun că la acel moment hardware-ul de virtualizare era foarte „brut”, motiv pentru care a refuzat în mod repetat să funcționeze așa cum este scris în documentație. A trebuit să mă ocup de literalmente de fiecare comandă de asamblare, iar comenzile pentru hardware-ul de virtualizare trebuiau scrise în coduri de mașină, de atunci nu existau compilatoare care să susțină comenzile de virtualizare. Eram mândru de rezultatele obținute, mă simțeam aproape stăpânul lumilor virtuale ... dar euforia mea nu a durat mult, doar o lună. În acel moment, am asamblat deja un aspect bazat pe servere cu hardware de virtualizare, ale cărui prime mostre seriale tocmai apăruseră, dar aspectul nu a funcționat. Am început să-mi dau seama și am realizat că sistemul meu se blochează atunci când execut comenzi de virtualizare hardware. Impresia a fost că fie nu au funcționat deloc, fie au funcționat cumva în afara cutiei. Suspendarea a avut loc numai atunci când hardware-ul de virtualizare rula în modul real, dar dacă sistemul meu a fost pornit din modul protejat după încărcarea sistemului de operare, atunci totul a fost în regulă. Profesioniștii știu că la primele revizuiri, hardware-ul de virtualizare Intel nu suporta funcționarea procesorului în timp real. Acest lucru necesită un strat suplimentar suficient de mare pentru a emula x86 virtual. Deoarece hyperdriver-ul a fost pornit înainte ca sistemul de operare să fie încărcat, astfel încât să poată crede pe deplin în noua configurație virtuală, o mică parte din codul de boot al sistemului de operare a fost executat în modul real al procesorului. Sistemul a murit doar pe dispozitivele de emulare în modul real din hyperdriver. La început am crezut că mă înșel undeva, nu înțelegeam ceva, uitasem de ceva. Am verificat totul până la ultima bucată din codul meu, nu am găsit nicio eroare și am început să păcătuiesc nu pe mine, ci pe colegii mei din spatele dealului. Primul lucru pe care l-am făcut a fost să înlocuiesc procesoarele, dar asta nu a ajutat. Pe plăcile de bază în acel moment, hardware-ul de virtualizare era doar în BIOS, unde a fost inițializat când serverul a fost pornit, așa că am început să compar bios-urile de pe plăcile de bază (plăcile de bază de același tip cu mostrele) - totul se potrivea cu octetul și cu numărul BIOS-ului în sine. Am căzut într-o stupoare și, nemaiavând ce să fac, am aplicat ultima soluție - „metoda poke”. Ce nu am făcut, nu mă mai gândesc, ci pur și simplu combin, și până la urmă am descărcat prost bios de pe site-ul oficial Intel și le-am rescris în plăci de bază, după care totul a funcționat ... Nu a existat nicio limită pentru surprinderea mea: numărul BIOS-ului a fost același , imaginile BIOS-ului s-au potrivit cu octet cu octet, dar din anumite motive plăcile de bază seriale au început să funcționeze doar când am încărcat același BIOS preluat de pe site-ul Intel în ele. Deci, motivul este încă în plăcile de bază? Dar singura lor diferență a fost în marcare: Canada asamblată a fost scrisă pe probe, iar China asamblată pe plăcile seriale. A devenit clar că plăcile din China conțin module software suplimentare încorporate în BIOS, dar aceste module nu au fost văzute de programele de analiză standard. Se pare că aceștia au lucrat și cu hardware de virtualizare și, în consecință, au reușit să ascundă adevăratul conținut al BIOS-ului. Motivul blocării hyperdriver-ului meu pe aceste plăci chineze a devenit, de asemenea, clar: două sisteme software funcționau simultan cu același hardware de virtualizare, ceea ce nu permitea partajarea resurselor lor. Am vrut să mă ocup de acest bios rău intenționat și, fără să mă gândesc din nou la „semne de carte”, „ușă din spate”, „caracteristici nedocumentate”, a existat doar un interes academic și nimic mai mult. Trebuie să spun că, în paralel cu introducerea hardware-ului de virtualizare, Intel a actualizat radical chipset-ul. Acest chipset, numerotat 5000x, este încă produs în mai multe modificări. Podul sudic al acestui chipset, hubul de control I / O 631xESB / 632xESB, la care sunt conectate microcircuite flash cu bios, a fost practic neschimbat din 2007 și este utilizat ca cip de bază pentru aproape toate serverele într-o versiune cu două socketuri. Am descărcat foaia tehnică pentru podul sudic, am citit descrierea și am fost uimit. Se pare că trei cipuri de memorie flash sunt conectate la acest nou pod sudic: primul este un BIOS standard, al doilea este dedicat programelor procesorului de controler de rețea, iar al treilea este destinat unității BMC integrată în podul sudic. Unitatea de gestionare a sistemului (BMC) este un mijloc de control de la distanță și de monitorizare a facilității de calcul. Este indispensabil pentru camerele mari de servere, în care este pur și simplu imposibil să stați mult timp din cauza zgomotului, temperaturii și curenților de aer. Faptul că unitățile BMC au propriul procesor și, în consecință, memoria flash pentru programele sale, desigur, nu este o știre, dar până acum un astfel de procesor și memorie au fost scoase pe o placă separată care a fost conectată la placa de bază: dacă doriți - puneți-o, nu doriți - nu-l pune. Acum, Intel a implementat aceste componente în podul sudic, în plus, a conectat această unitate la magistrala de sistem și nu a folosit un canal de rețea dedicat (așa cum este prevăzut de standardul IPMI care descrie funcțiile unității BMC) pentru funcționarea rețelei de servicii, dar a tunelat tot traficul rețelei de servicii în rețeaua principală adaptoare. Apoi am aflat din documentație că programele de pe microcircuitul flash al unității BMC sunt criptate și un modul special criptografic hardware, de asemenea integrat în podul sudic, este folosit pentru a le despacheta. Nu am mai întâlnit niciodată astfel de blocuri ale Marinei. Pentru a nu fi neîntemeiat, iată un extras din documentația acestui pod sudic:

  • Procesor ARC4 care funcționează la viteza de 62,5 MHz.
  • Interfață la ambele porturi LAN ale hubului de control I / O Intel® 631xESB / 632xESB care permite conexiunea directă la rețea și accesul la toate registrele LAN.
  • Modul criptografic, care suportă algoritmi de criptare AES și RC4 și algoritmi de autentificare SHA1 și MD5.
  • Mecanism securizat pentru încărcare reglementată FW.
Utilizarea mijloacelor criptografice străine cu o lungime a cheii mai mare de 40 de biți este interzisă pe teritoriul Rusiei prin lege, dar aici - vă rog! - în fiecare server Intel există un criptomodul cu chei necunoscute de 256 de biți. Mai mult, aceste chei au fost folosite pentru a cripta programe încorporate în cipurile plăcii de bază în timpul producției. Se pare că unitățile navale din Rusia pe serverele Intel, care includ un chipset de 5000x, ar trebui să fie dezactivate. Cu toate acestea, aceste unități, dimpotrivă, sunt întotdeauna în stare de funcționare, chiar dacă unitatea de calcul în sine este oprită (pentru funcționarea DIU, tensiunea de așteptare este suficientă, adică cablul de alimentare al serverului introdus în priză). Toate acestea mi s-au părut în acel moment de importanță secundară, pentru că mai întâi trebuia să aflu care dintre microcircuitele flash conținea modulul software care funcționează cu hardware-ul de virtualizare și interferează cu hyperdriverul meu și am început să experimentez firmware-ul. După ce am citit documentația, am fost în gardă și, când am descoperit că performanța hyperdriver-ului a fost restabilită imediat după ce a aprins cipul flash al unității DIU, nici măcar nu am fost surprins. Era imposibil să înțelegem mai departe fără standuri speciale, deoarece criptografia a blocat complet posibilitățile de inversare a codului pentru Marina. Nu am găsit nicio documentație cu privire la arhitectura internă a acestui DIU integrat; în foaia tehnică pentru podul sudic, Intel a descris doar registre de interfață pentru gestionarea acestei unități folosind metode de acces standard, ceea ce a dus la o „cutie neagră” clasică. Totalitatea faptelor a alarmat și a dus la gânduri paranoice în stilul detectivilor spion. Aceste fapte au indicat în mod clar următoarele:
  • Noile plăci server din seria 5000 ale Intel conțin programe care sunt încorporate în memoria flash a unității BMC și rulează pe procesorul central, iar aceste programe rulează folosind hardware-ul de virtualizare al procesorului central.
  • Imaginile flash de pe site-ul oficial Intel nu conțin astfel de module software, prin urmare, modulele software care interferează cu mine au fost flashate ilegal în plăci de bază în etapa de producție.
  • Memoria flash a unității BMC conține module software criptate care nu pot fi asamblate și turnate în memoria flash fără a cunoaște cheile de criptare, prin urmare, cel care a introdus aceste module software ilegale știa cheile de criptare, adică avea acces la informații de fapt secrete.
Am informat conducerea Kraftway despre problema cu memoria flash a unității Forțelor Navale și situația dubioasă din punct de vedere al legislației cu noile chipset-uri Intel, la care am primit un răspuns destul de așteptat în stilul „nu vă amestecați, interferați cu afacerea”. A trebuit să mă calmez, pentru că nu poți călca în picioare pe angajatori. Mâinile erau legate, dar „gândurile mele, caii mei” nu mi-au dat odihnă, nu era clar de ce aceste dificultăți și cum s-a făcut totul. Dacă aveți ocazia să plasați propriul software în memoria unității Forțelor Navale, de ce aveți nevoie de toate aceste probleme cu procesorul central? Singurul motiv rezonabil ar putea fi faptul că problema rezolvată necesită controlul contextului de calcul actual pe procesorul central. Este evident că este imposibil să țineți evidența informațiilor procesate pe sistemul principal al computerului folosind doar un procesor periferic de viteză mică cu o frecvență de 60 MHz. Astfel, se pare că sarcina acestui sistem ilegal a fost de a prelua informații procesate pe instalația principală a computerului folosind hardware de virtualizare. Desigur, este mai convenabil să controlați de la distanță întregul sistem ilegal de la procesorul unității BMC, deoarece are propriul său acces independent la adaptoarele de rețea de pe placa de bază și propriile adrese MAC și IP. Întrebarea „cum se face asta?” avea o natură mai academică, deoarece cineva a reușit să creeze un hipervizor care poate partaja resursele hardware-ului de virtualizare cu un alt hipervizor și face acest lucru corect pentru toate modurile, cu excepția modului real al procesorului. Acum nu veți surprinde pe nimeni cu astfel de sisteme, dar apoi, în urmă cu cinci ani, au fost percepute ca un miracol, în plus, viteza de emulare a fost uimitoare - era imposibil să emulați programatic o gazdă fără pierderi semnificative de performanță. Pentru a clarifica, trebuie să mergeți puțin mai adânc în teorie. Arhitectura sistemelor de virtualizare Intel și AMD nu implică prezența mai multor hipervizoare pe platformă simultan, cu toate acestea, hipervizorul lansat mai întâi poate emula munca pe hardware-ul de virtualizare real pentru hipervizoarele care sunt lansate după. În acest caz, toți hipervizorii au fost lansați după prima rulare într-un mediu gazdă emulat. Acest principiu îl numesc „dreptul primei nopți”. Poate fi implementat cu ușurință utilizând handler-uri speciale pe gazda rădăcină fără a schimba semnificativ modul de activitate și gazdele secundare de hipervizor care rulează în modul de activitate pentru gazda rădăcină. Modul de emulare nu este dificil de organizat, dar există probleme cu performanța. Hardware-ul de virtualizare funcționează în principal cu blocul VMCB (VMCS), programele gazdă accesează în mod constant acest bloc și fiecare astfel de acces necesită 0,4-0,7 μs. Este aproape imposibil să ascunzi această emulație de gazdă software pentru sistemul de virtualizare Intel, prea multe comenzi de virtualizare vor trebui emulate programatic prin ieșirile către gazda rădăcină, în loc să le rulezi pe hardware real. Vă voi spune puțin despre diferențele dintre arhitecturile de virtualizare. Sistemele de virtualizare hardware de la Intel și AMD sunt complet diferite unele de altele. Principala diferență arhitecturală dintre aceste sisteme este modul de operare gazdă. Pe un sistem AMD, gazda rulează cu hardware de virtualizare dezactivat, ceea ce înseamnă că programele sale rulează pe un procesor real. Virtualizarea gazdei secundare pe sistemele AMD necesită doar virtualizarea comenzii VMRUN (se poate presupune că nu există alte comenzi). Lucrul cu blocul de control VMCB în arhitectura AMD are loc prin comenzile obișnuite pentru accesarea RAM, ceea ce permite gazdei secundare să controleze doar executarea comenzilor VMRUN cu ajutorul gazdei secundare și să corecteze blocul VMCB dacă este necesar înainte de a intra efectiv în modul task. Este încă posibil să prelungiți bucla evenimentului de două ori, iar această emulare este viabilă pe platforma AMD. Sistemul de virtualizare Intel este mult mai complicat. Pentru a accesa blocul VMCB, utilizați comenzi speciale VMREAD și VMLOAD, care trebuie virtualizate. De obicei, gestionarii gazdelor accesează câmpuri VMCB de zeci, dacă nu de sute de ori, și fiecare astfel de operație trebuie imitată. În același timp, se observă că viteza scade cu un ordin de mărime, acest lucru este foarte ineficient. A devenit clar că colegii necunoscuți foloseau un mecanism diferit, mai eficient pentru emulare. Și indicii despre care am găsit în documentație. Gazda Intel este ea însăși un mediu virtual, adică nimic, de fapt, în acest sens nu diferă de mediul de execuție a sarcinilor și este controlat pur și simplu de un alt VMCB (vezi diagrama). În plus, documentația descrie conceptul de "monitor dual" pentru virtualizarea modului SMM (modul de gestionare a sistemului), atunci când două gazde sunt active deodată și, prin urmare, două blocuri VMСB, iar gazda virtualizând modul de gestionare a sistemului controlează gazda principală ca sarcină dar numai la gestionarea sistemului întrerupe punctele de apel. Acest corp de dovezi circumstanțiale sugerează că hardware-ul de virtualizare Intel are probabil un mecanism pentru controlul mai multor gazde secundare gestionate de gazda rădăcină, deși acest mecanism nu este descris nicăieri. În plus, așa a funcționat sistemul meu și încă nu am altă explicație pentru acțiunile aproape imperceptibile ale hipervizorului rădăcină. A devenit și mai interesant: se pare că cineva a avut acces la aceste caracteristici nedocumentate și le-a folosit în practică. Cu aproximativ șase luni înainte de încheierea cooperării cu Craftway, am preluat poziția de observator pasiv, continuând totuși să-mi lansez în mod regulat sistemul pe noi loturi de plăci de bază seriale din China și mostre noi. Pe probe totul a continuat să funcționeze stabil. Când am trecut la panourile chinezești, au apărut din ce în ce mai multe minuni în sistem. Se părea că colegii din străinătate îmbunătățeau în mod activ performanța hipervizorului rădăcină. Ultimele loturi suspecte de plăci s-au comportat aproape normal, adică prima lansare a hyperdriver-ului meu a dus la o repornire a sistemului în timpul pornirii sistemului de operare, dar toate lansările ulterioare ale hyperdriver-ului și ale sistemului de operare au dispărut fără probleme. În cele din urmă, ceea ce așteptam de mult s-a întâmplat: a sosit un nou lot de plăci de bază obișnuite care nu mi-au înghețat deloc hyperdriver-ul. Începusem deja să-mi pun la îndoială suspiciunile paranoice, dar un nou incident le-a întărit. Trebuie remarcat faptul că Intel îmbunătățește activ hardware-ul de virtualizare. Dacă prima revizuire a hardware-ului cu care am început să lucrez a fost numărul 7, atunci situația descrisă s-a întâmplat la cea de-a 11-a revizie, adică în aproximativ un an revizuirea a fost actualizată de două ori (din anumite motive, reviziile au doar numere impare). Deci, la revizuirea 11, condițiile pentru intrarea în gazdă în funcție de starea sarcinii pentru hardware-ul de virtualizare s-au extins semnificativ, potrivit cărora un nou câmp de control a fost chiar introdus în blocul VMCB. Când au apărut eșantioane de procesoare cu această revizuire a hardware-ului de virtualizare, am vrut să încerc noi posibilități în practică. Am îmbunătățit hyperdriverul datorită noilor caracteristici ale revizuirii a 11-a a hardware-ului de virtualizare, am instalat un procesor de probă pe o placă serial din China, în care totul a funcționat fără niciun comentariu și am început depanarea. Noile capacități ale echipamentului nu s-au manifestat în niciun fel și am căzut din nou în prosternare, păcătuind asupra procesorului de probă și a documentației. După ceva timp, placa de bază a fost necesară pentru o altă sarcină și, după reluarea experimentelor, din motive de siguranță, am rearanjat procesoarele cu cea de-a 11-a revizuire a hardware-ului de virtualizare în eșantionul canadian. Imaginați-vă surpriza mea când totul a funcționat la acest eșantion! La început, am crezut că m-am încurcat undeva cu placa serială, deoarece noile ieșiri către gazdă nu au nimic de-a face cu placa de bază, ei bine, era pur o funcție de procesor. Pentru a-l testa, am schimbat procesorul de probă pe placa serială și totul a încetat să funcționeze din nou. Aceasta înseamnă că nu am deranjat nimic și problema consta în faptul că placa de bază a influențat cumva noile capacități ale hardware-ului de virtualizare a procesorului. Având în vedere suspiciunile mele, singura concluzie s-a sugerat - gazda rădăcină ilegală a colegilor din străinătate, cusută în memoria flash a plăcii de bază, nu știa despre noua revizuire a hardware-ului de virtualizare. Când această piesă hardware necunoscută a început să funcționeze, nu va mai direcționa corect ieșirile din starea sarcinii către gazda mea secundară prin intermediul propriului său handler de evenimente. Știind deja cum să fac față acestui flagel, am încărcat firmware-ul pentru unitatea BMC de pe site-ul Intel pe placa de serie, am pornit sistemul cu încrederea că totul va funcționa imediat și din nou s-a precipitat, pe măsură ce înghețurile au rămas. A fost ceva nou. Potrivit teoriei mele, hipervizorul ilegal a devenit insolent și a devenit convins de invulnerabilitatea sa. Aparent, autorii săi au considerat că ideea lor a trecut de etapa de testare și nu mai era necesar să se mascheze software-ul nerezolvat în caz de eșec al BIOS-ului. După ce a fost activată funcția de protejare a codului de inițializare împotriva suprascrierii în memoria flash, marcajul a devenit aproape imposibil de șters. Nu aveam încredere în neprihănirea mea, aveam nevoie de experimente de control. A trebuit să inventez propria metodă de detectare a hipervizorului hardware. Apoi, însă, s-a dovedit că inventasem bicicleta. Metoda a permis controlul timpului de execuție a comenzilor de sistem care au necesitat o emulare obligatorie în gazda hipervizorului. Ca temporizator, am folosit un contor de cadre ciclice în hardware-ul controlerului USB și am scris programul pentru o operare reală pentru a minimiza întreruperile false și necontrolate care mascau timpul real de execuție al instrucțiunilor de sistem. Prima verificare pe care am făcut-o a fost pentru un sistem curat bazat pe exemple de plăci de bază din Canada.
Timpul de execuție afișat în fotografie este o anumită valoare condițională, aproximativ corespunzătoare ciclului procesorului. Apoi am efectuat același test pe o placă de bază serială și m-am asigurat de ipotezele mele paranoice - ciclurile de comandă au fost prelungite semnificativ.
Adică, în memoria flash a unității BMC a plăcilor de server din China, fabricată sub eticheta Intel, a existat un modul software nedeclarat instalat în etapa de producție, care funcționează ca o gazdă de hipervizor. Rămâne să-i convingi și pe alții de acest lucru. Primul lucru pe care l-am făcut a fost să contactez reprezentantul rus Intel. Nu a fost deloc dificil, deoarece angajații biroului rus s-au prezentat adesea la Craftway. Am spus și am arătat totul, dar nu eram sigur dacă tehnicianul a înțeles totul. Acești așa-ziși specialiști tehnici diferă puțin de manageri în ceea ce privește competența lor. Cu toate acestea, el a promis că va raporta totul conducerii. Nu știu dacă a făcut-o, dar nu a existat niciun răspuns din partea Intel, totul a mers ca nisipul. Lucrările la Craftway s-au încheiat până atunci și am început un nou proiect într-o companie legată de sistemele de securitate a informațiilor. Șeful acestei firme, cu care am împărtășit „descoperirile” mele, mi-a luat cuvintele în serios. În acest sens, s-a decis contactarea conducerii Centrului pentru Securitatea Informațiilor și Comunicații Speciale al FSB. Această structură din cadrul FSB este implicată în asigurarea securității informațiilor în țară și reglementează activitățile organizațiilor de stat și comerciale care sunt legate de protecția informațiilor. De asemenea, reglementează măsurile de protecție a informațiilor pentru agențiile guvernamentale și firmele comerciale care procesează informații clasificate și confidențiale. Compania la care lucram la acea vreme a menținut contacte oficiale cu Centrul pentru a certifica și a licența proiectele lor comerciale, așa că a fost destul de ușor să organizăm o întâlnire la nivelul specialiștilor. S-a presupus că experții Centrului își vor comunica opinia conducerii și, după aceea, conducerea consideră că este necesar să ne asculte, următoarea etapă va fi o întâlnire la un nivel superior. Ședința a avut loc, i-am spus și am arătat tot ce am putut afla, apoi am demonstrat prezența unui modul software ilegal folosind exemplele de plăci din Canada și China. Apropo, a fost prima dată când am auzit termenul profesional „marcaj”, adică un astfel de modul. Când conversația s-a îndreptat către Marina, o neînțelegere a apărut în ochii colegilor de la centru. A trebuit să conduc un program educațional. În acest proces, s-a dovedit că nici măcar nu bănuiau existența unui microprocesor special în podul de sud cu acces la un adaptor de rețea și prezența unui modul criptografic în unitatea navală care încalcă legea rusă. În concluzie, am auzit destul de neașteptat că acest model de amenințări a fost deja investigat, se aplică un set de contramăsuri în raport cu acestea și, în general, nu ne temem de marcaje, deoarece sistemele noastre nu au acces la Internet. Mai multe anchete nu au dus la nimic, totul s-a bazat pe secret, de exemplu, suntem deștepți și super-alfabetizați și nu ar trebui să știți nimic. Cu toate acestea, m-am îndoit puternic de alfabetizarea lor tehnică, deoarece pur și simplu nu înțelegeau majoritatea a ceea ce am spus și am arătat. Ne-am despărțit de ceea ce ei vor raporta superiorilor lor și doar ei vor decide asupra acțiunilor ulterioare. Ulterior am aflat care este această „metodă secretă” de detectare a programelor gazdă. Și am aflat destul de întâmplător, în timpul negocierilor la companie - licențiatul Centrului, autorizat să verifice BIOS-ul pentru marcaje. Specialiștii tehnici ai acestei companii, care efectuează cercetări pe BIOS, au spus că modulele sale software care utilizează hardware de virtualizare ar trebui să fie căutate prin semnăturile comenzilor de virtualizare. Într-adevăr, instrucțiunile procesorului pentru hardware-ul de virtualizare conțin trei sau patru octeți în codul programului, dar cine a spus că va găsi acest cod de program sub formă necriptată pe un microcircuit flash? Cum scanează acest cod în RAM dacă aceste zone de memorie sunt protejate de vizualizare de către hardware? În general, rezultatul primei întâlniri a lăsat un gust neplăcut și, în cea mai posomorâtă dispoziție, mă așteptam la dezvoltarea evenimentelor. O lună și jumătate mai târziu, am fost invitați la Centrul pentru Protecția Informației și Comunicații Speciale în sine, astfel încât să putem demonstra marcajul pe care l-am descoperit. De data aceasta nu angajații obișnuiți s-au adunat să ne asculte, ci manageri și specialiști de frunte (cel puțin așa s-au prezentat). Ședința s-a transformat într-o prelegere, m-au ascultat cu atenție aproape trei ore, era clar că auzeau pentru prima dată ce le spuneam. Am enumerat noi vulnerabilități pe platforma x86, am arătat marcajul și am spus cum să îl detectez și am răspuns la multe întrebări. La final, ne-au mulțumit, au spus că subiectul trebuie dezvoltat în cadrul unor proiecte speciale de cercetare și de aceasta ne-am despărțit. Euforia a dispărut atunci când informațiile ne-au ajuns prin canale neoficiale pe care pur și simplu nu au vrut să ne creadă. Cu toate acestea, acest lucru nu mi-a răcit dorința de a-mi demonstra cazul. După cum mi s-a părut atunci, soluția era la suprafață: era necesar să scriu eu însumi un astfel de modul de program pentru marcaj. Nu aș fi putut să pun un marcaj în memoria flash a Marinei, dar aș putea să-l împing în BIOS-ul principal. Am decis să dotez hipervizorul cu un modul propriu de securitate pentru mascare în memorie și pe un microcircuit flash, precum și blocarea scrierii pe un microcircuit flash unde va fi plasat codul marcajului, după care va fi posibil să îl ștergeți doar desoldând BIOS-ul și reprogramându-l pe un programator extern. A rămas doar să decidă asupra funcției „rău intenționate” pe care ar trebui să o îndeplinească hipervizorul. Mi-am amintit afirmația unuia dintre specialiștii FSB că nu se tem de semne de carte, deoarece sistemele lor sunt deconectate de la rețeaua globală. Dar informațiile din lumea exterioară trebuie să ajungă cumva în aceste rețele locale securizate, cel puțin prin intermediul discurilor optice de unică folosință. Astfel, am ajuns la concluzia evidentă și am decis să analizez fluxul de informații primite în filă prin intermediul hyperdriver-ului pentru a implementa, ca să spunem așa, o armă a zilei de final, adică pentru a utiliza fila pentru a distruge sistemul de calcul pe o comandă externă, trecându-l prin fluxul de informații de intrare, steganografic. Pentru a scana fluxul de informații pe ascuns, fără a pierde performanța, numai hardware-ul de virtualizare îl poate gestiona. În ce moment să scanați, este, de asemenea, clar: pe bufferele I / O ale sistemelor de disc și pe un adaptor de rețea. Scanarea bufferelor I / O este o mare problemă pentru hardware-ul de virtualizare. Făcut repede și foarte bine! Un astfel de hyperdriver, cu o dimensiune de aproximativ 20 KB, a fost înregistrat în bios-ul plăcii de bază și este echipat cu o funcție anti-detectare. A blocat încercările de suprascriere la actualizarea BIOS-ului și a îndeplinit singura funcție: a resetat cipul flash BIOS când a fost recepționată o comandă pentru distrugere. Pentru ușurința implementării, comanda în sine a fost cusută într-un fișier text în format DOC în etichetele de setări. Când totul a fost gata, conducerea companiei a mers din nou la FSB cu o propunere de a analiza activitatea propriului nostru marcaj și de a ne asigura că tehnologiile de virtualizare reprezintă o amenințare reală. Dar nimeni nu a vrut să se uite la semnul nostru de carte, a venit o comandă din partea de sus (nu am aflat niciodată a cui ordine este exactă) să nu mai comunicăm cu noi. Principalii luptători pentru securitatea informațiilor nu au vrut să ne asculte. Apoi, sperând deja în nimic, de fapt, să ne curățăm conștiința, am încercat să transmitem informații despre problemă utilizatorilor de sisteme de securitate a informațiilor. Am contactat Gazprom pentru a informa specialiștii companiei despre amenințările actuale la adresa sistemelor distribuite de control al proceselor. Am reușit să organizăm o întâlnire cu conducerea securității corporative și managementul sistemelor complexe de securitate ale acestei corporații. O versiune mai vizuală a marcajului cu o interfață de comandă simplificată a fost pregătită special pentru ei. Marcajul a fost activat după descărcarea unui fișier text pe computer, al cărui conținut a inclus două cuvinte - „Gazprom” și „oprire” - aranjate în ordine aleatorie. După aceea, computerul a murit, dar nu imediat, ci cu o întârziere de cinci minute. Bineînțeles, a fost posibil să facem o întârziere pentru o zi, dar atunci nu am fi întâlnit timpul alocat demonstrației. Angajații „Gazprom” s-au plâns de nivelul scăzut de securitate a informațiilor și au spus că nu este treaba lor, deoarece sunt ghidați de cerințele și normele stabilite de FSB. Cercul s-a închis, a devenit clar că acest sistem monolitic de „iresponsabilitate informațională” nu putea fi spart. În cei peste trei ani care au trecut de atunci, nu am auzit pe nimeni să vorbească despre hardware-ul de virtualizare ca pe un instrument de penetrare a sistemelor țintă. Paradox? Nu cred. Specificitatea subiectului este că învățăm doar despre tehnologiile eșuate. Nu știm despre tehnologii care nu au fost descoperite, iar autorii lor, desigur, sunt tăcuți. Trebuie avut în vedere faptul că plasarea fiabilă a marcajelor în BIOS este posibilă numai din fabrică. În condiții de funcționare, acest lucru va necesita concentrarea asupra unui anumit model de placă de bază, iar astfel de opțiuni nu sunt foarte interesante pentru hackeri. Au nevoie de o scară de masă, funcționează, după cum se spune, „după zonă”. Cu toate acestea, există cei care atacă țintirea, „stil de lunetist”. Tehnologia pentru plasarea marcajelor în BIOS și chiar cu activarea hardware-ului de virtualizare, care vă permite să le ascundeți în mod eficient, este, desigur, un instrument convenabil pentru astfel de „lunetisti”. Odată au fost aproape prinși și aproape din întâmplare. Cred că acum nu va fi posibil să faceți acest lucru și nu este nimeni de prins, așa cum ați înțeles probabil.

A fost odată, când computerele personale erau achiziționate în străinătate în loturi de câteva sute de piese, și nu în milioane de „circulații”, sub egida unuia dintre departamentele KGB, erau organizate mici birouri comerciale pentru „căutarea marcajelor”. Acum înțelegem perfect că acesta a fost unul dintre modurile cinstite de a lua bani, pentru că la acel nivel de securitate și organizare, puteți găsi orice doriți, dar nu doar o filă în compoziția jetoanelor. Dar cumpărătorii mari din numărul de birouri de stat și întreprinderi nu mai aveau încotro. Au platit.

publicitate

Astăzi, Intel nici măcar nu ascunde faptul că instrumentele pentru controlul de la distanță ale computerului sunt încorporate în procesoarele și chipset-urile platformelor moderne de computer. Tehnologia Intel Active Management Management (AMT) foarte mediatizată ar trebui să ajute la simplificarea întreținerii la distanță a sistemului - diagnosticare și recuperare - fără intervenția utilizatorului. Dar nimeni nu este asigurat că este posibil să se utilizeze drepturile administratorului AMT în scopuri rău intenționate și, după cum se dovedește, nu există doar un semn de carte, există o „ipotecă” întreagă.

Potrivit unei publicații a expertului în securitate Damien Zammit, chipset-urile Intel moderne au un cip de microcontroler Intel Management Engine (Intel ME) local și izolat încorporat. Aceasta este o soluție cu propriul firmware care nu este disponibil pentru examinare de către instrumente terțe și cu control complet asupra procesorului, memoriei și a sistemului în ansamblu. Mai mult, controlerul poate funcționa cu computerul oprit, atâta timp cât este alimentată memoria. Desigur, sistemul de operare și utilitățile nu vor dormi și nici nu vor ști spiritual despre activitatea controlerului și nu vor suna o alarmă în timp ce lucrează cu sistemul și datele.

Îngrijorează că, cu un nivel tehnic suficient al inamicului, există pericolul de a efectua o modificare ascunsă a oricărui cip. Cipul modificat va funcționa în noduri critice, iar „calul troian” sau „dispozitivul hardware” introdus va trece neobservat, subminând apărările țării la cel mai fundamental nivel. Pentru o lungă perioadă de timp, o astfel de amenințare a rămas ipotetică, dar o echipă internațională de cercetători a reușit recent să o implementeze la nivel fizic.

Georg T. Becker de la Universitatea din Massachusetts, împreună cu colegii din Elveția și Germania, ca parte a unei dovezi de concept, au creat două versiuni ale unui „troian la nivel hardware” care perturbă (pseudo) generatorul de numere aleatorii (PRNG) din blocul criptografic al procesoarelor Intel Ivy. Pod. Cheile criptografice create folosind PRNG modificat pentru orice sistem de criptare vor fi ușor previzibile.

Prezența unei file hardware nu este în niciun fel determinată nici de testele încorporate special concepute pentru aceasta, nici de o examinare externă a procesorului. Cum s-ar fi putut întâmpla asta? Pentru a răspunde la această întrebare, este necesar să reveniți la istoria apariției hardware PRNG și să vă familiarizați cu principiile de bază ale funcționării sale.

Atunci când creați sisteme criptografice, este necesar să eliminați posibilitatea selectării rapide a cheilor. Lungimea și gradul lor de imprevizibilitate afectează în mod direct numărul de opțiuni pe care ar trebui să le sorteze partea atacantă. Lungimea poate fi setată direct, dar este mult mai dificil să se realizeze unicitatea variantelor cheie și probabilitatea lor egală. Pentru a face acest lucru, numerele aleatoare sunt utilizate în timpul generării cheilor.

În prezent, este general acceptat faptul că doar din cauza algoritmilor software este imposibil să se obțină un flux cu adevărat aleatoriu de numere cu distribuția lor haotică uniformă pe întregul set specificat. Vor avea întotdeauna o frecvență ridicată în unele părți ale gamei și vor rămâne oarecum previzibile. Prin urmare, majoritatea generatoarelor de numere utilizate în practică ar trebui percepute ca pseudo-aleatorii. Sunt rareori suficient de fiabile criptografic.

Pentru a reduce efectul predictibilității, orice generator de numere are nevoie de o sursă fiabilă de semințe aleatorii. De obicei, rezultatele măsurătorilor unor procese fizice haotice sunt utilizate ca acesta. De exemplu, fluctuațiile intensității vibrațiilor luminii sau înregistrarea zgomotului de frecvență radio. Un astfel de element aleatoriu (și întregul hardware PRNG) ar fi convenabil din punct de vedere tehnic de utilizat într-o versiune compactă și, în mod ideal, pentru a-l încorpora.

Intel a construit generatoare de numere (pseudo) aleatorii în cipurile sale de la sfârșitul anilor nouăzeci. Anterior, natura lor era analogă. Valorile aleatorii la ieșire au fost obținute datorită influenței proceselor fizice dificil de prezis - zgomot termic și interferențe electromagnetice. Generatoarele analogice erau relativ ușor de implementat ca blocuri separate, dar dificil de integrat în circuite noi. Pe măsură ce procesul a devenit mai mic, au fost necesari pași de calibrare noi și lungi. În plus, scăderea regulată a tensiunii de alimentare a înrăutățit raportul semnal-zgomot în astfel de sisteme. PRNG-urile au lucrat constant și au consumat o cantitate semnificativă de energie, iar viteza muncii lor a lăsat mult de dorit. Aceste neajunsuri au impus restricții asupra posibilelor aplicații.

Ideea unui generator de numere (pseudo) aleatorii cu o natură complet digitală mi s-a părut ciudată, dacă nu chiar absurdă, de mult timp. La urma urmei, starea oricărui circuit digital este întotdeauna rigid deterministă și previzibilă. Cum să introduceți elementul necesar aleatoriu în el dacă nu există componente analogice?

Încercările de a crea haosul râvnit bazat doar pe elemente digitale au fost făcute de inginerii Intel încă din 2008 și au fost încununate de succes după câțiva ani de cercetare. Lucrarea a fost prezentată în 2010 la Simpozionul de vară VLSI din Honolulu și a făcut o mică revoluție în criptografia modernă. Pentru prima dată, un PRNG complet digital, rapid și eficient din punct de vedere energetic a fost implementat într-un procesor comercial de uz general.

Primul său titlu de lucru a fost Bull Mountain. Apoi a fost redenumită Secure Key. Acest bloc criptografic este format din trei module de bază. Primul generează un flux de biți aleatori la o rată relativ lentă de 3 Gbps. Al doilea evaluează varianța lor și le combină în blocuri de 256 de biți, care sunt folosite ca surse de semințe aleatorii. După o serie de proceduri matematice în al treilea bloc, un flux de 128 de biți de numere aleatorii este generat la o rată mai mare. Pe baza lor, folosind noua instrucțiune RdRand, dacă este necesar, sunt create numere aleatorii cu lungimea necesară și plasate într-un registru special desemnat: 16, 32 sau 64 de biți, care sunt transferați în cele din urmă către programul care le-a solicitat.

Erorile generatorilor de numere (pseudo) aleatorii și modificările lor dăunătoare determină o pierdere a încrederii în produsele criptografice populare și chiar procedura de certificare a acestora.

Datorită importanței excepționale a PRNG-urilor pentru orice sistem criptografic, testele au fost încorporate în cheia securizată pentru a verifica calitatea numerelor aleatorii generate, iar grupurile de experți de vârf au fost implicate pentru certificare. Întreaga unitate îndeplinește criteriile standardelor ANSI X9.82 și NIST SP 800-90. În plus, este certificat NIST FIPS 140-2 Nivelul 2.

Până acum, cea mai mare parte a lucrărilor pe troieni hardware a fost ipotetică. Cercetătorii au propus modele suplimentare din circuite logice mici care trebuiau adăugate într-un fel la cipurile existente. De exemplu, Samuel Talmadge King și coautorii săi au prezentat la LEET-08 o versiune a unui astfel de troian hardware pentru procesorul central care să ofere control deplin asupra sistemului unui atacator la distanță. Prin simpla trimitere a unui pachet UDP configurat, s-ar putea face orice schimbări pe un astfel de computer și să obțină acces nelimitat la memoria acestuia. Cu toate acestea, circuitele logice suplimentare sunt relativ ușor de identificat prin microscopie, fără a menționa metodele specializate pentru căutarea unor astfel de modificări. Grupul lui Becker a mers pe altă cale:

În loc să conectăm circuite suplimentare la cip, ne-am implementat filele de nivel hardware prin simpla schimbare a funcționării unora dintre microtransistori care se află deja în el. După mai multe încercări, am reușit să schimbăm selectiv polaritatea dopantului și să facem modificările dorite la funcționarea întregii unități criptografice. Prin urmare, familia noastră de troieni s-a dovedit a fi rezistentă la majoritatea metodelor de detectare, inclusiv microscopie de scanare și comparație cu cipurile de referință. "

Ca rezultat al muncii depuse, în loc de numere unice cu o lungime de 128 biți, al treilea bloc Secure Key a început să acumuleze secvențe în care doar 32 biți erau diferiți. Cheile criptografice generate pe baza unor astfel de numere pseudo-aleatorii sunt foarte previzibile și pot fi sparte în câteva minute pe un computer obișnuit de acasă.

Schimbarea selectivă a conductivității electrice care stă la baza filei hardware a fost implementată în două versiuni:

  1. postprocesare digitală a semnalelor de la cheia securizată Intel;
  2. utilizați pe un canal lateral folosind metoda Substitution-box.

Această din urmă metodă este mai versatilă și poate fi aplicată cu modificări minore la alte cipuri.

Abilitatea de a utiliza PRNG-ul integrat prin instrucțiunea RdRand a apărut pentru prima dată în procesoarele de arhitectură Intel Ivy Bridge. Intel a scris ghiduri detaliate pentru programatori. Acestea descriu metode pentru implementarea optimă a algoritmilor criptografici și oferă un link către o descriere a modului în care funcționează cheia securizată. Pentru o lungă perioadă de timp, eforturile experților în securitate au vizat găsirea vulnerabilităților în partea software. Poate că, pentru prima dată, intervenția ascunsă la nivel de hardware sa dovedit a fi o tehnologie mult mai periculoasă și destul de fezabilă.