Quantcast
Channel: KEIN PFUSCH, BITTE!
Viewing all articles
Browse latest Browse all 561

Il terrore che corre sui numeri. LOL.

$
0
0
Ho nella casella di posta elettronica una ventina di richieste che riguardano tutte lo stesso tema: PRISM ha trovato il modo di "aggirare", dicono, i sistemi di crittazione, per cui succede che anche criptando non sei al sicuro. Aha. LA cosa deve aver terrificato un bel pochino di persone, almeno vista la risonanza che la notizia sta avendo, ma credo di dover dire una cosa. E cioe' che la notizia e' una non-notizia, e che di fatto si dicono cose risapute.



Il primo punto riguarda gli algoritmi di criptazione. Sul design di questi algoritmi si e' sempre speculato, per la serie "ma si poteva fare di meglio". Si, certo: si poteva fare tutto in maniera piu' chiara, anziche' un complesso sistema di chiavi , iniziare direttamente con lo scambiarsi le chiavi pubbliche e poi crittare da subito a chiave simmetrica. Niente di che. Anche gli algoritmi come AES furono indeboliti molto rispetto alla loro stesura, e quindi pac: anche qui siamo al punto di partenza, ovvero si sospetta che NSA abbia voluto gestire le cose in modo da poter rompere il traffico criptato.

Qualcuno allora immagina che si tratti di tecniche matematiche sofisticatissime, o di chissa' quali tecniche di analisi crittografica. Ma non ce n'e' alcun bisogno. Prendiamo il caso piu' classico, quello che vi terrifica di piu': il governo americano puo' decodificare una crittazione di un sito "sicuro" senza che lo sappiamo? Ha tecniche matematiche per farlo?

LA risposta ovvia e': perche', servono tecniche matematiche per farlo?


Cosi', rispondo alla prima tra le domande dei lettori: ma il "lucchettino sicuro" e' davvero sicuro? No, non direi.

Guardiamo qui:

 

Se andate tra le opzioni del vostro browser, voi avete tutta una lista di autorita' di certificazione che sono quelle che vi servono per "far chiudere" il lucchetto del vostro browser, quello di cui vi fidate quando siete su un sito "sicuro". Queste "autorita' di certificazione", che appunto certificano che il sito web sia proprio lui (e non un impostore che si e' messo di mezzo tra voi ed il sito) sono tutto cio' che impedisce a qualcuno di mettersi di mezzo , tra voi e chiunque altro che sia un "sito sicuro". L'idea era che cosi' facendo qualcuno di cui vi fidate avrebbe "garantito" per l'identita' dei siti web. Bello.

Il guaio e', pero', che NESSUNO DI NOI ha idea di chi diavolo siano questi signori. Supponete che questi signori siano una estensione del governo, o che permettano al governo di produrre certificati. Mi voglio mettere tra voi e il vostro sito web "gmail.com". Non devo fare altro che deviare il vostro traffico su un mio proxy, che poi lo gira a gmail.com.  Come fate voi a sapere che parlate proprio con gmail.com e non con qualcuno in mezzo? Lo sapete perche' si chiude il lucchettino, ovvero perche' il vostro browser riceve un certificato che ritiene valido.

Quindi, se UNA SOLA di queste autorita' di certificazione , su richiesta di un governo, produce un certificato VALIDO per gmail.com, che viene installato sul proxy che si trova in mezzo, non siete piu' sicuri che gmail.com sia gmail.com.

E' stato necessario usare un qualsiasi sofisticato cluster HPC per fare crittanalisi? No. E' stato sufficiente che una qualsiasi di queste autorita' di certificazione , inserita nella lista di Firefox, IE, Chrome, fornisca al governo un certificato valido per il dominio gmail.com , ed ecco che un attacco "man in the middle" non costa praticamente nessuno sforzo crittografico, visto che e' sufficiente manipolare le rotte: http://www.cs.princeton.edu/courses/archive/fall08/cos561/slides/19Goldberg.pdf

