Android IKEv2: il certificato utente e la CA svolgono compiti diversi

Una schermata IKEv2 di Android che chiede insieme un certificato utente e un certificato CA sembra volere la stessa cosa due volte. Non è così. IKEv2 autentica entrambe le parti nelle due direzioni dentro un unico scambio, e il telefono ha un ruolo diverso in ciascuna direzione: deve dimostrare chi è e decidere di quale gateway si fida. Il certificato utente risponde alla prima domanda, la CA fidata alla seconda, e nessuno sostituisce l’altro.

Due direzioni di autenticazione in un solo scambio

IKEv2 costruisce un canale di controllo in due fasi. La prima negozia algoritmi e chiavi; la seconda, IKE_AUTH, porta un carico AUTH da ciascun lato insieme alla sua identità. Il carico è una firma o un MAC calcolato sullo scambio e viene verificato contro qualcosa di cui il destinatario si fida già.

Il gateway dimostra la propria identità con il suo certificato, e il telefono convalida la catena fino a una radice accettata verificando che l’identità corrisponda al gateway che intendeva raggiungere; il telefono dimostra la propria identità con le sue credenziali, e il gateway le verifica contro la CA che ha emesso il certificato client.

È tutto il meccanismo dietro i due campi. Il certificato utente è una dichiarazione del telefono su se stesso; il campo CA dice di chi si fiderà. Un profilo che ne ha uno ma non l’altro non completa l’autenticazione reciproca, e riprovare non cambia nulla. Persino gli errori appaiono diversi: senza chiave utente il telefono non può firmare, senza ancora di fiducia non può accettare il certificato del gateway.

Cosa richiede il generatore di profili di Android

Il generatore di profili IKEv2 di Android espone ogni metodo separatamente, non come un unico modo certificato. Il metodo con firma digitale richiede un certificato utente, una chiave privata e una CA radice del server; gli altri richiedono nome utente e password, oppure una chiave precondivisa.

Leggere bene quella firma, perché descrive il meccanismo qui sopra. Non c’è alcun campo per la chiave privata nel metodo nome utente e password, né un’ancora di fiducia nel PSK, perché quei metodi dimostrano cose diverse. Una password incollata in un campo certificato produce un profilo che fallisce a IKE_AUTH con un messaggio che non nomina né l’uno né l’altro.

Il tipo di chiave privata documentato per la firma digitale è RSA. Un menu etichettato IPsec o certificato non implica il supporto ECDSA, e un profilo costruito su questo presupposto fallisce nell’API della piattaforma prima ancora che la rete entri in gioco.

Perché un certificato pubblico non basta

Il carico AUTH è una firma sullo scambio realizzata con la chiave privata del client. Il certificato pubblico permette al gateway di controllare una firma, ma non fa nulla per il telefono, che ha bisogno della chiave per produrla. Importare solo .crt e lasciare indietro la chiave è la forma più comune di questo errore.

L’infrastruttura delle chiavi di Android lo riflette: scegliere un’identità client passa per KeyChain, che richiede l’accesso alla chiave privata corrispondente, non solo una voce di certificato. Un pacchetto di registrazione o una gestione dei dispositivi che installa la coppia insieme è la via normale; copiare un file a mano di solito no.

I due elementi del profilo non sono quindi un fascio di certificati e il suo duplicato. Uno è una coppia di chiavi con cui la piattaforma deve poter firmare, l’altro un’ancora di fiducia con cui confronta. Verificarli come due fatti distinti: questo profilo può firmare e sa di chi fidarsi?

Le ancore di fiducia appartengono all’applicazione, non al telefono

Una radice installata nell’archivio utente non fa credere tutte le applicazioni Android ad essa: da Android 7 un’app deve optare tramite la propria configurazione di sicurezza di rete, e prima di quella versione le CA installate dall’utente erano accettate molto più ampiamente. La configurazione di fiducia può variare, e un client VPN che gestisce da sé il proprio materiale di fiducia può non guardare mai l’archivio utente. Per questo lo stesso file CA può funzionare in un client e sembrare ignorato in un altro.

Ne derivano due modelli. Un profilo gestito dal sistema usa l’installazione dei certificati del dispositivo o l’iscrizione dell’amministratore, poi fa riferimento alla CA prevista. Un VPN gestito dall’applicazione conserva il proprio materiale e la propria importazione documentata, che può essere del tutto separata dalle impostazioni di Android. È lì che si ripara anche una catena spezzata.

Decidere in quale modello si è prima di importare qualsiasi cosa, poi confermare la selezione di fiducia del profilo attivo. Se le istruzioni dell’operatore e il menu del client non concordano, per quella installazione vince il comportamento documentato del client, ma la CA deve comunque arrivare dall’operatore tramite un canale verificabile. Il nome di un file non prova chi lo ha emesso.

Scegliere il modo, poi i file

Il modo certificato richiede una coppia di chiavi client, la CA emittente sul lato del gateway, un’ancora di fiducia per il certificato del gateway e l’attesa di quale identità quel certificato debba portare. Nome utente e password sostituiscono la coppia con credenziali ma mantengono il requisito di fiducia nel gateway. PSK sostituisce entrambi con un segreto condiviso e cambia il modello di fiducia invece di semplificarlo.

Qualunque scelta si faccia, lasciare attiva la validazione normale. Un’opzione senza verifica elimina il controllo per cui esiste il campo CA; non ripara un’ancora di fiducia mancante. Lo stesso vale per accettare qualsiasi certificato server perché la connessione funziona senza.

Poi verificare nel posto giusto: importare il materiale, collegarsi una volta e confermare nei dettagli della connessione che l’identità del gateway sia quella attesa e che il profilo dichiari il metodo previsto. Una connessione riuscita con il metodo sbagliato è una configurazione che non si è ancora capita, e fallirà quando l’operatore irrigidirà una regola.