Titolo

La guerra alla crittografia - alcune questioni tecniche

2 commenti (espandi tutti)

... ma, se gli altri commenti al mio sono della stessa qualita' logica, meglio lasciar stare. Per due ragioni, cruciali.

1) Non discuto con anonimi. Si, lo so, esiste una comunita' in rete per cui rimanere anonimi eccetera eccetera. Conosco la solfa. Discussa su questo blog svariate volte molti anni fa. La mia policy non e' mai cambiata.

2) Non discuto con chi si inventa affermazioni che io non ho fatto. Non ho fatto questa affermazione. Infatti, sull'intera specifica (e secondaria, come ha spiegato Franco Cazzaniga altrove) vicenda Apple-FBI la mia posizione e' agnostica. E, comunque, la richiesta di FBI, come documentato sin troppe volte per doverlo ripetere, NON era di costruire un passpartout universale ma di contribuire ad un patch per il caso specifico.

Fine. Se hai qualcosa di rilevante da dire, dillo. Se hai bisogno di scrivere cazzate nascondendoti dietro l'anonimato, ti prego di cambiare rapidamente aria. Grazie, saluti. 

oh gesussanto.

1)
Desolato.

Mi chiamo Riccardo Poli, ho 38 anni, vivo a Firenze.

Vi seguo da tempo, trovando molto interessanti i pezzi che pubblicate, di cui spesso leggo anche i commenti, trovandoli altrettanto interessanti. Non mi sono mai registrato perché non mi era mai parso di poter dare un contributo alle discussioni; in questo caso invece mi è venuta voglia di partecipare perché l’argomento mi sta molto a cuore.

Mi sono velocemente iscritto inserendo il nick e l’email che son solito adoperare per forum e commenti, e prima di uscire ho postato il mio piccolo contributo.

Mi spiace di non aver rispettato la netiquette di questa comunità, ma nella pagina del modulo di registrazione non ho trovato nessuna indicazione riguardo l’uso di nomi reali. Non ho letto la Guida al sito perché non avevo notato il link nel footer, e nemmeno la Policy sui commenti perché non avevo notato che quelle tre parole nelle istruzioni del form di commento nascondessero un link.

Me ne scuso.

 

Detto questo,

2)
Non mi pare di aver inventato nessuna affermazione e resto dell’idea che l’analogia - ripeto, alla grossa - sia valida.

Quando dici che “Il rischio, evidentemente, esisteva COMUNQUE” enunci un truismo informatico equivalente a dire che qualsiasi porta può esser forzata.

È noto che implementare un sistema informatico inviolabile al 100% è un’impossibilità pratica.

Per quanto accurato possa essere lo sviluppo, ci saran sempre bug, sviste, interazioni non previste sfruttabili per penetrarlo.

Esempi per capirsi: il cosiddetto “jailbreaking” e “rooting” dei telefoni iOS e Android si basa su tecniche di “privilege escalation” che dovrebbero essere impossibili by design nell’implementazione di questi OS.

Eppure finora gli hacker sono praticamente sempre riusciti a confezionare nuovi exploit per realizzarle, dopo ogni aggiornamento degli OS che tappava le falle che rendevano possibili gli exploit precedenti.

Nel caso dell’iPhone 5C di San Bernardino, è da tempo opinione comune degli esperti di sicurezza che sia agenzie statali come l’NSA, sia hacker privati, possano avere a disposizione multipli metodi di attacco (sia solo software, che con modifiche all’hardware).

Il punto da portare a casa nell’interpretazione della vicenda è che è plausibile affermare che se il governo americano avesse davvero voluto a tutti i costi decrittare l’iPhone aziendale del terrorista morto, avrebbe potuto già farlo, se non tramite l’FBI, con l’intervento dell’NSA.
Come poi è stato in grado di fare rapidamente una volta che l’offensiva legale contro Apple si è arenata.

Va detto di passata che l’FBI ha anche commesso una grave leggerezza ordinando il reset della password dell’account iCloud del terrorista, compromettendo un possibile metodo di recupero dei dati decrittati. Per chi volesse approfondire:
http://arstechnica.com/tech-policy/2016/02/apple-we-tried-to-help-fbi-terror-probe-but-someone-changed-icloud-password/

 

Però, l’FBI ha deciso di tentare la strada di obbligare Apple, attraverso un’interpretazione dell’All Writs Act e altri strumenti legali, a scrivere una versione speciale del firmware priva dei meccanismi di protezione contro il brute-force.

Questo aggiornamento speciale avrebbe dovuto essere consegnato all’FBI che avrebbe potuto installarlo su qualsiasi iPhone 5C in suo possesso.

