CAI Technology
Menu ☰
cai-auth · · 8 min citire

Atestare hardware explicată: StrongBox, Secure Enclave și TEE

Cum demonstrează atestarea hardware că o cheie există într-un element securizat - StrongBox, Secure Enclave, TEE - și de ce un furnizor de identitate ar trebui să o impună.

CAI Technology
Birou de inginerie luminos în care două persoane analizează pe un ecran mare lanțul de atestare al elementului securizat al unui telefon

Atestare hardware explicată: StrongBox, Secure Enclave și TEE

TL;DR

Ce este atestarea hardware în autentificare?

Atestarea hardware este un proces în care un dispozitiv produce un certificat semnat care dovedește că o anumită cheie criptografică a fost generată și este păstrată într-un element securizat dedicat, că nu poate fi exportată și că dispozitivul îndeplinește o postură de securitate declarată (stare de boot, blocare a sistemului de operare, nivel de patch). Furnizorul de identitate verifică acel certificat în raport cu rădăcina de încredere a producătorului hardware înainte de a acorda încredere cheii.

În practică, asta transformă „utilizatorul a apăsat aprobă” în „o cheie care există în mod demonstrabil în siliciu rezistent la modificări, pe un dispozitiv nerootat, a semnat această provocare.” Această distincție este ceea ce separă un factor MFA rezistent la phishing puternic de o credențială pe care orice malware de pe un telefon compromis ar putea-o sustrage. De asemenea, completează întărirea pe partea de semnare discutată în ghidul nostru de autentificare post-cuantică: semnăturile post-cuantice protejează cheile emitentului, atestarea protejează cheia dispozitivului utilizatorului.

StrongBox vs Secure Enclave vs TEE

Acești trei termeni sunt folosiți adesea interschimbabil, dar descriu hardware diferit. Un TEE (Trusted Execution Environment, standardizat de GlobalPlatform) este un context de execuție izolat care rulează pe același procesor de aplicații ca și sistemul de operare normal, protejat prin hardware (de exemplu Arm TrustZone). Este rapid și omniprezent, dar împarte siliciul cu CPU-ul principal.

StrongBox de la Android este mai puternic: este un cip de securitate dedicat, rezistent la modificări (un Secure Element cu propriul CPU, RAM și spațiu de stocare) care atinge un prag de certificare hardware. Secure Enclave de la Apple este un coprocesor de securitate dedicat, cu propriul boot ROM și motor AES, izolat de procesorul principal. Diagrama de mai jos rezumă compromisurile.

flowchart TD A["Aplicația cere o cheie legată de dispozitiv"] --> B{"Unde este stocată cheia?"} B -->|"Cip dedicat certificat"| C["StrongBox (Android Secure Element)"] B -->|"Coprocesor dedicat"| D["Secure Enclave (Apple)"] B -->|"Zonă izolată pe CPU-ul principal"| E["TEE (clasă TrustZone)"] C --> F["Izolare maximă; cheia nu ajunge niciodată pe CPU-ul principal; atestată hardware"] D --> G["Izolare puternică; boot ROM propriu; atestată prin lanțul Apple"] E --> H["Izolare bună; împarte siliciul cu sistemul de operare; disponibilă pe scară largă"] F --> I["Politica IdP: preferă StrongBox, revino la TEE"] G --> I H --> I

Cum se citește diagrama: Mapează o singură cerere - „dă-mi o cheie legată de dispozitiv” - pe cele trei opțiuni de element securizat și proprietățile lor de securitate. Ramura din stânga arată locația fizică a materialului cheii, care este proprietatea ce contează cu adevărat: un cip dedicat (StrongBox) sau un coprocesor (Secure Enclave) este mai greu de atacat decât o zonă care împarte CPU-ul principal (TEE). Coloana din dreapta surprinde consecința practică pentru un furnizor de identitate, motiv pentru care fluxurile converg către un singur nod de politică la final. Concluzia este că un IdP ar trebui să exprime o ordine de preferință (StrongBox > TEE) în loc să trateze toate cheile susținute hardware ca fiind egale, pentru că atestarea îi spune exact ce nivel a folosit dispozitivul.

Cum funcționează lanțul de certificate de atestare

Când aplicația cere platformei să genereze o cheie atestată, elementul securizat creează perechea de chei și emite un certificat de atestare care încorporează proprietățile declarate ale dispozitivului (nivel de securitate, stare de boot, nivel de patch al sistemului de operare, nonce-ul provocării). Acel certificat-frunză este semnat de un certificat intermediar, care se înlănțuie până la o rădăcină a producătorului hardware - rădăcina de atestare hardware Google pentru Android sau rădăcina Apple pentru Secure Enclave. Furnizorul de identitate verifică întregul lanț până la o rădăcină fixată (pinned) înainte de a acorda încredere oricărui lucru semnat de cheie.

