2010/1/19 Rissone Ruggero: [...] > Me lo ricordo...se non erro avevano attivato una funzione "dimenticata" > all'interno della > centrale Ericsson, modificando porzioni di codice che agivano sia > sull'Intercept Access > Point che sull'Intercept Management System. [...]
Il sistema era estremamente complesso da "esploitare" anche per chi è estremamente esperto della tecnologia, ed è un caso molto raro di "hacking" estremamente complesso portato alla luce del pubblico. > Comunque, con tutte i sistemi di LI che si possono implementare, vorrei > sapere come > intercettare una comunicazione tra due cellulari che, opportunamente > modificati nel > firmware, effettuano un pre-encrypt dell'audio con un algoritmo "inventato" > (una versione > moderna dello scrambling)e condiviso con il/i terminali chiamati. Se effettui una criptazione su una criptazione è chiaro che, anche se sei l'"owner" della prima criptazione, devi "crackare" ancora la seconda per conoscere il contenuto del messaggio. Come dire che usi un tunnel SSL dentro ad una VPN: anche se sei colui che gestisce il VPN concentrator, non sei in grado di leggere il messaggio se non hai accesso alle chiavi del secondo tunnel. Quello che è vero è che se hai accesso al core switching della rete, soprattutto in caso di mobile, hai un deciso vantaggio, per una serie di motivi. Le comunicazioni GSM (basate su A5/3) sono non solo difficili da crakkare: il vero problema è l'intercettazione, individuare la comunicazione corretta in mezzo a tutte le altre e seguire il frequency hopping e il re-key della criptazione. Se ti trovi al "centro" del sistema hai risolto questi problemi, che sono quelli più importanti, probabilmente. > Da evitare ovviamente i terminali con tali caratteristiche attualmente > disponibili sul > mercato i cui algoritmi, presumo, siano gia' ben noti alle forze di Polizia. Mah, per esempio, se usi Skype dal cellulare, l'intercettazione la vedo dura... > Intercettazioni 2.1 : la presunta debolezza dell'A5-3 apre nuove scenari > (Notizia riportata > su piu' blogs e siti)...Onestamente mi sembra una mezza "bufala", visto che > richiede un > tempo di 11.6 giorni per acquisire i dati necessari per il cracking (che > invece e' > abbastanza rapido, 2 ore), periodo nel quale il cellulare non deve mai essere > spento e > non deve nemmeno cambiare stazione base... [...] Esattamente. Ma non c'è solo questo. A parte i problemi che ho enunciato prima, e giustamente le tecniche che spieghi tu (che comunque sono possibili da implementare, visto il modo in cui funzionano i cellulari, ma non posso spiegare oltre qua...), la tecnica di decriptazione che viene riportata in blog e siti - estremamente disinformati ed eccessivamente scandalistici... - è semplicemente non applicabile. Non posso anche qua per ovvi motivi spiegare pubblicamente i dettagli del perché (essendo proprietà intellettuale anche dell'azienda dove lavoro ed informazione riservata) ma possiamo sgomberare il campo da alcuni equivoci. L'attacco non è stato elaborato contro A5/3, ma contro l'algoritmo Kasumi. *Kasumi non è A5/3*. A5/3 è una costruzione, che *utilizza* Kasumi. L'attacco mostrato è di tipo "related key", che ha bisogno per funzionare di fare alcune supposizioni molto ottimistiche. In alcuni casi, è possibile fare queste supposizioni (vedi WEP...), in altri, come nel caso di A5/3, semplicemente no. (per chi non lo sapesse: un "related key attack" - http://en.wikipedia.org/wiki/Related-key_attack - è un attacco dove si assume che l'attaccante possa costringere la vittima a criptare messaggi scelti dall'attaccante, utilizzando una chiave differente da quella della vittima ma che "funzioni" ugualmente. In molti casi reali è impossibile che questo accada a livello pratico ed è il caso di A5/3). Seppure il lavoro pubblicato (http://eprint.iacr.org/2010/013.pdf), sia un gran bel pezzo di criptografia, A5/3 non è intaccato da esso. A5/3 non è un algoritmo, ma un full strength cipher che utilizza questo algoritmo, tra le altre cose. Cordiali saluti -- Marco Ermini r...@human # mount -t life -o ro /dev/dna /genetic/research http://www.linkedin.com/in/marcoermini "Jesus saves... but Buddha makes incremental back-ups!" ________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List
