Quali sono i rischi inerenti alla connessione a un server a chiave pubblica non affidabile?

La tua preoccupazione è molto valida.

Nel 2000, Ralf Senderek ha scoperto un bug nelle versioni commerciali di NAI dalla 5.5.x alla 6.5.3 di PGP: Chiave -Experiments . Era particolarmente imbarazzante perché implicava l'implementazione della funzionalità "Additional Decryption Key (ADK)" (con obiettivi simili a key escrow), un aspetto del software commerciale PGP che molti già obiettavano in linea di principio. Permetteva a un utente malintenzionato di modificare la chiave di un utente (certificato) per aggiungere la propria chiave come chiave di decrittografia aggiuntiva e quindi decodificare i messaggi intercettati creati con le versioni vulnerabili di PGP. NAI ha rilasciato molto rapidamente versioni fisse e ha anche aggiornato i server delle chiavi per rilevare questo problema e due problemi correlati con i revocatori designati - vedere La risposta di Zimmerman . Nota che GnuPG si rifiuta di supportare ADK affatto.

Ecco un altro esempio, sebbene non con keyserver o PGP. Un attacco di overflow del buffer che "può consentire l'esecuzione di codice arbitrario" è stato visto nel 2010 per almeno un prodotto con certificati X.509. In tal caso, in realtà è accaduto durante una conversazione con un endpoint inaffidabile: Vulnerabilità legata all'overflow del buffer di elaborazione dei certificati yaSSL - CNET

Come puoi evitare questo tipo di problemi? In questo caso specifico, è ovviamente meglio ottenere le chiavi direttamente e in modo sicuro dalla gente con cui si desidera corrispondere. Elenco i protocolli più sicuri del tradizionale (ma non standardizzato e insicuro) protocollo del server dei tasti HKP all'indirizzo Se non si utilizza il recupero dei tasti GPG connessione sicura? .

Oltre a ciò, si applica l'igiene generale del software. Utilizza software ben studiato da gente nota per le pratiche sicure, tieni aggiornato il tuo software, fai attenzione a dove ottieni qualsiasi tipo di dati che elabori sul tuo computer, riduci la superficie di attacco, dividi il processo di elaborazione dei dati, ecc.

Non sono sicuro che ci sia qualcosa di specifico in OpenPGP, ma il problema che descrivi non sembra specifico per questo contesto.

Per quanto ne so, gli exploit che portano all'esecuzione di codice arbitrario (ad esempio basati su overflow del buffer) potrebbero verificarsi con l'elaborazione di qualsiasi tipo di dati non attendibili a priori che potrebbero essere elaborati. Se ciò accade nel codice che ha elaborato una chiave malformata o qualsiasi altra forma di dati probabilmente non importa molto in questo contesto.

Ogni volta che esegui del codice che elabora alcuni dati che non ti fidi già (e in un modo che ti fidi), vuoi che quel codice sia privo di errori, almeno privo di bug che porterebbe a codice arbitrario esecuzione o altri problemi di sicurezza. In questo caso, se i dati vengono utilizzati successivamente da un meccanismo di sicurezza è una preoccupazione secondaria. (Ovviamente si desidera anche che l'implementazione della verifica della firma necessaria sia corretta. Ecco dove è importante per motivi di sicurezza.)

Lo stesso tipo di problema potrebbe verificarsi con uno stack TLS basato su X.509, ad esempio. Si vorrebbe che lo stack TLS non permetta ai certificati non validi di consentire a un utente malintenzionato di ottenere il controllo del proprio sistema (di nuovo, è vero per qualsiasi sistema che elabora un gruppo di byte che non conosce in anticipo). La corretta convalida e verifica del certificato che ti consentirà di avere fiducia nella connessione TLS stabilita una volta che l'handshake è stato completato con successo è molto importante, ma solo una questione secondaria, quindi.

Penso che la differenza principale rispetto ad altri tipi di dati risieda nella difficoltà di implementare correttamente questo tipo di codice. Le strutture di archiviazione utilizzate nel contesto di PGP o X.509 tendono a fare affidamento su ASN.1, che in molti casi può essere chiaro come il fango. Scrivere un codice senza bug che si occupa di ASN.1 non è facile (IMHO).

Penso che la citazione di Thomas (" ... non dovresti fidarti del server delle chiavi ... ") ha più a che fare con il fatto che non puoi fidarti del key server come entità che garantisce per la chiave che serve. Questo è solo un servizio di hosting, al contrario di un editor / editore / autore.