Una chiave pubblica o un'impronta digitale hard-coded protegge contro MITM?

Potenzialmente sì, protegge dagli attacchi man in the middle ma ci sono 2 problemi con esso

1. Come si ottiene il software all'utente? Anche questa connessione deve essere protetta.
2. Cosa succede se viene rivelata la chiave privata? Non c'è modo di revocare il certificato.

L'HSTS (HTTP Strict Transport Security) funziona con le impronte digitali dei certificati codificate nei browser. Ciò presuppone che la catena per ottenere il browser sia sicura o che utilizzi HSTS (ad esempio si ottiene Windows 10 solo il disco da una fonte attendibile che ha IE11 e Edge che supportano entrambi HSTS, li si usa per scaricare chrome da link che utilizza HSTS) Per mitigare 2, aggiungi due impronte digitali del certificato, usane solo una quindi se quella cert non è più sicura inizi a utilizzare l'altra e revocare il primo.

Perché questo è potenzialmente eccessivo? Questo aggiunge solo protezione dagli attacchi MITM attivi, i normali scambi di certificati funzionano nel proteggerti dal MITM passivo. Gli attacchi MITM attivi sono molto costosi da eseguire perché è necessaria una CA per fornire un certificato per un dominio che non si possiede (ciò dovrebbe essere impossibile ma è successo in più di un'occasione) o inserire il proprio certificato CA sul PC della vittima.

Lo scambio di chiavi TLS non consente non rilevato MITM

I protocolli esistenti, ad es. HTTPS / TLS non forniscono realmente un'opportunità per il MITM, lo scambio di chiavi è sicuro. Le autorità per la firma dei certificati potrebbero essere compromesse, ma le tecniche esistenti come il blocco delle parole chiave lo impediscono: si potrebbe pensare allo standard HPKP come l'implementazione consigliata di "una chiave pubblica o un'impronta digitale codificata".

Gli svantaggi sono semplici: in primo luogo, se una determinata chiave pubblica è codificata nel client, diventa molto difficile per il legittimo proprietario modificare la propria chiave pubblica quando necessario, ad es. ruotarlo periodicamente o revocare una chiave compromessa; e in secondo luogo, devi comunque ottenere la chiave iniziale da ogni server al client che ti riporta indietro a tutti i problemi di distribuzione chiave / scambio di chiavi.

Ecco come funzionava nei vecchi tempi dei computer:

1. Alice invia i dati UNINCRYPTED a un server, tramite un ROUTER

2. Il server rinvia i dati UNINCRYPTED, UNSIGNED ad Alice

Bob può, se la sua scheda di rete è abbastanza buona, dire "Sono ora il router" e leggere facilmente TUTTI I DATI che Alice invia al server

Quindi un uomo nell'attacco centrale può facilmente accadere.

Ecco com'è stato, prima che la sicurezza fosse implementata

Ecco com'è ora:

1. Alice invia DATI CRIPTATI a un server tramite router
2. Il server decrittografa i dati, con un tasto VERIFICATO, FIRMATO.
3. I dati crittografati vengono inviati ad Alice.

Un uomo nel mezzo è ora abbastanza difficile da fare, ma poi qualcuno può entrare nella prima connessione all'autorità di sicurezza e cambiarlo nella propria.

Tutto quello che stai facendo è cambiare la seconda parte in un'altra fase di verifica. L'utilizzo del riconoscimento facciale è probabilmente il modo migliore per crittografare tali dati.

Puoi cercare Computerphile Network Security se questo non aiuta.