Blocco dei certificati e problema di distribuzione delle chiavi

3

I (penso che io) comprenda il concetto di blocco dei certificati . Tuttavia, mi chiedo se, nello scenario peggiore: il certificato sia più sicuro del modello di fiducia gerarchico su cui è costruito? Uno scenario di esempio:

  1. Sviluppo un'app mobile che utilizza connessioni protette
  2. Per crittografare queste connessioni sicure, ho bisogno di una chiave
  3. In passato, usavo HTTPS per le connessioni protette e mi assicuravo che il mio servizio avesse un certificato valido. Faccio affidamento sugli altri per la mia sicurezza.
  4. Ora, non voglio più fare affidamento sugli altri, quindi inizio a bloccare il mio certificato di servizio (diciamo il certificato X). Ciò significa che le CA slanciate non saranno in grado di infrangere la mia sicurezza. Diciamo che appunto la mia chiave pubblica, in modo efficace questo significa che non mi fido di nessuna CA (altrimenti potrei aggiungere una CA).
  5. Questo mi riporta al problema della distribuzione delle chiavi originale, che il PKI doveva risolvere: come distribuire la mia applicazione ai miei utenti? Non voglio che un utente malintenzionato si trovi nel mezzo del canale e sostituisca la mia applicazione con un'altra (e con un altro certificato Y bloccato).
  6. Bene, è facile: io uso HTTPS.
  7. ...
  8. Io uso HTTPS, che controlla i certificati rispetto all'archivio MS Windows, il che significa che devo affidarmi alle CA shifty del passaggio 4.
  9. Sidenote: ogni volta che invio un aggiornamento, un utente malintenzionato (una CA rischiosa) potrebbe essere pronto a intercettare il mio aggiornamento e sostituire la chiave pubblica bloccata con un'altra.

La pagina OWASP indica che il pin può essere aggiunto durante lo sviluppo o al primo incontro. Tuttavia, quando lo si aggiunge durante lo sviluppo, dobbiamo ancora distribuire l'app agli utenti, che ruotano sul problema di sicurezza nel canale di distribuzione. Questo canale di distribuzione potrebbe anche bloccare i certificati, ma alla fine tutto dipende dalla fiducia del tuo primo canale. Nel caso di MS Windows, questo è l'elenco dei certificati MS: anche se Chrome potrebbe controllare il pin di tutti i domini Google, prima devo installare Chrome su una connessione sicura.

Non sto dicendo che il blocco dei certificati non è più sicuro (anche se non sono sicuro del valore aggiunto, specialmente considerando il punto 9), mi chiedo solo se il ragionamento sopra riportato è corretto.

    
posta Michael 01.03.2015 - 12:05
fonte

2 risposte

3

Hai menzionato le applicazioni mobili. Le applicazioni mobili vengono generalmente installate da uno specifico app store controllato dal produttore (l'App Store nel caso di dispositivi iOS e il Play Store nel caso di dispositivi Android). Devi fidarti dell'archivio per consegnare il binario corretto al dispositivo, ma è comunque molto più sicuro del sistema CA che consente a qualsiasi CA di firmare per conto di chiunque.

Sui sistemi desktop, questo problema è molto più difficile. I gestori di pacchetti simili a Linux risolvono principalmente questo problema attraverso l'uso di gestori di pacchetti che verificano i pacchetti firmati con chiavi precaricate. Di nuovo, ti fidi del repository che consegna il pacchetto ma è una superficie di attacco molto più piccola.

    
risposta data 01.03.2015 - 12:54
fonte
0

Distribuzione chiave possibile con DNSsec
È possibile utilizzare il pin cert per distribuire una chiave. Ma solo se quel metodo di distribuzione è autenticato in qualche modo. Ad esempio, è possibile archiviare il pin in DNS e proteggere DNS tramite DNSsec.

Altrimenti, sì, torni a Trust-on-first-use.

E se non sei sicuro che il tuo sistema operativo iniziale sia sicuro, allora sei bloccato con il problema del bootstrap.

    
risposta data 01.03.2015 - 20:26
fonte

Leggi altre domande sui tag