Ho letto su Firma digitale e si afferma che fornisce non ripudio.
Supponendo che Alice firmi il messaggio utilizzando la sua chiave privata e lo invii a Bob, Bob può utilizzare la chiave pubblica di Alice per verificare la firma, quindi Alice non può negare l'invio del messaggio. Questo dimostra solo che Alice è il mittente del messaggio.
Come può Alice avere la prova che Bob ha ricevuto il messaggio inviato da Alice?
TL; DR Chiunque può inviare un messaggio e dire che è di Alice se non è firmato; Alice non ha modo di dimostrare che non ha inviato quei messaggi non firmati. Tuttavia, Alice può dimostrare che ha inviato un messaggio firmandolo con una chiave privata. Allo stesso modo, chiunque può dire che Bob ha letto un messaggio e Bob non può dimostrare di non averlo fatto. Ma Bob può dimostrare di aver letto un messaggio firmandolo con la sua chiave privata.
Un piccolo punto a parte, ho intenzione di fare una distinzione qui tra avere ricevuto e leggere un messaggio. Posso inviare una mail al tuo server di posta, (e la rete confermerà che è stata inviata), ma se il tuo server sta ignorando tutti i dati in arrivo, anche se la rete dice che è stata ricevuta dal tuo firewall, ciò non significa che il server di posta in realtà legge il messaggio o ha accesso ad esso in qualsiasi modo.
In buona crittografia, si presume che tutti possano ricevere il messaggio , ma solo il destinatario rientrato può leggere . Anche se Alice qui non è in realtà una criptazione specifica per Bob, assumeremo che il messaggio sia pubblicato in qualche modo pubblico che garantisce che Bob potrebbe riceverlo se lo desidera, ma crittografato in modo tale solo da Bob puoi leggerlo (anche se potresti non crittografarlo tecnicamente, richiede semplicemente a Mario di accedere a Gmail con il suo nome utente e password, ma lo stesso principio).
In tal caso, non c'è modo per Bob di dimostrare che non ha ricevuto il messaggio ; dopotutto, Bob poteva scaricare (ricevere) l'e-mail da Alice dal server di posta al suo computer, ma in realtà non aprirlo (leggerlo). Se il messaggio è stato crittografato, potrebbe salvare il messaggio e la sua chiave privata in un computer non in rete e decrittografarlo e leggerlo lì, bruciando il computer dopo che ha finito. Nessuno potrebbe sapere se è riuscito a decrittografarlo con successo e a leggere il messaggio o meno.
Tuttavia, in qualsiasi momento Bob può dimostrare che ha leggere il messaggio firmando il messaggio decrittografato Alice inviato e restituire la firma. L'unico modo in cui poteva accedere e firmare la versione decodificata (che includeva aver letto l'e-mail non crittografata dal suo account Gmail) era se l'avesse letto.
Addendum: Idealmente, Bob firmerebbe il messaggio con la sua chiave privata , ma questo non è strettamente necessario. Finché il messaggio "crittografato" (o inviato in modo sicuro) in un modo che solo Bob può leggerlo, l'unico che potrebbe avere accesso e firmare il messaggio "decrittografato" è Bob *. Se il messaggio non viene crittografato o inviato in modo sicuro, chiunque potrebbe firmare il messaggio di Alice con qualsiasi chiave, sostenendo di essere stato Bob a firmarlo.
* Tecnicamente, c'è una seconda persona che può firmare il messaggio decrittografato: poiché Alice ha scritto l'e-mail a Bob, ha accesso al messaggio non crittografato e potrebbe firmarlo, sostenendo di essere Bob. Se lei vuole solo sapere se Bob ha letto il suo messaggio, sarebbe stato sciocco da parte sua. Tuttavia, se Alice vuole dimostrare alle autorità che è stato Bob a leggere la sua email, Bob avrebbe bisogno di firmare il messaggio decrittografato con la sua chiave privata (a cui Alice non avrebbe avuto accesso).
In pratica, a meno che Bob non invii una ricevuta firmata, sei sfortunato.
Il problema crittografico sottostante è chiamato fair exchange . Se si considera un protocollo di rete in modo tale che Alice e Bob vogliano inviarsi reciprocamente alcuni elementi di dati (ad esempio nel caso di una e-mail da Alice a Bob e una ricevuta da Bob a Alice, ma funziona anche come modello per i pagamenti), poi Alice e Bob invieranno messaggi. Chiamiamo m a l'elemento che deve essere trasportato da Alice a Bob e m b l'elemento che dovrebbe andare da Bob ad Alice. Quando viene riprodotto il protocollo di scambio, ad un certo punto nella sequenza dei messaggi, Alice otterrà informazioni sufficienti per essere in grado di ricostruire m b . Quel punto sarà immediatamente dopo la ricezione da parte di Alice di qualche messaggio di protocollo di Bob; prima del messaggio, Alice non ne sa abbastanza per ricostruire m a e dopo che lo ha fatto. Allo stesso modo, Bob otterrà anche informazioni sufficienti per ricostruire m b subito dopo aver ricevuto un messaggio da Alice.
Il punto delicato è che non esiste una cosa come la simultaneità. Non è possibile garantire a due persone remote (Alice e Bob) di inviare messaggi contemporaneamente . Così, Alice e Bob ottengono tutto ciò di cui hanno bisogno in momenti necessariamente distinti. Supponiamo che Alice ottenga prima il suo elemento; allora potrebbe semplicemente smettere di rispondere a quel punto. Bob non otterrà mai l'elemento da Alice, mentre Alice ha preso quello da Bob. Lo scambio è ingiusto.
Per avere qualche intuizione su ciò che spiego sopra: supponiamo un semplice protocollo con cui Alice invia un'email a Bob, allora Bob invia una ricevuta firmata. In tal caso, Bob potrebbe ricevere l'e-mail e rifiutarsi di inviare la ricevuta; Alice non avrebbe avuto prove. Per risolvere il problema, è possibile progettare il protocollo in modo tale che Bob invii la ricevuta prima , quindi Alice invia l'e-mail. In tal caso, Alice potrebbe barare ricevendo una ricevuta da Bob, quindi rifiutando di completare il protocollo e inviare l'e-mail.
Ciò che intendo qui è che il difetto è fondamentale. Non può esistere un protocollo bipartitico, per quanto complesso e complesso, che garantisca uno scambio equo. Questo a causa della mancanza di simultaneità.
Ora i risultati impossibili non hanno mai scoraggiato le persone dal provare. Esistono principalmente due metodi per ottenere un protocollo di scambio equo:
Fai in modo che gli imbroglioni paghino per questo. Ad esempio, Alice invia un'email cifrata a Bob, con una chiave simmetrica K a . Bob invia un'e-mail crittografata ad Alice, con una chiave simmetrica K b . Alice e Bob quindi si scambiano le chiavi, un po 'alla volta, una alla volta. O si può salvare il protocollo in qualsiasi momento, con una conoscenza chiave parziale, e cercare di completare la decrittografia attraverso la ricerca esaustiva dei bit chiave mancanti. Un imbroglione avrà quindi un vantaggio rispetto all'altro, ma solo di un bit nella forza bruta risultante. C'è qualche ingiustizia rimanente, ma solo piccola.
Affinché un protocollo del genere funzioni, è necessario aggiungerne altri, in modo che Alice e Bob possano dimostrarsi reciprocamente che i "messaggi crittografati" inviati sono le cose genuine e non alcuni pezzi di spazzatura casuale. Ci sono molti dettagli di cui preoccuparsi.
Avere una terza parte affidabile. Questo è il modello dei servizi postali esistenti in tutto il mondo. Alice consegna la lettera al servizio postale; il postino quindi assicura che Bob riceverà la lettera solo dopo aver firmato la ricevuta. Questo funziona perché sia Alice che Bob si fidano del postino: Bob sa che il postino gli gli darà la lettera, e quindi non ha problemi a firmare la ricevuta prima di avere la lettera nelle sue mani; Alice sa che il postino non consegnerà la lettera a Bob senza ricevere prima una ricevuta e il postino restituirà la ricevuta ad Alice.
Le e-mail standard non seguono alcun metodo al momento. Alcune persone eseguono servizi basati sul Web in cui svolgono il ruolo di terze parti attendibili; Non sono sicuro che nessuno di loro abbia raggiunto alcun livello di significativo successo commerciale. Non sono a conoscenza di alcuna implementazione nell'implementazione selvaggia di un protocollo di scambio equo crittografico.
Se vuoi richiedere a Mario di far sapere a Alice ogni volta che Bob ha ricevuto un messaggio, per quanto ne so non esiste alcun sistema integrato nei più comuni sistemi di crittografia. Dovresti uscire per un po 'dalla crittografia e richiedere un server che tenga traccia ogni volta che viene scaricato un messaggio.
Ad esempio, Alice potrebbe inviare un URL segreto a Bob che gli dice dove può trovare il messaggio. Quando Bob apre quell'URL, il server dall'altra parte tiene traccia che Bob ha avuto accesso all'URL, invia una ricevuta ad Alice e invia i dati a Bob. Se vuoi essere pedante, c'è sempre la possibilità che Bob dica che la richiesta dell'URL non è stata completata, e sebbene abbia inviato una richiesta per un messaggio, c'era un problema di rete e non ha mai ricevuto e letto i dati.
Questa parte successiva doveva essere un commento, non parte della risposta, ma è troppo lunga per il campo del commento:
Potresti ideare un elaborato sistema crittografico in cui ogni volta che Bob accede all'URL che riceve (1) un singolo carattere del messaggio e (2) un piccolo bit di dati che deve firmare con la sua chiave privata. Memorizza il personaggio (aggiungendolo ai dati che ha già ricevuto), quindi firma e rimanda il bit di dati per ottenere il carattere successivo del messaggio.
Alice può quindi provare esattamente quali caratteri nel messaggio che Bob ha ricevuto. Bene, quasi esattamente . Tieni presente che Bob poteva sempre dire "Ho ricevuto 499 caratteri, ma non il 500 ° carattere, quindi non ho ricevuto l'intero messaggio." supponendo che si sia rifiutato di restituire la prova di lavoro per l'ultimo carattere che ha ricevuto.
Alice potrebbe anche farlo su una base per messaggio piuttosto che su base di carattere. In ogni messaggio, Alice invia istruzioni su come decrittografare il messaggio di testo (magari includendo un blocco temporaneo). Non può mai provare che Bob ha letto l'ultimo messaggio che ha inviato, ma se può provare che Bob ha letto un singolo messaggio , può provare che Bob ha letto ogni messaggio prima di quello em>.
C'è un solo modo in cui Alice può davvero provare che Bob ha ricevuto il suo messaggio:
Anche con la digitazione asimmetrica, puoi avere garanzie ragionevoli che il canale di comunicazione sia sicuro e che il destinatario previsto stia ricevendo i tuoi messaggi.
Puoi garantire che la chiave privata di Alice sia stata utilizzata per crittografare un messaggio. Puoi garantire che la chiave privata di Mario sia stata utilizzata per firmare la ricezione di un messaggio. Quello che non puoi provare è se Alice o Bob fossero i portatori di quelle chiavi al momento della trasmissione.
Il mio punto è che non c'è modo di fornire, in modo matematico, una comunicazione sicura dei messaggi distribuiti. Il tuo caso migliore si scontra prima con un asintoto di mattoni che non può essere superato, quindi parole come "prova" e "garanzia" dovrebbero essere evitate. Il tuo scenario migliore è "Ehh, è abbastanza vicino."
L'unico modo per Alice di garantire che Bob riceva il suo messaggio è di consegnarlo fisicamente a lui, e ciò vale solo se Alice riesce a identificare fisicamente Bob, immancabilmente.
Leggi altre domande sui tag authentication certificates