Enunciamo dunque il problema: il piu' diffuso sistema di crittazione usato su internet dall'utente finale, HTTPS-2-Browser, si basa su una assunzione debole , che consiste nell'avere fiducia in centinaia di autorita' di certificazione di cui l'utente non sa nulla. Chi diavolo e' "Thawte?". Esiste una ragione per cui vi fidate di loro piuttosto che del vostro kebabbaro di fiducia?  I browser arrivano con una lista enorme ed INVERIFICABILE di autorita' di certificazione, ognuna delle quali "merita fiducia" quanto il primo sconosciuto che incontrate per la strada quando siete in vacanza all'estero.

Soluzioni possibili? Soluzione globale: azione governativa. Si crea una autorita' di certificazione governativa, o europea, e si vieta per legge di  inserire qualsiasi altra CA nei browser preinstallati. Risultato? Chi non ha la CA del governo deve accettare MANUALMENTE l'identita' di un sito che usa una chiave non governativa. Per questo, viene reso edotto del rischio. Messaggio per le aziende: procuratevi una chiave governativa o morite.

Del resto, il certificato e' come una carta di identita'. Come fate a sapere che la carta di identita' dice il vero? Perche' la  fa un governo, presso il quale (almeno le forze dell'ordine) possono controllarne la veridicita' usando il numero di serie. E produrre documenti falsi e' un reato. Adesso ditemi che crimine commetterebbe una CA inserita nell'elenco se producesse un certificato valido per gmail.com ovviamente non richiesto da google. Risposta: nessuno.

Morale: rompere qualsiasi quantita' di comunicazioni https e' semplice quanto un attacco main in the middle su TCP, a patto di ottenere la cooperazione di una qualsiasi autorita' di certificazione tra quelle preinstallate nel vostro browser. Non e' richiesta alcuna abilita' crittografica.

Il punto debole e' che vi lasciate installare sul browser una lista di autorita' di certificazione che considerate valide, senza per questo conoscerne NEANCHE UNA. Qualsiasi tra queste autorita' potrebbe essere un altro nome di NSA, un'azienda di copertura, e voi non lo sapete.

Volete sapere quanto sia invasivo il problema? Bene: andate sulla configurazione del vostro browser e poi rimuovete TUTTE le autorita' di certificazione. Dopodiche' girate per internet e fate le cose di sempre. E ad ogni segnalazione del browser riguardo al certificato self-signed, pensate che per quanto ne sapete, potrebbe esserci PRISM a spiarvi. OOPS. Imbarazzante, vero?

Esiste una soluzione locale? Si. Se volete mettere in sicurezza la VOSTRA rete interna, paradossalmente i certificati self-signed sono PIU' sicuri di quelli "issued by the big CA". Createvi una CA aziendale, mettete SOLO QUELLA nel browser, client-email, VPN client, etc, e a quel punto dentro la vostra azienda accettate come valida SOLO la vostra CA. Scomodo? Si. Sicuro? Piu' di accettare una certificazione da qualcuno che nessuno ha certificato. Chi certifica il certificatore?

Molti mi hanno scritto dicendo "ma se uso una vpn , di questo e quel provider di VPN, sono al sicuro?". Mah. Ho fatto alcune prove sniffando il processo di handshake di queste vpn da 5 dollari, e devo dire una cosa: iniziano tutte con gli stessi valori. Un individuo che voglia mettere il SUO server VPN di fronte a voi e giocarvi un tiro MIM non ha molti problemi nel farlo nel 90% dei casi.

Ma come dovreste fare, voi, a sapere per certo che dall'altro capo ci sia il vostro provider di VPN? La risposta e'  "il certificato". Aha. E chi certifica il certificato? Siamo al punto di sopra. Allora enunciamo un altro problema in maniera generale.


Quasi tutti i problemi di sicurezza su internet si riassumono, in estrema sintesi, nella difficolta' di risalire all'identita' certa dell'altro capo della comunicazione. Quando qualcuno ottiene diritti di root nel vostro sistema, potremmo riscrivere il problema dicendo che il sistema non riesce a distinguere tra l'identita' di root e quella dell'attaccante. Allo stesso modo, possiamo riassumere i problemi di privacy di cui ci occupiamo dicendo che non avete modo di sapere con certezza chi ci sia dall'altro capo. Se poteste saperlo con certezza, potreste concordare un qualsiasi codice e cifrare a piacimento. Il guaio e' che quando iniziate una connessione cifrata, concordando un codice, non sapete CON CHI lo state concordando, ed il risultato e' che tutta la vostra sicurezza decade se non riuscite a certificare l'identita' della vostra controparte.

La robustezza degli algoritmi e' nota, il vero guaio e' che stabilire una connessione criptata con un ente e' inutile, se non siete sicuri al 100% di parlare proprio con quello e non con un impostore che poi "gira" il traffico a destinazione, fingendosi voi.

La difficolta' nell'intercettare comunicazioni digitali NON e' insita nella difficolta' di rompere il codice, perche' il problema si puo' ridurre ad un problema piu' semplice, ovvero di certificazione dell'identita'. NON ESISTE alcun algoritmo di cifratura sicuro per una trasmissione, se non riuscite ad avere la certezza che state iniziando la sessione criptata con l'endpoint che avevate in mente.

Attaccare un algoritmo di cifratura puo' essere complesso a piacere, mentre e' molto piu' semplice in termini computazionali, per un governo, procurarsi un certificato valido e farvi credere di essere l'endpoint della vostra comunicazione.

Andiamo allora ad una stesura piu' ampia del vostro problema della privacy. Possiamo dire che ognuno dei vostri problemi di privacy si esprime con una specie di "stack" della sicurezza:

  1. Problema di identita': In che modo posso sapere che dall'altro capo della mia comunicazione ci sia colui che sto chiamando, e non un individuo che si finge la mia controparte?
  2. Problema di crittazione: DOPO essere certo che dall'altro lato ci sia chi credo, come essere sicuro che un curioso non capisca quello che ci diciamo se mi ascolta?
La cosa che viene POCO compresa e' che se viene meno il layer sottostante, il layer 2 NON VI AIUTA.

Stabilire una connessione criptata con qualcuno che finge di essere il vostro provider VPN non vi fornisce una certezza di privacy. MA per saperlo non vi serve a nulla la "forza" delle vostre chiavi o del loro modulo: solo una certificazione della controparte puo' aiutarvi. SOLO DOPO aver avuto la certezza di parlare con chi credete , potete fidarvi della crittazione. Cifratura senza identificazione non serve a NULLA nei confronti del problema che state approcciando.

Quello che NSA sta dicendo non e' che sono in grado di rompere tutte le cifrature. Non e' vero. Quello che vi stanno dicendo e' che possono sostituirsi facilmente alla vostra controparte.

Adesso andiamo all'ultimo punto, quello delle backdoor. Una backdoor e' un pezzo di codice, o un chip, che permette ad un attaccante di entrare nella vostra macchina e farci quel che vuole. Insomma, voi inviate una lettera crittografata. Viene consegnata da una divisione di Speznaz sorvegliata dall'alto da un satellite. Arriva a casa vostra. La aprite. La leggete ad alta voce. E c'e' un microfono nella stanza che vi ascolta.

Morale: il problema dell'identita' si complica. Non solo deve essere possibile stabilire che dall'altra parte ci sia DAVVERO colui che pensate, ma deve essere possibile stabilire che ci sia SOLO chi pensate. Se qualcuno, solo perche' puo' entrare nel server che usate per la VPN, e' in grado di leggere il traffico dopo che esso e' stato decrittato, la vostra VPN non serve a nulla. Insomma, la vostra sicurezza non dipende sempre e solo dalla cifratura che passa TRA due punti e dal fatto di essere certi dell'identita' dell'altro punto, ma dal fatto che la vostra controparte sia a sua volta inviolabile.

Andiamo allora ad una stesura ANCORA piu' ampia del vostro problema della privacy. Possiamo dire che ognuno dei vostri problemi di privacy si esprime con una specie di "stack" della sicurezza:

  1. Problema di integrita': In che modo posso sapere che l'altro capo della mia comunicazione non sia , parzialmente o completamente, sotto il controllo di altri diversi da chi deve ricevere la comunicazione?
  2. Problema di identita': In che modo posso sapere che dall'altro capo della mia comunicazione ci sia colui che sto chiamando, e non un individuo che si finge la mia controparte?
  3. Problema di crittazione: DOPO essere certo che dall'altro lato ci sia chi credo, come essere sicuro che un curioso non capisca quello che ci diciamo se mi ascolta?

Il nostro stack si complica. Perche' alla fine dei conti la crittazione, su cui affidiamo tante speranze, e' solo IN CIMA alla pila. In pratica la crittazione e' il tetto di un palazzo che sotto ha un piano chiamato "identita"', e come fondamenta l'integrita' del sistema destinatario.  Focalizzarsi sul tetto e' inutile, se non avete prima fondamenta solide e se il primo piano e' pericolante.

Quindi, direi una cosa: levatevi dalla testa storie fantascientifiche su supercomputer che attaccano brute-force con tecniche quantistiche tutto il traffico criptato del mondo. Levatevi dalla testa che i 52 miliardi di dollari di CIA siano serviti a costruire enormi cluster per attaccare la vostra crittografia. Quei 52 miliardi sono finiti invece in corruzione.

Pagando il vostro endpoint viene meno la sua integrita': "se mi dai accesso ai tuoi sistemi ti regalo 200 milioni di dollari". Semplice ed efficace.
Pagando una autorita' di certificazione viene meno l'identita': "se mi fai un certificato valido per il tale sito ti do' un milione di dollari".

Lo stesso Snowden ha detto quello che sto dicendo estensivamente , ovvero che "la cifratura aiuta moltissimo, ma la difesa dell'endpoint e' cosi' fragile che gli sforzi fatti sono facilmente vanificati".

Quindi, riesco a vedere diverse cose plausibilissime nei dati appena usciti:

  1. Il potere di calcolo necessario a rompere le cifrature cui si accenna non e' un potere di calcolo brute force, ma un potere di calcolo che serve a decrittare , possedendo le chiavi e i moduli (per via di meccanismi di scambio delle chiavi abbastanza deboli) , il traffico in tempo reale.
  2. La capacita' invasiva di NSA consiste probabilmente "solo" nella possibilita' di procurarsi certificati che vengono visti come validi dai principali sistemi di crittazione, magari in cooperazione con qualche CA, magari creata ad hoc come attivita' di copertura e inserita tra quelle "trusted" di ogni software. Questo sarebbe un esempio di "backdoor" nel vostro browser.
  3. La capacita' invasiva di NSA consiste nell'avere accesso, palese o meno, ai sistemi informativi dei grandi provider, dei fornitori di servizi e degli "over the top".

Qual'e' la soluzione ai problemi?

Se vogliamo immaginare una soluzione RADICALE, diciamo di un governo che voglia DAVVERO dire basta, la soluzione e':

  1. Implementare un proprio protocollo di rete, non interoperabile con TCP/IP,  o resuscitarne uno tra quelli esistenti in passato.
  2. Dotarlo di crittazione e di un sistema di certificati , legati ad una autorita' centrale gestita dallo stato. Vietare ogni altra CA.
  3. Implementare un proprio sistema operativo nazionale, e imporre quello, insieme ad uno stack di software.
  4. Prendere il controllo delle infrastrutture di rete, carrier ed accesso, e produrre in casa i dispositivi necessari (router, switch, etc)
  5. Piazzare una serie di gateway sul bordo, in modo da consentire agli utenti l'accesso ad Internet, ma non il contrario.
  6. Piazzare una serie di proxy sul bordo, che permettano ad internet di vedere alcuni siti web.
  7. Bloccare tutto il traffico da e per UK e USA, se non pochissimi siti, e di certo non tollerare cose come Facebook, Gmail , twittere co.
  8. Procedere allo stesso modo col mondo della telefonia.
Possiamo chiamarlo "metodo cinese", se vogliamo,  anche se i cinesi non sono ancora arrivati cosi' avanti. Come si paga una cosa cosi' mastodontica? Semplice: in termini di maggior competitivita' industriale.

Perche' da questo momento in poi qualcuno potrebbe chiedersi se gli americani siano davvero cosi' bravi col business, o se stiano solo rubando idee a tutto il mondo, e viene da chiedersi se la Cina non sia capace di sfidarli principalmente per via del controllo che il governo esercita sulla rete, e sul fatto che in Cina non ci siano Gmail, google, facebook &co, ma servizi locali protetti dalla "muraglia elettronica cinese".

E viene da chiedersi se , costruendo la "muraglia elettronica europea", non si potrebbe avere un qualche simile vantaggio.


Uriel

Viewing all articles
Browse latest Browse all 561

Trending Articles