Newsgroup: it.comp.sicurezza.crittografia
Titolo: Usare XTEA per l'autenticazione

Ciao a tutti,
ho un dispositivo embedded che deve inviare dei dati al un PC via
porta seriale. Non è necessario che i dati siano cifrati ma vorrei
implementare per lo meno un meccanismo di autenticazione del PC.
Viste le scarse risorse del dispositivo embedded pensavo di utilizzare
XTEA (
http://en.wikipedia.org/wiki/XTEA
) in questo modo:
1. Il dispositivo invia al PC due numeri a 32 bit pseudo-casuali.
2. Il PC cifra questi due numeri usando come chiave 4 numeri a 32 bit
   che conosce sia lui che il dispositivo (pre-shared key).
3. Il PC invia i due numeri cifrati al dispositivo.
4. Il dispositivo decifra i numeri ricevuti usando la stessa chiave.
   Se ottiene i numeri originali allora può iniziare l'invio dei dati.
Siccome non ho molta esperienza in crittografia volevo chiedervi:
1. Se un possibile malintenzionato "sniffasse" la comunicazione
potrebbe
   vedere sia il testo in chiaro sia quello cifrato: con queste
   informazioni riuscirebbe a risalire alla chiave e quindi in seguito
   ad autenticarsi in modo illecito?
2. Per implementare un meccanismo di autenticazione del genere credo
sia
   più corretto usare un algoritmo di hashing come SHA256 o simili
   purtroppo però risultano troppo pesanti per il piccolo processore a
   16 bit usato dal dispositivo. Conoscete qualche algoritmo di
   hashing "abbastanza" resistente alle collisioni ma al tempo stesso
   molto semplice da implementare?
Grazie in anticipo,
Giuseppe

geppoz ha scritto:

Se non hai necessità di aprire un canale cifrato perché vuoi fare un
sistema di autenticazione a cifratura?
Mi pare uno spreco di tempo e di risorse.
Puoi benissimo scrivere un sistema di autenticazione in chiaro, della serie:
1) il dispositivo invia una sequenza di bit per informare il PC che è
pronto per inviare i dati ed attende una risposta;
2) il PC, che è in ascolto sulla porta, capta la sequenza e risponde
anch'esso con una sequenza  prestabilita e poi apre la connessione;
3) il dispositivo legge la sequenza di risposta ed inizia la trasmissione.
-- 
Ciao.
Leo.
Web: 
www.leonardomiliani.com
E-mail: 
leon...@leonardomiliani.com
Scegli software opensource - Choose opensource software
Co-fondatore di Gambas-it.org
Il sito di riferimento della comunità italiana degli utenti di Gambas
www.gambas-it.org

 Mi pare uno spreco di tempo e di risorse.
Ciao Leonardo e grazie per la risposta.
La mia esigenza è quella di consentire l'uso del dispositivo solo con
il mio software lato PC: se facessi l'autenticazione in chiaro
chiunque
potrebbe gestire il mio dispositivo con un proprio software.
Mi rendo conto che anche con il mio meccanismo di autenticazione
un malintenzionato potrebbe usare il mio software per il login, poi
chiuderlo e riaprire la comunicazione con la porta seriale usando
un suo programma ma sto pensando di evitare anche questa
possibilità in un modo abbastanza semplice.
Farò in modo che il dispositivo continui ad inviare dati alla seriale
solo se ogni secondo riceve dal PC un "codice" che potrebbe
essere ad esempio un numero progressivo codificato sempre
con XTEA e la pre-shared password dell'autenticazione.
A presto,
Giuseppe.
pre-shared password

    semplice da implementare?
nomi non saprei dartene, ma di solito djb (
http://cr.yp.to
) ha soluzioni 
di questo tipo

 pre-shared password
