Re: One-way authentication

On Tue, Jul 11, 2006 at 12:26:58PM +0200, [email protected] wrote:
* >personalmente lascerei perdere timestamp e simili, HMAC mi sembra una=20
* >soluzione ragionevole (adottata da IPSEC e compagnia ad esempio). HMAC=
=20
* >sta per Message Authentication Code basato su Hash functions, RFC-2104=
.=20
* >L'idea =E8 molto facile: client e server hanno un segreto in comune=20
* >(chiave simmetrica) e l'impronta dei dati =E8 calcolata aggiungendo ai=
=20
* >dati la chiave che per=F2 ovviamente non =E8 inviata all'altro.
*=20
* Scusa ma non =E8 lo stesso meccanismo di cui stavamo discutendo prima?
* Il _dato_ che dovr=F2 aggiungere dovr=E0 avere un valore variabile (com=
e il=20
* timestamp GMT di cui parlavamo) altrimenti MITM pu=F2 replicare ugualme=
nte la=20
* sequenza.=20

magari ho capito male, ma avevo capito di usare un timestamp come=20
chiave, e la mia esperienza sulla sincronizzazione degli orologi mi=20
suggerisce di lasciar perdere od avere una grande finestra, il che non =E8=
=20
chiaro quanto possa essere utile.

Per il resto, cosa ti preoccupa? un MITM, un replay-attack e cos'altro?=20
HMAC va bene per MITM, ma da solo non fa nulla per un replay-attack. Se=20
vuoi proteggerti da tutti gli attacchi, finisci che riscopri SSL/TLS,=20
IKE o simili (e addio al one-way)

Tieni conto che la maggior parte dei protocolli attuali fanno=20
l'autenticazione utilizzando nonce e simili (ovvero se voglio essere=20
sicuro di chi tu sia, ti mando un numero casuale, tu lo firmi/hmac al=20
momento e me lo rimandi)

--
Andrea Pasquinucci                     [email protected]
PGP key: http://www.ucci.it/ucci_pub_key.asc
fingerprint =3D 569B 37F6 45A4 1A17 E06F  CCBB CB51 2983 6494 0DA2
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List