Dalla mia comprensione dell'email PGP, è possibile:
Alice invia un messaggio a Bob. Quindi Bob può prendere lo stesso identico messaggio e inviarlo a Carol mentre lo fa sembrare a Carol come se fosse da Alice a lei.
Questo potrebbe essere evitato se lo standard dovesse firmare anche i destinatari insieme all'email.
La mia domanda è: esiste una pratica standard per proteggersi da tali attacchi di replay?
Il tuo argomento è valido, con Accedi e amp; Encrypt , i 2 livelli sono indipendenti e questo ti dà (come Bob) la possibilità di ricodificare il messaggio di Alice mentre la firma è ancora sul posto e inoltrarla a Carol.
Un'altra opzione potrebbe essere Encrypt then Sign ma esiste anche una vulnerabilità in questo approccio. Bob o qualunque utente non autorizzato può rimuovere la firma e aggiungere la propria firma. Senza conoscere il contenuto del messaggio crittografato, può impersonare se stesso come mittente del messaggio.
Ci sono numerose discussioni su SE, quindi non ne parlerò. ad esempio: Dovremmo firmare-poi-cifrare, o cifrare -Poi-segno?
La soluzione deve aggiungere un'associazione tra la firma e il livello di crittografia perché la vulnerabilità si trova nel divario in cui si trovano questi due livelli indipendenti.
E come hai detto, potremmo aggiungere l'indirizzo del destinatario nella parte crittografata del messaggio.
In questa pagina (Segno e crittografia difettosi in S / MIME, PKCS # 7, MOSS, PEM, PGP e XML) nella sezione 5, vengono proposte cinque opzioni di riparazione:
- Sign the recipient's name into the plaintext
- Encrypt the sender's name into the plaintext
- Incorporate both names
- Sign again the signed-&-encrypted message
- Encrypt again the signed ciphertext.
Per le soluzioni di denominazione delle riparazioni:
Perhaps part of the reason naïve Sign & Encrypt seems secure is that with many common payload messages, S&E is secure. For example, even if Alice just signs and encrypts the text ''Dear Bob, The deal is off. Regretfully, Alice,'' then Alice's message is secure, albeit only accidentally so. The presence of names under both crypto layers is crucial, but including both names is not strictly necessary
Uso di firma / crittografia / firma:
Inner Signature: "Alice wrote the plaintext;"
Encryption: "Only Bob can see the plaintext;"
Outer Signature: "Alice used key B to encrypt."
Utilizzo di Cifra / Firma / Cifra:
First Encryption: "Only Bob sees the plaintext;"
Signature: "Alice wrote the plaintext and the ciphertext;"
Outer Encryption: "Only Bob can see that Alice wrote the plaintext and ciphertext."
Puoi anche trovare l'analisi del rapporto costi / benefici sotto quel link, la riparazione più semplice è l'aggiunta dell'indirizzo del destinatario al testo in chiaro e poi firma e crittografia.
Tornando alla tua domanda principale, sembra che non ci sia implementazione standard per i client PGP per aggiungere / verificare l'indirizzo dei destinatari nel testo cifrato, in modo che uno possa andare avanti e aggiungere / verificare manualmente l'indirizzo nel corpo del messaggio.
Questo è impedito semplicemente, usando una corretta comunicazione umana.
Normalmente, inizi un messaggio con lo stesso tipo:
"Hello Bob
Nice to hear from you again.
bla bla bla"
Quindi Carol, sarebbe facilmente in grado di rilevare questa discrepanza dato che il messaggio non è rivolto a lui / lei, e naturalmente chiederebbe ad Alice "Mi hai inviato questo? Allora hai l'indirizzo sbagliato". e Alice direbbe "No, non te l'ho spedito, il messaggio deve essere stato trapelato e ripubblicato."
Tieni presente che "Hello Bob" deve essere parte della porzione firmata e pertanto non è modificabile dall'utente malintenzionato.
Se non conosci il nome o il destinatario previsto della posta, è normale che il contenuto si distingua in un modo specifico per chiarire che è destinato a una persona specifica, quindi se il messaggio finisce nel torto posta in arrivo, il destinatario capirà che il messaggio non è destinato a lei.
Un esempio potrebbe essere se si invia un messaggio a "support@random_isp.com"
"Hello.
My broadband account just got suspended, my RandomISP customer number is 153424.
Could you check my account details if the latest bill payment has arrived and whats happened if not."
Se questa posta arriverà nella tua casella di posta, sarà chiaro che non è destinata o inviata a te.
Si noti inoltre che esistono altri sistemi come SPF e DKIM, che verificheranno e impediranno l'utilizzo dell'indirizzo e-mail del mittente, che in questo caso darebbe anche via qualsiasi tentativo di replay, dal momento che l'e-mail del mittente non corrisponderebbe alla chiave pubblica che corrisponde alla chiave privata con cui è stata firmata la posta.
Leggi altre domande sui tag email encryption