In SSL / TLS , il client utilizza la chiave pubblica del server. Poiché in generale il client non conosce la chiave pubblica del server in avanzato, si aspetta di ottenerlo attraverso la magia del Public Key Infrastructure : la chiave pubblica del server verrà presentata in un certificato e il client sarà in grado di verificare che:
- i contenuti del certificato sono autentici (ovvero convalida : le firme e i nomi e le estensioni del certificato sono corretti e si collegano a una radice attendibile);
- il certificato è di proprietà del server previsto (il nome del server previsto viene visualizzato nell'estensione
Subject Alt Name del certificato o il suo nome comune se non è presente un'estensione SAN).
Ora tutto ciò è una complicazione inutile se il client conosce già la chiave pubblica; se quella chiave è nota a priori , allora il client può semplicemente usarla e semplicemente ignorare il certificato inviato dal server.
Per motivi di compatibilità con le specifiche formali del protocollo e per riutilizzare più facilmente le librerie e l'implementazione esistenti, è probabilmente ancora più semplice fare ciò che suggerisci, cioè verificare che il certificato del server sia bit-to-bit certificato atteso e lasciare che il codice estragga la chiave pubblica da quello. L '"impronta digitale", se è calcolata con una funzione di hash che è resistente alle seconde preimmagini (ad esempio SHA-1), può essere utilizzata per quel controllo. Questo va bene.
Nel tuo caso, capisco che il server è il dispositivo e il client è la tua applicazione. La tua applicazione non sarà ingannata (parlando con un dispositivo falso) solo se l'autore dell'attacco non ha compromesso la chiave privata del dispositivo, cioè l'ha estratta da un dispositivo. Se hai diversi dispositivi allora ogni dispositivo dovrebbe avere la sua coppia di chiavi privata / pubblica. Se tutti i dispositivi hanno la stessa coppia di chiavi, la chiave privata non può essere considerata "privata": un segreto noto a più di due o tre persone non è un segreto, ma una voce.
Il modo "sicuro" è quindi di avere una sorta di fase di inizializzazione, in condizioni controllate, in cui l'istanza dell'applicazione impara le impronte digitali dei dispositivi a cui si collegherà successivamente (forse l'applicazione genera le coppie di chiavi pubbliche / private e i certificati autofirmati e li importa nei dispositivi).
Questo è il modello di sicurezza utilizzato in SSH : la prima connessione da un client a un determinato server richiede una conferma esplicita (il client mostra l'impronta digitale della chiave pubblica del server, e l'utente umano dovrebbe verificarlo, ad esempio, telefonando al server sysadmin); in seguito, il client si fida di tale chiave pubblica perché ricorda l'impronta digitale.
Il modello "ricorda la chiave" funziona bene, ma devi essere consapevole del fatto che rinuncia alla funzione PKI nota come revoca : un meccanismo automatico fuori banda per trasmettere informazioni sul contenimento dei danni. Se la chiave privata di uno dei dispositivi è compromessa, il ladro può quindi eseguire un dispositivo falso e ingannare l'applicazione per collegarsi ad esso; per evitare il persistere di questa situazione, l'applicazione deve in qualche modo essere avvertita che una determinata impronta digitale del certificato non deve più essere accettata. Controlli di revoca, con risposte CRL o OCSP regolarmente pubblicate, è un metodo automatico per farlo. Quando hai memorizzato le impronte digitali, non c'è PKI, quindi nessun CRL. Ma il bisogno potrebbe essere ancora lì.
Se segui la strada no-PKI, con le impronte digitali dei certificati incorporati, devi decidere se hai bisogno di qualcosa per assicurarti che il lavoro sia normalmente svolto da CRL.