Beh, mi sembra che tu abbia bisogno di aprire un canale cifrato, allora.
Se devi difendere il dispositivo da un uso non autorizzato, devi esser
certo che solo il tuo software possa comunicare con esso e che esso
possa comunicare solo con il tuo software.
Come implementare la cosa?
Io penserei cosě:
1) il software ascolta sulla porta scelta;
2) il dispositivo emette ad intervalli regolari un pacchetto costituito
dal numero seriale del dispositivo e da un timestamp, il tutto
codificato con la pre-shared-key;
3) se il tuo software riceve questo pacchetto sulla porta, lo decifra e
verifica che il seriale sia quello di un dispositivo autorizzato tenuto
in una lista sul PC (magari in formato hash cosě che puoi liberamente
salvarla); se questo controllo č positivo, allora il software risponde
inviando sulla porta seriale un pacchetto costituito dall'hash del
timestamp ricevuto dal dispositivo e da una password casuale, il tutto
cifrato con la pre-shared key;
4) il dispositivo riceve il suddetto pacchetto di risposta e lo decifra
controllando che l'hash del timestamp che ha ricevuto sia identico
all'hash del timestamp che ha inviato in origine;
5) in caso affermativo, risponde con una sequenza prestabilita cifrata
con la chiave ricevuta dal software sul PC, aprendo una connessione cifrata;
6) in caso negativo, ferma le operazioni di autenticazione per un tempo
prestabilito e poi riparte dal punto 2);
7) se il software non riceve risposta dopo il punto 3), dopo un tempo
prestabilito riparte dal punto 1).
In questa maniera hai giŕ una piccola soluzione sul controllo delle
connessioni, in modo da scartare la possibilitŕ che un dispositivo
comunichi con un software non tuo o che il tuo software comandi un
dispositivo clonato.
Inoltre, ad ogni instaurazione del canale cifrato, la password cambia
cosě che le comunicazioni siano relativamente protette dall'utilizzo
della stessa chiave, che viene usata solo per scambiarsi i dati
necessari all'autenticazione fra dispositivo e software.
E' ovvio che un tale protocollo sia molto debole ma penso che rispetto
ad uno scambio in chiaro sia giŕ un gradino sopra.
Leggo piů sotto che il microprocessore č poco potente: non penso quindi
che permetta l'uso di un sistema a chiavi pubbliche, senz'altro piů
sicuro del sistema sopra descritto.
-- 
Ciao.
Leo.
Web: 
www.leonardomiliani.com
E-mail: 
leon...@leonardomiliani.com
Scegli software opensource - Choose opensource software
Co-fondatore di Gambas-it.org
Il sito di riferimento della comunitŕ italiana degli utenti di Gambas
www.gambas-it.org

 di questo tipo
Sul sito ho trovato soluzioni troppo complicate per la mie esigenze ed
anche per le mie competenze :)
Ricordo di aver letto un post di DJB in qualche newsgroup in cui
metteva
in palio 500$ a chi riusciva a trovare una falla su un algoritmo di
hashing
che aveva scritto usando una manciata di shift e xor. Purtroppo
non riesco più a trovarlo...
Grazie e a presto,
Giuseppe


Grazie mille per gli spunti,
Giuseppe

 non riesco più a trovarlo...
Dopo qualche altra ricerca ho trovato l'algoritmo di DJB e molti
altri: 
http://www.partow.net/programming/hashfunctions/
Ora ho l'imbarazzo della scelta :)
Qui (
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/
142054)
ho trovato qualche confronto e sembra che uno dei più robusti
e semplici sia "sdbm".

Vediamo se ti posso suggerire qualcos'altro.
1) hai una pre-shared key, con la quale crei un pacchetto cifrato P
usando l'XTEA contenente il seriale S del dispositivo ed un timestamp T;
2) il PC riceve il pacchetto P e lo decifra: se riconosce il seriale S,
risponde con un pacchetto cifrato P1 con l'XTEA e la chiave comune
contenente il timestamp ricevuto ed un "ticket" TK;
3) il dispositivo decifra il pacchetto di risposta P1 e controlla che il
timestamp sia quello che ha spedito in origine. Se è uguale, prende il
ticket e lo utilizza allegandolo ad ogni pacchetto inviato;
4) il PC, per ogni pacchetto che riceve, deve semplicemente controllare
che contenga anche il ticket TK: se lo contiene, sa che i dati ricevuti
fanno parte della connessione appena aperta con il dispositivo di cui al
punto 1.
Che ne pensi?
-- 
Ciao.
Leo.
Web: 
www.leonardomiliani.com
E-mail: 
leon...@leonardomiliani.com
Scegli software opensource - Choose opensource software
Co-fondatore di Gambas-it.org
Il sito di riferimento della comunità italiana degli utenti di Gambas
www.gambas-it.org

 punto 1.
A questo punto io preferirei costringere il PC ad inviare
periodicamente
un pacchetto che dimostri che il software usato sia sempre quello
autorizzato.

 autorizzato.
Beh, qui puoi semplicemente far sì che il dispositivo non invii il
pacchetto successivo finché non ha ricevuto un "ping" dal tuo software,
ping costituito da una sequenza prestabilita e dal ticket distribuito in
apertura di connessione (secondo uso), per far vedere al dispositivo che
 sta ancora inviando i dati al programma originale.


 dati.
io rimango dell'idea che il challenge inviato da una delle due parti 
debba essere modificato in maniera prevedibile prima di essere rispedito 
all'altra (essendo un sistema simmetrico, rimandare i dati tali e quali è 
una fonte di problemi e attacchi)
cmq per rispondere alla domanda iniziale, su Handbook of Applied 
Cryptography (che trovi su google cercando hac e waterloo) ci sono non 
pochi esempi di protocolli di authentificazione basati su un metodo 
simmetrico. che possono essere usati tutti mettendo xtea al posto 
dell'algoritmo in esempio.

 dell'algoritmo in esempio.
Grazie mille per la segnalazione, mi sembra un ottimo testo.
Mi sa che la cosa migliore è riprodurre il meccanismo di
"mutual authentication, using random numbers" che si trova
a pagina 402 (capitolo 10).
Grazie ancora ad entrambi per i consigli. A presto,
Giuseppe