sequenceDiagram participant U as "Dispozitivul utilizatorului" participant SE as "Element securizat (StrongBox / Enclave / TEE)" participant IdP as "Furnizor de identitate" participant Root as "Rădăcina producătorului (Google / Apple)" IdP->>U: "Trimite provocarea de atestare (nonce)" U->>SE: "Generează cheia + semnează nonce-ul" SE-->>U: "Lanț de certificate de atestare + semnătură" U->>IdP: "Trimite lanțul de certificate + nonce-ul semnat" IdP->>IdP: "Analizează extensia: nivel de securitate, stare de boot, nonce" IdP->>Root: "Verifică lanțul până la rădăcina fixată a producătorului" Root-->>IdP: "Lanț valid / revocat" IdP->>IdP: "Aplică politica (respinge root / emulator)" IdP-->>U: "Leagă cheia dispozitivului / respinge"

Cum se citește diagrama: Această secvență arată întregul handshake de verificare, de la stânga la dreapta în timp. Serverul începe prin emiterea unui nonce proaspăt, astfel încât dispozitivul să nu poată rejuca o atestare veche - elementul securizat încorporează acel nonce în materialul semnat. Dispozitivul returnează atât lanțul de certificate, cât și semnătura, iar munca esențială se petrece pe server: acesta analizează extensia de atestare (nivel de securitate, stare de verified-boot, nivel de patch), apoi verifică lanțul până la o rădăcină fixată a producătorului, nu până la orice rădăcină oferită de dispozitiv. Abia după ce lanțul se validează și politica trece, IdP-ul leagă cheia. Diagrama clarifică faptul că încrederea curge de la rădăcina producătorului de siliciu, prin lanț, până la server - dispozitivul nu poate niciodată să-și afirme unilateral propria credibilitate.

De ce contează atestarea obligatorie pentru un furnizor de identitate

Fără atestare, „passwordless” este o promisiune pe care dispozitivul o face despre el însuși. Un telefon Android rootat sau un emulator software poate prezenta o cheie perfect validă care există în memorie obișnuită, unde malware-ul o poate citi sau clona. Atestarea obligatorie elimină acest punct orb: IdP-ul inspectează starea de boot și nivelul de securitate raportate în certificat și respinge dispozitivele rootate, cu bootloader deblocat sau emulate înainte de a aproba orice autentificare. Acesta este modelul pe care organisme de standardizare precum FIDO Alliance îl susțin pentru legarea autentificatorilor de hardware verificabil.

CAI-AUTH impune acest lucru direct: necesită atestare hardware obligatorie (Android StrongBox sau TEE) și refuză înregistrarea cheilor de dispozitiv care nu trec verificarea lanțului sau care raportează o stare de boot compromisă. Pentru organizațiile care cântăresc unde ar trebui să se afle stratul lor de identitate, ghidul nostru pentru rularea unui furnizor de identitate auto-găzduit acoperă modul în care politica de atestare se potrivește unei implementări suverane. CAI Technology nu este o autoritate guvernamentală.

Limite și avertismente

Atestarea este puternică, dar nu miraculoasă. Acoperirea este inegală: nu orice dispozitiv Android livrează un cip StrongBox, așa că o politică strictă doar-StrongBox exclude hardware altfel demn de încredere - majoritatea implementărilor acceptă atestarea la nivel de TEE drept prag minim. Rotația cheilor are nevoie de un flux definit: când un utilizator primește un dispozitiv nou, vechea cheie atestată trebuie retrasă și un lanț nou verificat, nu acordată tacit încredere. Certificatele rădăcină și intermediare pot fi revocate, așa că IdP-ul trebuie să verifice revocarea, nu doar validitatea lanțului. În cele din urmă, atestarea dovedește mediul cheii, nu omul - se asociază cu, nu înlocuiește, prezența utilizatorului și gesturile biometrice. Tratați-o ca pe un semnal puternic de legare a dispozitivului în cadrul unui design pe straturi, nu ca pe un punct unic de încredere.

FAQ

Ce este atestarea hardware?

Atestarea hardware este o dovadă criptografică a faptului că o cheie privată a fost generată în interiorul unui element securizat rezistent la modificări de pe un dispozitiv și că nu îl părăsește niciodată, plus un raport semnat despre postura de securitate a dispozitivului. Un verificator verifică lanțul de certificate de atestare în raport cu rădăcina producătorului hardware înainte de a acorda încredere cheii.

Ce este StrongBox?

StrongBox este nivelul de securitate hardware cel mai înalt de la Android: un cip Secure Element dedicat, rezistent la modificări, cu propriul procesor, memorie și spațiu de stocare, certificat la un prag hardware. Cheile generate în StrongBox nu ating niciodată procesorul de aplicații principal, iar platforma poate emite un certificat de atestare care dovedește că o cheie există acolo.

Poate un furnizor de identitate să detecteze un telefon rootat?

Da. Certificatul de atestare raportează starea de verified-boot a dispozitivului, statutul de blocare a bootloader-ului și nivelul de securitate. Un furnizor de identitate care verifică lanțul până la o rădăcină fixată a producătorului poate citi acele câmpuri și poate respinge dispozitivele rootate, cu bootloader deblocat sau emulate înainte de a aproba autentificarea - exact ceea ce politicile de atestare obligatorie sunt concepute să facă.


Vedeți atestarea hardware obligatorie în acțiune - explorați CAI-AUTH, un furnizor de identitate OIDC post-cuantic operat în UE care necesită chei de dispozitiv susținute hardware: auth.caitech.ro.

Începem cu o conversație de 30 de minute.

Audit AI-readiness gratuit pentru companii peste 50 angajați. Răspundem în 24 de ore.