Nel protocollo Diffie-Hellman, se i partecipanti hanno la propria chiave privata e una chiave pubblica generata. Come possiamo determinare se hanno o meno un'autorità di certificazione fidata per l'autenticazione o solo il protocollo originale in cui i partecipanti non sono autenticati?
Dobbiamo specificarlo, inserire una firma digitale nei messaggi o possiamo assumere l'autenticazione ogni volta che è coinvolta una chiave pubblica?
Diffie-Hellman (DH) è un algoritmo di accordo chiave , usato per stabilire il materiale della chiave simmetrica condivisa .
A volte è chiamato il "protocollo Diffie-Hellman" ma è un po 'fuorviante. Per DH è necessario adottare alcuni passaggi per utilizzare specifici elementi di dati come le chiavi pubbliche. Tuttavia, il protocollo DH non specifica esattamente quando devono essere presi quei passi, né la rappresentazione bit per bit di quei passi. Ancora peggio, ci sono diversi modi per eseguire anche DH. Per avere un'idea basta dare un'occhiata a NIST SP 56 revisione 3 schemi.
INTERLUDE: se leggi questo documento puoi vedere che è effettivamente possibile autenticarsi usando DH stesso. Per questo una chiave pubblica attendibile deve essere disponibile sul lato facendo l'autenticazione. Ciò significa utilizzare una coppia di chiavi statiche per l'entità che deve essere autenticata. Generalmente questo può essere fatto usando un certificato DH (o ECDH). Tuttavia, questi sono difficilmente presenti nella vita reale; la maggior parte dei certificati si basa sulle firme digitali piuttosto che sulla definizione della chiave DH.
Se e in che modo un'entità è affidabile fa affidamento sul protocollo di livello superiore , ad es. un protocollo di trasporto come TLS. Nell'ultima versione TLS 1.3 il cosiddetto accordo chiave effimero-effimero Diffie-Hellman è obbligatorio da utilizzare. In questo caso il contratto chiave è separato dalla parte di autenticazione: i parametri DH sono semplicemente inclusi nell'autenticazione finale ma l'accordo stesso non ha un ruolo in esso.
Questo significa anche che la presenza di un certificato CA attendibile può essere rilevata solo osservando la fase di autenticazione basata su X.509v3 che si verifica dopo la definizione della chiave DH. Cioè: se la DH ha luogo, naturalmente. Te lo aspetteresti per es. autenticazione del server ma possono essere implementati anche altri metodi di autenticazione.
Risposta breve dopo la lunga spiegazione: sì, devi specificarlo insieme al resto del protocollo di livello superiore che tenti di implementare.
if the participants have their own private key and a generated public key
Diffie-Hellman non ha una chiave pubblica e privata. Immaginiamo che tu sia in una stanza con almeno tre persone: Alice, Bob ed Eve. Alice e Bob vogliono parlare in privato (e andare in una stanza diversa è troppo facile), quindi Alice propone di usare Diffie-Hellman:
Alice: Facciamo uno scambio di chiavi DH. Scegli un numero casuale e rilancia 5 alla potenza di quel numero. Dividi il risultato per 23 e dimmi il resto.
Alice sceglie 16, 5**16=152587890625 , e il resto se diviso per 23 è 3.
Mario prende 25, 5**25=298023223876953125 , e il resto se diviso per 23 è 10.
Bob: 10.
Alice: ho ottenuto 3. Ora alza il mio numero al potere di quel numero ancora, e dividi per 23 di nuovo, e prendi il resto.
Alice aumenta Bob's 10 alla potenza 16, 10**16=10000000000000000 , e prende il resto quando divide per 23, 10000000000000000%23=4
Bob aumenta Alice 3 alla potenza 25, 3**25=847288609443 , e prende il resto quando divide per 23, 847288609443%23=4
Hanno ottenuto lo stesso risultato. Hanno un numero comune che Eva non sa. Eve ha solo sentito che Alice ha mandato 3 a Bob e che Bob ha inviato 10 a Alice. Non è in grado di calcolare il numero 4.
Alice: ora usa questa chiave per AES e parliamo di crittografia!
Naturalmente, nel mondo reale, i numeri sono tutti molto più grandi. Indovinare che la password per AES sia "4" non è molto difficile.
Do we need to specify it, put a digital signature in the messages or can we assume authentication whenever there is a public key involved?
Nell'esempio precedente, Alice e Bob potevano vedersi. Se Alice parlava, Bob poteva vedere che era Alice. Su Internet, questo non è il caso. È più come comunicare per lettera: chiunque consegna posta potrebbe iniettare lettere false.
Quindi hai ancora bisogno di firmare digitalmente questo scambio, per essere sicuro che un (wo) uomo nel mezzo non inietti nulla nella conversazione. Diffie-Hellman non può farlo, quindi è necessario un algoritmo aggiuntivo: uno che usi le chiavi pubbliche e private. I sistemi più popolari per farlo sono l'algoritmo RSA e la crittografia a curve ellittiche.
Il modo in cui funzionano le firme digitali viene spiegato abbondantemente altrove. Basta applicare le firme digitali alla conversazione sopra (dove Alice fornisce i parametri 5 e 23, dove Bob dice 10 e dove dice Alice 3) e hai un protocollo di scambio delle chiavi autenticato.
Ma per scambiare le chiavi pubbliche, hai lo stesso problema: come fai a sapere che nessuno nel mezzo ha cambiato la vera chiave pubblica per la propria chiave pubblica? Questo è ciò per cui vengono utilizzate le autorità di certificazione (CA): sono una terza parte attendibile e mettono una firma digitale sulla chiave pubblica. Un altro modo per risolverlo è TOFU: Trust On First Use. Questo ha lo svantaggio che, se la tua prima comunicazione fosse già stata intercettata, la tua comunicazione è stata compromessa. Ma ha il vantaggio che non è necessario alcun sistema CA e quindi non c'è CA che possa essere compromessa.
Leggi altre domande sui tag cryptography digital-signature diffie-hellman