In questo articolo Indice dei contenuti 2 sezioni
Chi si occupa di migrazioni tra computer Apple farà bene a segnarselo: su macOS Tahoe il Portachiavi di accesso non si sposta più con un semplice copia e incolla del file. La verifica arriva da un test pratico, condotto partendo da un Mac con chip Apple Silicon, e il risultato è netto. Il database può essere trasferito senza problemi, ma sulla macchina di destinazione resta chiuso, anche fornendo la password corretta. Nessun errore di digitazione, nessun account configurato male: il blocco arriva da un livello più profondo, cioè dall’hardware che ha generato le chiavi.
Il file in questione è il classico login.keychain-db, quello che custodisce password dei siti, certificati, chiavi e note protette. Nel test è stato copiato dentro la directory Keychains di una macchina virtuale macOS, configurata con un account che usava esattamente la stessa password dell’originale. La scelta della VM non è casuale: una macchina virtuale non dispone di un Secure Enclave equivalente a quello del Mac di partenza. Al login successivo il sistema ha provato ad aprire il database, ha fallito, e ha reagito nel modo più prevedibile possibile, cioè rinominando il file copiato e creando da zero un nuovo portachiavi di accesso.
Cosa succede davvero dentro il Secure Enclave
La spiegazione sta nella documentazione Apple sulla protezione dei dati del keychain, che descrive un’architettura crittografica ancorata al chip. Il portachiavi di macOS è di fatto un database SQLite, e i dati al suo interno sono protetti da due chiavi AES-256-GCM con compiti diversi. La prima si occupa dei metadati, quindi delle informazioni che servono al sistema per fare ricerche rapide, ed è protetta dal Secure Enclave ma mantenuta in cache sul processore principale proprio per permettere le interrogazioni. La seconda protegge il valore segreto vero e proprio associato a ogni singolo elemento, e ogni volta che serve deve passare dal Secure Enclave.
Qui sta il punto che spiega tutto. Spostare il database significa spostare un contenitore, non le chiavi che lo aprono. Se il dispositivo di destinazione non può riprodurre le condizioni hardware di quello di origine, i segreti restano cifrati e inaccessibili. I log di securityd raccolti durante la prova mostrano esattamente questa sequenza: tentativo di apertura, errore nell’operazione di login, ricostruzione di un portachiavi nuovo e vuoto.
Le strade corrette per una migrazione su macOS Tahoe
La conseguenza pratica è che la copia diretta del file non può essere considerata una procedura affidabile in generale. Apple, del resto, prevede percorsi diversi a seconda del tipo di trasferimento. Setup Assistant è pensato per gestire la migrazione completa da un Mac all’altro, mentre Keychain Access permette di esportare e importare gli elementi compatibili, con un controllo più granulare su cosa spostare. Le credenziali sincronizzate tramite iCloud Keychain seguono invece un meccanismo a sé stante, che non dipende dalla copia manuale di alcun file locale.
La differenza pesa soprattutto nelle procedure amministrative, dove un’operazione apparentemente andata a buon fine può nascondere un disastro silenzioso. Il file c’è, la dimensione è quella giusta, il percorso è corretto, eppure le informazioni protette al suo interno restano inutilizzabili. Chi gestisce parchi macchine aziendali rischia di accorgersene solo quando l’utente prova ad accedere a un servizio e non trova nulla.
Va detto che il caso documentato non prova che ogni elemento del keychain diventi automaticamente irrecuperabile dopo un trasferimento. Dimostra un limite specifico e circoscritto, cioè quello della sostituzione manuale del portachiavi di accesso verso una destinazione priva dei requisiti hardware necessari. Per le migrazioni su macOS Tahoe la scelta del metodo dipende quindi dal tipo di dati da spostare e dal meccanismo con cui quei dati sono stati protetti in origine.
Fonte: TecnoAndroid
