Protezione dati del portachiavi
Molte app devono gestire password e altri dati non di grandi dimensioni ma sensibili, quali ad esempio chiavi e token di login. Il portachiavi fornisce un modo sicuro per conservare questi elementi. I vari sistemi operativi Apple usano diversi meccanismi per implementare le misure associate alle varie classi di protezione del portachiavi. Sui dispositivi con macOS, la protezione dei dati non è utilizzata direttamente per implementare queste misure.
Panoramica
Gli elementi del portachiavi sono codificati tramite due diverse chiavi AES-256-GCM: una chiave per la tabella (metadati) e una chiave per ciascuna riga (chiave del valore segreto). I metadati del portachiavi (tutti gli attributi diversi da kSecValue) sono codificati con lâapposita chiave per velocizzare le ricerche, mentre i valori segreti (kSecValueData) vengono codificati con la chiave del valore segreto. La chiave dei metadati è protetta da Secure Enclave, ma è archiviata nella cache del processore per le applicazioni per consentire ricerche rapide del portachiavi. La chiave del valore segreto deve passare attraverso Secure Enclave.
Il portachiavi è implementato come un database SQLite archiviato nel file system. Esiste solo un database e il daemon securityd determina quali sono gli elementi del portachiavi a cui possono avere accesso i processi o lâapp. Le API di accesso al portachiavi eseguono chiamate al daemon, che a sua volta esegue la richiesta alle autorizzazioni Keychainâaccessâgroups, applicationâidentifier e applicationâgroup per lâapp. I gruppi di accesso, piuttosto che limitare lâaccesso a un singolo processo, consentono la condivisione tra app degli elementi del portachiavi.
Gli elementi del portachiavi possono essere condivisi solo tra app dello stesso sviluppatore. PerchĂŠ questo sia possibile, alle app di terze parti viene chiesto di utilizzare gruppi di accesso con un prefisso che viene assegnato nellâambito dellâApple Developer Program attraverso gruppi di app. La richiesta di prefisso e lâunicitĂ di appartenenza a un gruppo di app sono applicate attraverso la firma del codice, i profili di provisioning e lâApple Developer Program.
I dati del portachiavi sono protetti utilizzando una struttura a classi simile a quella usata nella protezione dati dei file. Queste classi hanno comportamenti equivalenti alle classi di protezione dati dei file, ma usano chiavi e funzioni distinte.
DisponibilitĂ | Protezione dati dei file | Protezione dati del portachiavi | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
Quando sbloccato |
|
| |||||||||
Quando bloccato |
| ||||||||||
Dopo primo sblocco |
|
| |||||||||
Sempre |
|
| |||||||||
Codice abilitato |
| ||||||||||
Le app che utilizzano servizi di aggiornamento in background possono usare kSecAttrAccessibleAfterFirstUnlock per quegli elementi del portachiavi a cui è necessario accedere durante gli aggiornamenti in background.
La classe kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly si comporta come kSecAttrAccessibleWhenUnlocked, tuttavia è disponibile solo quando il dispositivo è configurato con un codice. Questa classe esiste soltanto nella keybag di sistema. Queste classi:
Non vengono sincronizzate sul portachiavi iCloud.
Non vengono incluse nei backup.
Non vengono incluse nelle keybag Escrow.
Se il codice viene rimosso o reimpostato, gli elementi vengono resi inutilizzabili eliminando le chiavi di classe.
Altre classi del portachiavi hanno una classe equivalente âSolo questo dispositivoâ, sempre protetta con lâUID mentre viene copiata dal dispositivo durante un backup, per renderla inutilizzabile se ripristinata su un dispositivo diverso. Apple ha trovato lâequilibrio perfetto tra sicurezza e facilitĂ dâuso scegliendo classi del portachiavi che variano in base al tipo di informazione di cui si vuole garantire la sicurezza e da quando iOS, iPadOS e visionOS la richiedono.
Protezioni delle classi di dati del portachiavi
Le protezioni delle classi elencate di seguito vengono implementate per gli elementi del portachiavi.
Elemento | Disponibile |
|---|---|
Chiavi codifica annunci Handoff | Dopo primo sblocco |
Token iCloud | Dopo primo sblocco |
Chiavi iMessage | Dopo primo sblocco |
LDAP, CalDAV, CardDAV | Dopo primo sblocco |
Account di posta | Dopo primo sblocco |
Account Microsoft Exchange ActiveSync | Dopo primo sblocco |
Token account social network | Dopo primo sblocco |
Password VPN | Dopo primo sblocco |
Password WiâFi | Dopo primo sblocco |
Password âIn casaâ | Quando sbloccato |
Segnalibri Safari | Quando sbloccato |
Password Safari | Quando sbloccato |
Backup del Finder o di iTunes | Quando sbloccato, non migratorio |
Certificati VPN | Dopo il primo sblocco, non migratorio |
Token del servizio di notifiche push di Apple (APN) | Sempre, non migratorio |
Chiavi Bluetooth | Sempre, non migratorio |
Certificati iCloud e chiave privata | Sempre, non migratorio |
PIN SIM | Sempre, non migratorio |
Token Dovâè | Sempre |
Segreteria | Sempre |
Su macOS, tutti gli elementi di portachiavi installati da profili di configurazione sono sempre disponibili dopo aver sbloccato FileVault. Su iOS, iPadOS e visionOS gli elementi di portachiavi installati da profili di configurazione hanno diverse opzioni di accesso a seconda del tipo, del modo in cui viene fatto riferimento a essi e di quando sono stati installati. Di default, gli elementi di portachiavi installati tramite profili di configurazione sono disponibili dopo il primo sblocco e non migratori. Tuttavia, un elemento di portachiavi installato da un profilo di configurazione è sempre disponibile se:
Ă stato installato prima di eseguire lâaggiornamento ad iOS 15 o iPadOS 15 o versioni successive.
Ă un certificato (non unâidentitĂ ).
Ă unâidentitĂ a cui viene fatto riferimento dal campo
IdentityCertificateUUIDin un payloadcom.apple.mdm
Controllo accesso portachiavi
I portachiavi possono usare elenchi di controllo degli accessi (ACL) per impostare le policy di accessibilitĂ e i requisiti di autenticazione. Gli elementi possono stabilire delle condizioni che richiedono la presenza dellâutente specificando che non è possibile fornire lâaccesso senza lâautenticazione tramite Optic ID, Face ID, Touch ID oppure inserendo il codice o la password del dispositivo. Lâaccesso agli elementi può essere limitato specificando che la registrazione tramite Optic ID, Face ID o Touch ID non ha subito modifiche dal momento in cui lâelemento è stato aggiunto. Questa restrizione aiuta a impedire che un hacker possa aggiungere la propria impronta digitale per accedere a un elemento del portachiavi. Gli elenchi ACL sono valutati allâinterno di Secure Enclave e vengono rilasciati al kernel solo se si soddisfano i vincoli specificati.
Architettura del portachiavi in macOS
macOS offre lâaccesso al portachiavi per archiviare in modo comodo e sicuro i nomi utente e le password, comprese identitĂ digitali, chiavi di codifica e note protette. Ă accessibile aprendo lâapp Accesso Portachiavi in /Applications/Utilities. Lâuso del portachiavi elimina la necessitĂ di inserire (o persino di ricordare) le credenziali di ogni risorsa. Per ogni utente del Mac viene creato un portachiavi di default iniziale, ma gli utenti possono crearne altri per determinati scopi.
Oltre ai portachiavi dellâutente, macOS si affida a una serie di portachiavi di sistema che conservano le risorse di autenticazione non specifiche di un utente, come le credenziali di rete e le identitĂ di infrastruttura della chiave pubblica (PKI). Uno di questi portachiavi, âRoot di sistemaâ, è immutabile e conserva i certificati della CA root della PKI internet per semplificare attivitĂ comuni come le operazioni di online banking e lâe-commerce. Allo stesso modo, lâutente può distribuire ai computer Mac gestiti dei certificati CA di cui è stato eseguito il provisioning internamente, per facilitare la convalida di siti e servizi interni.