Qui, il punto da portare a casa è che grazie ad un software del genere, un attacco alla crittografia di un iPhone 5C passa da essere una tecnica complicata alla portata di pochi attori, ad un procedimento semplice eseguibile con modeste competenze e attrezzatura - alla portata di qualsiasi laboratorio forense, agenzia privata, o associazione a delinquere!, nel mondo.

E che non è difficile immaginare che avrebbe finito per essere contrabbandato al di fuori del controllo dell’FBI.

Direi quindi che, almeno limitatamente ad uno specifico modello di telefono, l’argomento che "SE il produttore coopera ALLORA crea un rischio enorme che prima non esisteva”… non cade.

E ulteriormente, non cade in un senso più generale, relativo al piano inclinato che un precedente legale del genere (obbligare un produttore a scrivere software secondo le specifiche di una agenzia governativa) avrebbe inevitabilmente creato.

In primo luogo, direttamente, che l’FBI avrebbe potuto cominciare a esigere versioni compromesse di qualsiasi sistema software.

In secondo luogo, con l’effetto che una consuetudine del genere avrebbe avuto sul dibattito politico sulla sicurezza informatica.

Intendo dire… facciamo un esempio.

Il firmware modificato richiesto ad Apple si basa su due caratteristiche dell’iPhone 5C per rendere possibile un attacco brute-force:

a) il contatore dei tentativi di password che distrugge la chiave di cifratura del disco al 10° tentativo è accessibile e modificabile dal firmware;

b) il firmware può essere aggiornato senza che sia richiesto di inserire la password dell’utente (questo era stato previsto per facilitare l’assistenza tecnica).

Sugli iPhone 6 e successivi, il vettore d’attacco a) non esiste più - il contatore è implementato in un area dell’hardware che il firmware non può modificare.

Inoltre, Apple sta verosimilmente valutando di eliminare anche b) semplicemente richiedendo la password per l’aggiornamento del firmware.

Ora, in uno scenario in cui i produttori software sono obbligati a fornire versioni indebolite dei propri sistemi al governo, non è ragionevole immaginare che verrebbe poi inevitabilmente dibattuta anche la libertà del produttore di implementare migliorie che rendano via via sempre più difficile continuare a sviluppare queste versioni “indebolite”?

Il vero rischio enorme sotteso a tutta la vicenda e al contesto in cui si colloca, per me, è l’inclinarsi del piano del dibattito verso uno scenario in cui il software, per essere legale, debba rimanere al di sotto degli standard industriali di sicurezza. Con tutte le conseguenze che questo comporta.

Da qui il taglio “FBI ultimately wants to make crypto illegal” di molte opinioni di esperti.

Un altro dettaglio inquietante sulla postura del governo americano: ad un certo punto, durante la disputa legale, il Dipartimento di Giustizia in un’istanza ha alluso alla possibilità di richiedere ad Apple la consegna del codice sorgente di iOS e delle chiavi per firmarne digitalmente gli aggiornamenti.

“9. For the reasons discussed above, the FBI cannot itself modify the software on [the San Bernardino shooter’s] iPhone without access to the source code and Apple’s private electronic signature. The government did not seek to compel Apple to turn those over because it believed such a request would be less palatable to Apple. If Apple would prefer that course, however, that may provide an alternative that requires less labor by Apple programmers.”

Con il codice sorgente e le chiavi, il governo può facilmente creare aggiornamenti installabili da remoto con cui far fare ad un iPhone praticamente qualsiasi cosa.

http://fortune.com/2016/03/11/apple-fbi-source-code-signature/

 

 

Ora, venendo al punto 1 del tuo intervento originario:

Alla "proposta Obama” si oppone davvero, piaccia o no, un insormontabile ostacolo tecnico.

È già incredibilmente difficile salvaguardare la privacy anche aderendo ai migliori standard correnti e perfezionandoli incessantemente.

Figuriamoci se i sistemi dovessero obbligatoriamente essere indeboliti by design.

Non si può individuare un giusto tradeoff privacy-sicurezza perché trovare un compromesso sulla privacy significa, tout-court, compromettere la privacy. Per tutti. Indiscriminatamente.
A meno di usare software illegali.

Il problema è squisitamente tecnico. Quello politico è rendersene conto.

Una lettura interessante:

https://backchannel.com/why-are-we-fighting-the-crypto-wars-again-b5310a423295

 

Bon, quel che volevo dire l’ho detto, mi scuso per la lunghezza, e m’interesserebbe sapere che ne pensate.

Mi auguro che non trovi anche questo mio commento irricevibile, nel caso me ne starò offline a riesaminare il mio punto di vista.

Saluti,
Riccardo

 

Ah, una cosa interessante a proposito dei fatti franco-belgi: i terroristi di Parigi usavano burner-phones usa e getta senza accesso internet, facendo per lo più solo chiamate vocali a pochissimi numeri.

http://arstechnica.com/tech-policy/2016/03/paris-terrorist-attacks-burner-phones-not-encryption/