Newsgroup: it.comp.sicurezza.crittografia
Titolo: Idea di algoritmo.

Salve a tutti. Premetto che non sono assolutamente pratico di crittografia 
quindi le cose riportate di seguito potrebbero essere concettualmente errate 
se non addirittura inapplicabili. In ogni caso, provo a chiedere ugualmente 
il vostro aiuto. :-)
Sto sviluppando un semplice applicativo di port knocking daemon in cui il 
server, previa ricezione di determinati pacchetti TCP con flag SYN attivo 
mandati dal client su determinate porte, nella giusta sequenza, esegue un 
comando (nel dettaglio: l'apertura di una porta tramite iptables).
Il programma allo stato attuale è completo ma gradirei aggiungere 
un'ultioriore funzione di sicurezza implementando un rudimentale sistema di 
autenticazione.
Il problema di un applicativo di questo tipo è che non stabilendo una 
connessione TCP vera e propria (di fatto i pacchetti viaggiano solo dal 
client verso il server)non dà modo di implementare algoritmi di cifratura a 
chiave pubblica, ad esempio.
L'idea (malsana) che mi è venuta è stata quindi questa:
- Il client manda, all'interno del pacchetto TCP, un hash MD5 risultante dai 
valori di [password + data locale + ora_locale (hh:mm:ss)] (ad es: 
"mia_password|1-17-2006|15:23.33" = "uijXHuxjX9Xj9").
- Il server riceve il pacchetto (diamo per scontato che il server al momento 
della ricezione del pacchetto riporti il medesimo orario di sistema 
(15:23:33)) ed esegue la medesima di funzione di hash 
("mia_password|1-17-2006|15:23.33" = "uijXHuxjX9Xj9"). Se i due hash 
collimano si assume che l'autenticazione sia avvenuta in modo corretto e il 
port knocking daemon può eseguire il comando.
Utilizzando un sistema di questo tipo il valore di hash trasmesso è sempre 
variabile e un attaccante che sniffa l'hash alle ore 15:23:33 del 1-17-2006 
non potrà impiegare lo stesso hash un minuto dopo, ad esempio. Tolte le 
debolzze "di terze parti" (es: se l'ora di sistema delle due macchine è 
diversa non funziona un bel niente) quella appena descritta può apparire 
un'idea sensata?
Ringraziamente anticipati.

 port knocking daemon può eseguire il comando.
A prima vista mi sento di dire che e' abbastanza sicuro contro chi sniffa
soltanto, ma ASSOLUTAMENTE NON SICURO contro the-man-in-the-middle.
Se l' intruso ha la possibilita' di intercettare i pacchetti provvenienti
dal client prende la parte di autenticazione e aggiunge il payload che
vuole che sara' autenticato. Se cliente voleva eseguire "comando uno"
l' attaccante potra' autenticare "comandopericoloso due".
Infatti dovrai prevedere una finestra di tolleranza per gestire i casi
di cambio orario e questo dara' opportunita' a the-man-in-the-middle.
Quindi l' hash dovrebbe coinvolgere l' intero payload del pacchetto da
autenticare, ma a questo punto dovrai riscrivere lo stack TCP perche'
non potrai sapere se il client mandera' un pacchetto con flag SYN
vuoto e dati in quello a seguire, o se il segmento autenticato sara'
spezzato su piu' pacchetti. Con UDP andrebbe bene.
Inoltre e' preferibile HMAC. Trova l' RFC. Non e' molto diverso da quanto
hai descritto, ma e' studiato per essere piu' resistente a "extended
plain text".
Ciao
Roberto.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 
concordo con le osservazioni di Roberto C
a me questa cosa ricorda Kerberos... magari vuoi vedere come avviene la 
comunicazione con il Ticket Granting Server (puoi ricrearlo facilmente)...

 plain text".
Grazie, guarderò. 

 un pacchetto di qualche centinaio di byte venga frammentato...
Avevo capito che il pacchetto iniziale del client avrebbe contenuto un
comando iptables da eseguire se autenticato. Effettivamente mi sembrava
troppo strano. Quindi questo port knocking consisterebbe nel bussare con
pacchetti fidati e senza risposta ne payload oltre il MAC a certe porte
in sequenza e da questo il server decodifica il comando da eseguire?
Se cosi comunque ti conviene autenticare anche la porta e il windows
del pacchetto perche' l' attaccante non li riutilizzi immediatamente, prima
che scadano, con sequenza diversa (magari stando ad osservare per diverso
tempo capisce che sequenze attivare)
Il windows del pacchetto lato client e' dato dal sistema in modo
random o puoi valorizzarlo tu? A meno che non ho preso un' altra cantonata
i pacchetti possono arrivare dalla rete anche con sequenza diversa da
quella di partenza. Quindi per riordinarli puoi usare il campo windows TCP
come seq-number. (ribadisco: se ho capito bene quello che vuoi fare :)
Spero questa volta di aver capito lo scenario correttamente.


 come seq-number. (ribadisco: se ho capito bene quello che vuoi fare :)
No, mi sa che non hai capito dato che questo è un problema di trasporto che 
non mi interessa. :-)
Non sto mandando files da un sock ad un altro, non mi interessa il sn nè 
l'integrità dei dati.
Lato client mando semplicemente dei singoli pacchetti con flag SYN attivo 
verso il server, pacchetti che NON USO per trasportare dati, sebbene essi 
siano TCP, ma solo per "bussare" all'applicativo server.
Prova a cercare "port knock" con google e capirai subito. Vedrai che 
concettualmente è davvero una stupidata.
Per tornare In Topic: opinioni sull'algoritmo ce ne sono? 

 Per tornare In Topic: opinioni sull'algoritmo ce ne sono?
Spero che il contributo che ho dato sia in qualche misura sufficiente
perche altre risorse non ho.
Ciao.


 code. (64 bits complessivi se ritenuti sufficienti.)
Proverò a dare un occhiata a questo campo. 

 Proverò a dare un occhiata a questo campo.
non e' necessario a questo punto. Se non usi socket RAW lascia pure che
l' header sia formato dal sistema. Solo all' hash passa pure la porta
e il numero progressivo del pacchetto nella transazione di knock (che
dovra' far parte in chiaro del payload come campo separato).
Ciao


 Per questo ti ringrazio.
E io ringrazio te per avermi fatto conoscere il protocollo port knock ;)
ciao


 risparimiare il ritardo di 0.2 sec.
Cosi diventa un port knocker su "porta singola". Preferisco attenermi ai 
canoni e impiegare un hash solamente nel primo pacchetto della sequenza.
A questo punto accantono per un attimo la mia idea di algoritmo basato sul 
tempo e chiedo:
Un meccanismo a chiave pubblica non sarebbe fattibile?
Mi viene in mente SSHd che se opportunamente configurato rilascia un 
certificato (sotto forma di file) il quale dovrà essere portato sempre in 
giro da parte di chi intende autenticarsi remotamente, ma sinceramente non 
so come funzioni... Una cosa di questo tipo, ad es, andrebbe più che bene.

 ha scritto nel messaggio 
news:subBf.46988$av6....@tornado.fastwebnet.it...
