Three Message Authentication Protocol

Question

Three Message Authentication Protocol

#1 da (2 voti)
#2 da (2 voti)
#3 da (1 voti)

1

Ho un protocollo in cui "A" inizia la comunicazione con "B". "B" quindi invia una sfida per verificare se "A" è realmente "A". "B" non ricorda di aver inviato la sfida, quindi "A" deve rispondere inviando la sfida insieme alla sfida crittografata con la sua chiave.

Esempio:

A ----Hi i am A-----> B
A <-- challenge --- B
A --- Challenge + Encrypted challenge ---> B

Modified

A ----Hi i am A-----> B
A <-- challenge + encrypted challenge with "B" key --- B
A --- Encrypted challenge with A+B Key ---> B

Uno di questi due protocolli è sicuro per "A" che si autentica su "B"?

authentication cryptography protocols nonce

posta Rebratorius097 30.11.2011 - 18:32

fonte

3 risposte

Leggi altre domande sui tag authentication cryptography protocols nonce

Sicurezza del servizio Web Creazione di una password per un nuovo utente quando la sua prima azione * non * lo sta cambiando

score 2 · Answer 1

A ----- says wants to contact B ----------------------->  B

A <---- encrypt some challenge with his private key ----  B

A ----- decrypt the challange with B public key
    encrypt the challange with A private key
    encrypt the challange with B public key
    send both to B ------------------------------------>  B

    decrypt the challange with A public key   ---------   B
    decrypt the challange with B private key
    they are the same? ok, so I could open a
        a message to me (good) that was sent
        from someone who have the A private key.

Problemi con questo:

B ha la chiave pubblica di A?
In caso contrario, dove lo ottiene? (risposta: qualche PKI?)
Se sì, è sicuro che le chiavi appartengano ad A? (risposta: certificato)
e verifica che la chiave di A sia valida (risposta: CRL o OCSP)
A ha la chiave pubblica di B? Si applicano le stesse domande.

Facendo quelle verifiche, funzionerebbe. Non farlo vuol dire che avresti un problema con:

A non sapendo che ha contattato B
B non sapendo che ha ricevuto un messaggio da A

score 2 · Answer 2

Il tuo requisito non è molto chiaro, non so cosa intendi con "A autenticarsi a B" (Cosa sa B a priori di A? Come testare un'autenticazione corretta?), né da encrypted challenge (crittografato da cosa). Ma la risposta è probabilmente no. Nessuno di questi protocolli garantisce che A mandi l'ultimo messaggio.

Supponendo che solo A possa produrre encrypted challenge da challenge , allora tutto questo protocollo (entrambe le versioni) garantisce che A ha ricevuto una sfida che si presume essere di B. Se A produrrà solo il suo secondo messaggio dopo aver provato a contattare B, quindi il tuo protocollo garantisce anche che A abbia provato a contattare B ad un certo punto. Ma un attaccante può almeno eseguire un attacco di replay: registra (e forse blocca) la risposta di A nel primo passaggio, quindi invia (eventualmente dopo averlo modificato) a B.

Nota che anche se B si ricordasse che aveva inviato la sfida, questo non sarebbe di aiuto. L'attacco richiede solo che l'attaccante possa vedere la sfida.

Per costruire un protocollo sicuro, devi prima essere più rigoroso sulle tue definizioni: che tipo di chiave (tipicamente condivisa o simmetrica o asimmetrica) e che cosa significhi concretamente i tuoi requisiti di alto livello. Quindi dovrai pensare all'integrità del messaggio (cosa impedisce a un utente malintenzionato di modificare un messaggio in transito?). Un modo semplice per garantire l'integrità del messaggio è quello di autenticare il messaggio, e ciò richiede (tra le altre cose) che A codifichi la sfida con un segreto che A conosce.

score 1 · Answer 3

Per costruire un sistema di risposta alla sfida sicuro in cui la sfida viene dimenticata dal server prima che la risposta venga restituita, devi assicurarti che un intruso non possa inviarti una risposta a una sfida che non hai inviato o una sfida rivolta a qualcun altro o una sfida vecchia o già utilizzata.

Prima di tutto, puoi assicurarti che tutte le tue sfide siano autentiche "firmandole" in qualche modo. Non è necessario utilizzare i tradizionali protocolli di firma per fare ciò poiché non è una firma generica. Invece, prendi la tua sfida esistente, aggiungi una stringa "segreta" e prendi un hash crittografico del risultato (ad esempio SHA-256). Quindi includere l'hash come parte della sfida. Quando si ottiene una risposta dal client, è possibile verificarne l'autenticità ripetendo il processo e confrontando l'hash trasmesso con quello calcolato. Se lo spazio è un premio, devi solo includere un piccolo sottoinsieme dell'intero hash.

Per assicurarti che le sfide non possano essere utilizzate per autenticare contro l'account di qualcun altro, puoi rendere la parte di identificazione dell'account della sfida stessa o parte dell'autenticazione sopra descritta. Cioè, invece di appendere una stringa "segreta", puoi aggiungere sia il nome utente AND una stringa segreta, e poi l'hash THAT. Allo stesso modo, puoi collegare le sfide a un dato ID di connessione, indirizzo IP dell'host, ecc., Incorporando tali informazioni nella firma.

Infine, puoi rendere le sfide sensibili al fattore tempo incorporando l'ora corrente nel contenuto della sfida e puoi impedire gli attacchi di riproduzione dando a ogni sfida un ID e non consentendo risposte che si riferiscono a un ID già utilizzato.

Il tuo sistema può apparire come questo, ad esempio. Si noti che questo esempio è appena fuori dalla mia testa, mentre il vostro dovrebbe probabilmente essere un po 'più sofisticato di questo. Ma questo almeno dimostra come un sistema del genere potrebbe funzionare.

Client:  
 say: My name is "Alice"

Server:
 *    super-secret key is "swordfish"  
 *    sha1sum("Alice|30Nov11@12:03|swordfish")="4f9167de1e754d...."
 say: Please sign this string: "Alice|30Nov11@12:03|4f9167de1e"  

Client:
  * password is "mustang"
  * sha1sum("Alice|30Nov11@12:03|4f9167de1e|mustang")="6148f8d7bd9eeb6...."
  * say: Challenge was "Alice|30Nov11@12:03|4f9167de1e"
  * say: Response is "6148f8d7bd9eeb6c9156c5be385e96871721f6df"

Server:
  * verify that user's name is in the challenge
  * verify that timestamp is no more than 5 minutes in the past
  * verify that "4f916..." corresponds to challenge with checksum replaced by "swordfish"
  * verify that response is challenge with user's password appended