TLS: l'autenticazione e l'inoltro della segretezza sono possibili senza PKI?

Question

TLS: l'autenticazione e l'inoltro della segretezza sono possibili senza PKI?

Naviga le tue risposte

#1 da (2 voti)

0

Im fare un progetto che consiste in un sistema client / server che richiede TLS senza PKI ..

Requisiti di progettazione:

Il client DEVE autenticarsi che sta comunicando con il server "THE"

Il server DEVE autorizzare che sta comunicando con il client "A"

La comunicazione DEVE essere riservata

La riservatezza di una sessione NON DEVE essere trasmessa sulla riservatezza di una sessione precedente (aka segretezza in avanti)

E l'integrità dei dati trasmessi DEVE essere verificata

Sto pensando di usare DHE per PFS, SRP (o alternativamente PSK) per l'autenticazione con crittografia AES / CBC e SHA per l'integrità.

Le mie domande sono ..

Questo stack di protocolli è possibile?

AES 256 CBC è affidabile per la riservatezza?

Tutti i requisiti saranno soddisfatti da questo design?

E se la password SRP / PSK di un client è ottenuta da una terza parte, sarà in grado di evasdrop su altri client?

ps: sto cercando l'opzione di massima sicurezza possibile

Grazie in anticipo per qualsiasi feedback e scusate per qualsiasi confusione causata, ho appena iniziato a conoscere la crittografia ..

cryptography tls forward-secrecy srp

posta Aristos Miliaressis 12.07.2017 - 21:41

fonte

1 risposta

Leggi altre domande sui tag cryptography tls forward-secrecy srp

False, honeypot come wifi Attacco WannaCry

score 2 · Answer 1

Non è necessario utilizzare un PKI con TLS. L'unica cosa che fa un PKI è rendere la parte di autenticazione della scala TLS. Quando si utilizzano certificati autofirmati, PSK o simili, tutte le informazioni sulla fiducia (come certificati o chiavi pre-condivise) devono essere distribuite a tutti i peer di comunicazione in modo sicuro. Queste informazioni devono anche essere tenute aggiornate, cioè quando vengono aggiunti nuovi partner di comunicazione, i segreti vengono compromessi o simili. Utilizzando una PKI, invece, questo processo viene ridotto alla condivisione dei trust ancore (certificati radice) che raramente devono essere aggiornati e per controllare regolarmente se un certificato è stato revocato. L'utilizzo di PKI ti offre quindi una facile creazione e condivisione di nuove informazioni sulla fiducia e anche la revoca e la sostituzione delle informazioni di trust compromesse.

Se hai già il pieno controllo su tutti i peer di comunicazione e hai anche un modo sicuro per distribuire nuove informazioni di fiducia e anche revocarle se compromesse, non hai bisogno di usare una PKI. Se non hai ancora questa infrastruttura, allora l'utilizzo di una PKI potrebbe essere più facile e probabilmente più sicuro dell'implementazione di tutto da solo.

Per quanto riguarda lo stack specifico del protocollo, si cita: Mentre l'autenticazione PSK / SRP può essere utilizzata in teoria con DHE / ECDHE come scambio di chiavi come dave_thomson @ correttamente sottolineato in un commento qui sotto, questi cifrari sembrano essere implementati raramente. Ma con l'autenticazione basata su certificato DHE / ECDHE è comunemente usato e anche il certificato autofirmato non ha bisogno di una PKI. Inoltre, mentre AES con SHA-256 è cifrario sicuro utilizzando AEAD come i cifrari GCM sono preferiti oggi. E ECDHE è preferito rispetto a DHE.

And if the SRP/PSK password of a client is obtained by a third party will he be able to eavesdrop on other clients?

Se si ottiene il segreto essenziale (chiave precondivisa, password, chiave privata), un utente malintenzionato non sarà in grado di decifrare i dati sniffati se DHE / ECDHE viene utilizzato per lo scambio di chiavi. Non sono sicuro di come si comportano gli scambi di chiavi PSK / SRP in questo senso. Ma in tutti i casi l'attaccante può impersonare il pari e ottenere l'accesso al traffico decifrato all'interno di un uomo nel mezzo dell'attacco. Poiché l'hacker ha il segreto, questo può essere fatto senza che l'altra parte realizzi il problema, cioè l'autenticazione riesce ancora. Questo è uno dei motivi per cui è necessario revocare e sostituire tali segreti - che è già incluso nell'infrastruttura PKI.