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. In macOS (compresi i Mac dotati di chip Apple) 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 | NSFileProtectionComplete | kSecAttrAccessibleWhenUnlocked | |||||||||
Quando bloccato | NSFileProtectionComplete UnlessOpen |
| |||||||||
Dopo primo sblocco | NSFileProtectionComplete UntilFirstUserAuthentication | kSecAttrAccessibleAfterFirstUnlock | |||||||||
Sempre | NSFileProtectionNone | kSecAttrAccessibleAlways | |||||||||
Codice abilitato |
| kSecAttrAccessibleWhen PasscodeSetThisDeviceOnly | |||||||||
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 e iPadOS 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 |
|---|---|
Password Wi‑Fi | Dopo primo sblocco |
Account di posta | Dopo primo sblocco |
Account Microsoft Exchange ActiveSync | Dopo primo sblocco |
Password VPN | Dopo primo sblocco |
LDAP, CalDAV, CardDAV | Dopo primo sblocco |
Token account social network | Dopo primo sblocco |
Chiavi codifica annunci Handoff | Dopo primo sblocco |
Token iCloud | Dopo primo sblocco |
Chiavi iMessage | Dopo primo sblocco |
Password “In casa” | Quando sbloccato |
Password Safari | Quando sbloccato |
Segnalibri Safari | Quando sbloccato |
Backup del Finder o di iTunes | Quando sbloccato, non migratorio |
Certificati VPN | Dopo il primo sblocco, non migratorio |
Chiavi Bluetooth® | Sempre, non migratorio |
Token del servizio di notifiche push di Apple (APN) | 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. Su iOS e iPadOS, 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, 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 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 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 /Applicazioni/Utility/. 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.