Il mio approccio all'autenticazione basata su certificati anonimi HTTP e al suono di messaggistica privata sicura?

1

Sto provando a elaborare un sistema di messaggistica sicuro un po 'anonimo e speravo che qualcuno potesse convalidare il mio approccio generale. Tieni presente che tutto avviene su HTTPS.

Autenticazione

Mentre il trasporto supporta l'autenticazione del certificato client a livello di protocollo, non vogliamo dover emettere certificati e non vogliamo averli firmati. Le opzioni mod_ssl / Apache sono none, facoltative, require e optional_no_ca - sfortunatamente non c'è niente come require_no_ca.

  1. Il client genera una coppia di chiavi pubblica / privata - chiavi RSA a 4096 bit o una chiave EC (utilizzando le curve brainpoolP512r1 o NIST P-521).
  2. Il client richiede una sfida dal server, inviandolo come chiave pubblica.
  3. Il server genera una sfida: una quantità enorme di dati casuali (ad esempio un byte [] 8 volte la dimensione del blocco del codice). Il server crittografa la risposta con la chiave pubblica del client.
  4. Il client accetta la risposta, la decrittografa, genera un hash SHA-512 e lo restituisce al server.
  5. Il server verifica che l'hash corrisponda e, in caso affermativo, il client sia autenticato.

Non abbiamo bisogno di login o password, solo certificati client. Se si desidera il controllo degli accessi al server, i certificati client potrebbero essere autorizzati o potrebbe essere utilizzata un'autenticazione con nome utente / password più tradizionale.

Comm da client a client

  1. I client scambiano le chiavi pubbliche. Questo ha tutti i vecchi problemi di PKI - revoca, ecc. Che non voglio davvero entrare. Quindi questo avviene manualmente tra i clienti fuori banda.
  2. Il client A invia al server una richiesta di handshake con una chiave pubblica ECDH e la chiave pubblica del mittente che è crittografata con la chiave pubblica del client B. Il server non ha un record del mittente.
  3. Il client B si connette al server e richiede qualsiasi messaggio. Il server invia il messaggio al client B. Il client lo decrittografa e controlla il mittente contro l'elenco delle chiavi pubbliche che è già. Se ha la chiave, genera una coppia di chiavi ECDH e invia una risposta al server con la chiave pubblica della coppia di chiavi ECDH, che è crittografata con la chiave pubblica del Cliente A.
  4. Il client A ottiene la risposta di handshake e dal suo cliente A & B può iniziare a comunicare usando il loro segreto condiviso, attraverso il server. Il segreto condiviso verrà utilizzato per crittografare i messaggi tramite AES-256 (GCM, senza padding)
  5. Ulteriori messaggi genereranno nuove coppie di chiavi ECDH (e quindi effimere), piggybacked in cima ai messaggi precedenti, quindi il tasto AES per le comunicazioni client < - > client ha una perfetta segretezza in avanti.

Il contenuto del client è tutto crittografato in modo che il server non possa vedere i messaggi. Funziona fondamentalmente come un negozio e il trasporto in avanti per i messaggi del cliente. L'autenticazione basata su CERT ci consente di spedire messaggi a singoli clienti su richiesta.

Mi piacerebbe qualsiasi feedback.

    
posta Mark 10.02.2014 - 23:59
fonte

0 risposte

Leggi altre domande sui tag