Autenticazione SSL confrontando l'impronta digitale del certificato?

Question

Domanda per tutti gli esperti SSL in circolazione:

Abbiamo un dispositivo incorporato con un piccolo server Web su di esso e possiamo installare i nostri certificati autofirmati SSL su di esso. Il client è scritto in .NET (ma non importa così tanto).

Come posso autenticare il dispositivo in .NET? È sufficiente a confrontare l'impronta digitale del certificato rispetto a una voce nota nel database?

La mia comprensione è che l'impronta digitale è un hash dell'intero certificato, inclusa la chiave pubblica. Naturalmente un dispositivo che finge di essere il mio dispositivo potrebbe inviare lo stesso certificato pubblico, ma non potrebbe conoscere la chiave privata, giusto?

Oppure devo creare la mia catena di fiducia, creare il mio certificato di origine CA, firmare il certificato del server Web e installarlo sul client?

Answer 1

Quello che proponi è in linea di principio ok. Ad esempio, viene utilizzato durante lo key signing parties. Qui i partecipanti di solito si scambiano il loro nome e le impronte digitali delle loro chiavi pubbliche e si assicurano che la persona alla festa sia davvero chi sostiene. Basta verificare le impronte digitali è molto più facile che verificare una lunga chiave pubblica.

Un altro esempio è il cosiddetto self certifying file system. Qui di nuovo solo gli hash delle chiavi pubbliche vengono scambiati su un canale sicuro. (Ad esempio, questi hash sono incorporati negli URL). In questo schema le chiavi pubbliche non devono essere inviate in modo sicuro. Il ricevitore deve solo verificare che l'hash delle chiavi pubbliche abbia gli hash incorporati negli URL. Ovviamente il ricevitore deve anche assicurarsi che questi URL provengano da una fonte attendibile.

Questo schema e ciò che si propone sono più semplici rispetto all'utilizzo di una CA. Ma c'è uno svantaggio. Devi assicurarti che il tuo database con hash sia autentico. Se il tuo database è grande, questo sarà probabilmente difficile. Se si utilizzano CA, è necessario assicurarsi che le chiavi di root siano autentiche. Questo di solito semplifica notevolmente la gestione delle chiavi ed è ovviamente una delle ragioni per cui gli schemi basati su CA sono più popolari di ad es. il file system auto certificante sopra menzionato.

Answer 2

Allo stesso modo non si dovrebbero considerare due oggetti uguali solo perché i loro codici hash corrispondono, non si dovrebbe considerare un certificato come autentico solo perché l'impronta digitale appare in un elenco di "noto" impronte digitali certificate ".

Le collisioni sono un fatto di vita con algoritmi di hash, anche quelli buoni, e dovresti evitare la possibilità che un aggressore motivato possa creare un certificato canaglia con un hash delle impronte digitali corrispondente. L'unico modo per proteggersi è quello di controllare la validità del certificato stesso, cioè controllare la catena di fiducia come stai implicando nella tua ultima dichiarazione.

Answer 3

breve:

Beh, in teoria, poi fare esattamente quello che un'autorità di certificazione fa per voi. Quindi dovrebbe andare bene.

più lunga:

Quando un'autorità di certificazione firma vostra chiave pubblica/certificato/richiesta di certificato che non firma i dati interi certificato. Ma solo il valore hash calcolato di tutti i dati del certificato. Ciò mantiene la firma piccola.

Quando non si desidera stabilire la propria CA o utilizzare uno commerciale/gratuito - confrontando l'impronta digitale con quella di cui ci si fida otterrete la seconda configurazione più affidabile. La soluzione più affidabile sarebbe confrontando l'intero certificato, poiché ti protegge anche dagli attacchi di collisione hash.

Come gli altri ragazzi qui affermato è necessario assicurarsi di utilizzare un algoritmo di hashing sicura/sicura. SHA-1 non è più sicuro.

informazioni più dettagliate a questa discussione:

• https://security.stackexchange.com/questions/6737
• https://security.stackexchange.com/questions/14330