Ottenimento della crittografia End-to-End con TLS

Purtroppo scoprirai che questo non è fatto. Come hai giustamente sottolineato, non permetti al client di connettersi fino in fondo attraverso l'utilizzo di un canale TLS, quindi la decrittografia sul server web o l'endpoint TLS è un dato.

Quindi ciò che le organizzazioni fanno è valutare il rischio e quindi esaminare altri controlli di sicurezza sul server web. Questi includono:

• Isolamento fisico
• Segregazione logica
• Connessioni gestionali separate
• Autenticazione strong
• Monitoraggio dell'accesso amministratore
• Server hardening
• etc

(Esiste una possibile soluzione parziale, che sarebbe quella di eseguire il server Web con RAM crittografata, dischi crittografati e così via, tuttavia questo porta a un impatto significativo sulle prestazioni e non protegge ancora contro un utente malintenzionato che ha ottenuto l'accesso a il webserver.)

Se vuoi una soluzione end-to-end per i clienti che accedono alle loro informazioni personali (che risiedono su un mainframe nella LAN della banca) da un servizio web (ospitato nella loro DMZ) dovrai creare un plugin per il browser per il tuo clienti.

Ciò richiederà loro di spendere un minuto extra (come utente al primo utilizzo) per scaricare & installa il tuo plug-in ... ma non avranno bisogno di privilegi amministrativi sul proprio computer per farlo.

Continuerai a utilizzare 2 sessioni TLS separate, ma avvolgeranno una soluzione end-to-end che crittograferà i dati dell'utente sul mainframe e decrittograferà i dati sul loro client (usando il plugin). Puoi usare PGP (preferisco la crittografia asincrona NaCl) come base per il tuo mainframe per il sistema di crittografia plug-in.

modifica: in alternativa, puoi inviare al tuo cliente un dispositivo (come l'uovo di ebay) o scaricare un'app mobile (come google auth) che può fornire una password basata sul tempo (la password utilizzabile è scaduta / sostituito regolarmente, in genere una questione di secondi, consentendo un PIN breve [~ 8 cifre] per essere sicuro). Quando il cliente richiede informazioni sensibili, il mainframe invierà loro un file ZIP crittografato che è stato protetto prima di lasciare il mainframe. Utilizzerebbero quindi il PIN corrente fornito dal dispositivo / app di autenticazione come password per decrittografare i dati.

Un'opzione tecnologica ancora più bassa (rispetto a un dispositivo / app di autenticazione) consiste nel consentire al cliente di raccogliere un elenco di PIN monouso che possono spuntare non appena vengono esauriti. È possibile richiedere al cliente di ritirare questi elenchi presso la propria filiale locale o inviarli per posta al cliente. Questa è una forma di autenticazione a 2 fattori in quanto il cliente dovrà comunque utilizzare la propria password per accedere al proprio sistema bancario online.

In sostanza, se capisco le tue necessità, tutto ciò che vuoi è di inoltrare la porta di ascolto SSL del mainframe in modo che ascolti su un host nella DMZ. Questo potrebbe essere fatto usando qualsiasi soluzione NAT.

Ecco un'architettura che potrebbe funzionare:

• Genera una coppia di chiavi di crittografia asimmetrica. La chiave privata sarà nota solo a un programma in esecuzione sul mainframe che è l'endpoint finale che recupera i dati.
  • Sul sito web, utilizzare una libreria di crittografia basata su JavaScript sul lato client in grado di generare una chiave di crittografia simmetrica di forza adeguata, come AES 256.
  • Il sito web renderebbe la chiave pubblica asimmetrica disponibile nello script. Utilizzando un'altra libreria Javascript per abbinare lo schema di crittografia asimmetrica del programma mainframe, crittografare la chiave simmetrica, prima di inviare nuovamente al server web. Fai questo su SSL per una buona misura ovviamente per proteggere il trasporto.
  • Il server Web inoltra una richiesta al programma mainframe chiedendo i dati e passa la chiave di crittografia crittografata asimmetricamente generata dal browser web.
  • Il programma mainframe usa la sua chiave privata per decodificare la chiave simmetrica. Quindi utilizza la chiave simmetrica per crittografare i dati sensibili che sta recuperando e li restituisce al sito Web, che lo rimanda al browser Web del cliente.
  • Il browser web del client decrittografa il carico utile.

Questo è il tuo modello di base. A seconda della natura dei dati, dell'unicità delle richieste, ecc., Probabilmente vorrai rendere ancora più interessanti le cose, ad esempio salendo i dati simmetricamente crittografati, determinando la frequenza con cui cambiare le chiavi di crittografia, ecc. E per essere precisi questo non è 100% end to end, in quanto non conosciamo la natura del tuo programma mainframe, o se i tuoi dati sono crittografati a riposo nell'archivio dati, ma penso che questo ti avvicini molto alle tue esigenze, come il web il server o qualsiasi altro hop nel mezzo non sarà in grado di leggere i dati sensibili.

Ci sono varie librerie là fuori che implementano algoritmi di crittografia in JavaScript per fare AES e algos asimmetrici come RSA.

Questa architettura non dovrebbe causare ulteriori problemi ai tuoi utenti come potresti vedere con una soluzione basata su certificati client o installare software aggiuntivo sul loro computer.