Valutazione del criptosistema per l'autenticazione e keyexchange

1

Sono uno studente di master in informatica che lavora part-time con la mia azienda come consulente.

Il mio ultimo progetto è basato sulla mia tesi di laurea che gestisce tutto tranne la sicurezza. L'applicazione verrà verificata da una società molto più grande di quelle che mi hanno assunto e un requisito nella verifica è il doppio livello di sicurezza su tutti i canali.

Il primo strato sarà ovviamente ssl / tls. Per quanto riguarda il secondo, ho trovato il seguente.

  • Autenticazione dell'accesso al digest HTTP - per lo scambio di credenziali
  • DHKE - per creare un segreto condiviso che in seguito viene utilizzato per trasportare un tasto AES.
  • RSA - per firmare digitalmente la risposta dal server per garantire che non ci sia un uomo nel mezzo.

Il mio primo pensiero è stato quello di utilizzare RSA per trasportare in modo sicuro la chiave. Ma ho pensato che avrei potuto ridurre l'overhead usando DHKE. Correggimi se sbaglio.

Il protocollo funzionerebbe in questo modo:

Client-> (username + public information for DHKE) -> Server
Server-> (B from DHKE, salt for HTTP digest, AES key encrypted with DHKE secret) -> Client
                 (Whole message signed with server private key)
Client-> AES(Hashed information for HTTP digest) -> Server
Server-> AES(Session token) -> Client

Una volta avviata la sessione, tutti i messaggi verranno crittografati con il tasto AES. Probabilmente sto pensando troppo a questo e mi mancano molti dettagli e apprezzerei molto qualche consiglio.

Cordiali saluti Johan Risch

    
posta Risch 19.04.2014 - 18:00
fonte

1 risposta

2

Dici questo:

one requirement in the audit is dual layer of security on all channels

e questo dice tutto. I tuoi auditor non capiscono come funziona la crittografia o persino la sicurezza. Se fossero medici, avrebbero raddoppiato le dosi per tutte le medicine; quando trapiantano un rene, cercano di agganciare un rene in più; quando devono tagliare una gamba rimuovono anche l'altra, solo per essere sicuri.

Dato che l'audit sarà fatto sotto tali auspici irrazionali, il meglio che si possa sperare è di fare qualcosa che formalmente rispetti il rituale "doppio strato", ma è comunque abbastanza innocuo. Ciò significherebbe incapsulare due SSL: all'interno di un tunnel SSL, basta eseguirne un altro (con algoritmi distinti, in modo che gli auditor non si accorgano di quanto siano ridicoli). Se vuoi veramente ascoltarli, usa un'altra libreria per SSL interno, ad es. OpenSSL all'esterno e GnuTLS all'interno.

Rendere la propria implementazione di un protocollo esistente è piena di pericoli; progettare il proprio protocollo ancora di più. Non farlo se puoi evitarlo. Riutilizzare i protocolli esistenti e le implementazioni esistenti ti farà risparmiare un sacco di tempo e generano molte meno vulnerabilità.

    
risposta data 19.04.2014 - 20:49
fonte

Leggi altre domande sui tag