Benvenuti, a chi già conosce Caliopen, così come a chi lo scopre con questa prima edizione italiana del nostro notiziario (quasi) mensile!
In questo numero, oltre agli aggiornamenti del progetto, daremo una spiegazione dell’approccio scelto da Caliopen per la cifratura, della posta elettronica in particolare. Ma prima, una breve presentazione di Caliopen per chi ancora non lo conoscesse.
Rielaborando il modello dei password manager, Caliopen è il progetto del primo communication manager, un programma che offre un’interfaccia unificata per diversi strumenti di corrispondenza privata (e-mail, chat, SMS, messaggi privati di Twitter, Facebook, Linkedin e simili), capace di mettere in sinergia questi diversi canali e di guidare l’utente, tramite un percorso pedagogico e ludio, verso standard di sicurezza delle comunicazioni più elevati.
In attesa della prossima traduzione del nostro sito in italiano, ecco quindi, in sintesi, il progetto di Caliopen.
Pronti con le ultime notizie del progetto? Via!
Novità
- Alcuni lo sanno forse già: il nostro prossimo traguardo è una versione alfa, pubblica, a fine Maggio. Ultimamente, tuttavia, i nostri programmatori sono stati particolarmente impegnati con gli altri progetti di cui sono responsabili e quindi, per quanto riguarda Marzo, i progressi sono stati ridotti. Nella prospettiva della versione alfa, per rendere più agevole contribuire al progetto, si impone una completa riorganizzazione del codice: è in corso e sarà presto conclusa.
- Bloccati su certi fronti, avanziamo su altri: abbiamo incontrato Manzalab per valutare con loro delle ipotesi relative alla ludificazione del percorso degli utenti per accrescere il loro indice privacy. Al tema abbiamo anche dedicato un pad pubblico (aperto alle idee di tutti!).
- Un altro incontro utile è stato quello con gli autori di PEPS, per cercare di trovare delle sinergie tra i nostri progetti, comunque piuttosto diversi. È stata l’occasione per iniziare a riflettere sulla possibilità di integrare l’indice privacy in altri sistemi di posta.
- Caliopen è un progetto nato in Francia e sino ad ora relativamente poco conosciuto all’estero. Per questo siamo particolarmente contenti della prima conferenza Caliopen che ha avuto luogo in Italia, al BGLUG: grazie per l’ospitalità!
- La prossima conferenza è prevista il 24 Aprile, a Brest. Siamo però interessati a presentare Caliopen al più ampio numero di persone possibile! Se vuoi organizzare una presentazione, vuoi consigliarci una conferenza una alla quale candidarci, non esitare: scrivici!
Il caso delle chiavi
Sin dal primo giorno di Caliopen, una domanda ci viene posta regolarmente, relativamente alle soluzioni di cifratura che adotteremo per garantire la confidenzialità della corrispondenza.
Rispondere non è facile, innanzi tutto per via della natura stessa di Caliopen e le sue scelte fondamentali:
- Non esiste IL metodo di cifratura di Caliopen perché -per principio- l’utente avrà la possibilità di scegliere tra non cifrare nulla, cifrare i messaggi in uscita o cifrare tutti i messaggi conservati… Si tratta di scelte che in un uso quotidiano comportano limitazioni diverse, e che giocheranno nel calcolo dell’indice privacy, ma che non saranno per nulla imposte. Caliopen offrirà delle soluzioni integrate di cifratura dei dati, fa chiaramente parte del suo DNA, ma non obbligherà a nulla.
- D’altra parte noi non crediamo che nessuno possa garantire la confidenzialità degli scambi. Anche nell’ambiente meglio protetto, nessuno è al sicuro da un microfono, una penna USB usata in propria assenza, un attacco mirato, o un banale errore.
L’ambizione di Caliopen è di complicare la sorveglianza di massa, al punto da renderla troppo cara perché possa essere anche solo presa in considerazione. L’obiettivo non è di proteggere Tizio o Caio (anche se, chiaramente, questa sarà nei fatti la nostra procedura) ma di proteggere meglio la totalità degli utenti.
Senza queste premesse, è difficile capire Caliopen. Siamo abituati a ragionare in termini binari (“le mie comunicazioni sono cifrate, quindi sono protetto” contro “non cifro le mie comunicazioni e quindi la NSA sa tutto di me”) mentre il nostro progetto è incardinato sulla progressività (“io ed i miei contatti siamo abbastanza protetti, ma posso ancora migliorare la situazione”).
Certo, non possiamo accontentarci di questa spiegazione senza indicare, nonostante tutto, le scelte tecniche che abbiamo fatto in materia di cifratura. Ed in particolare sulla gestione delle chiavi.
Sin dall’inizio abbiamo deciso che Caliopen non avrebbe rinchiuso gli utenti nel suo ecosistema: le nostre scelte sono conservatrici e compatibili con l’insieme dei sistemi di posta esistenti, in accordo con il buon vecchio principio di Postel («tollerante in quello che ricevi, esigente in quello che invii»). Sarà uguale per quello che riguarda la cifratura: per restare aperti al mondo, gli utenti che lo desideranno potranno usare PGP per firmare o cifrare i loro messaggi.
PGP offre un vantaggio enorme: è totalmente decentralizzato. Contrariamente a S/MIME, non si appoggia su alcuna autorità centrale incaricata di diffondere le chiavi pubbliche.
Ma PGP presenta un inconveniente enorme: proprio perché totalmente decentralizzato, è difficile conoscere la chiave pubblica che ti permettera di cifrare il messaggio destinato ad un nuovo contatto, ed è altrettanto difficile mettere a disposizione dei proprio contatti la chiave che permetterà loro di cifrare i messaggi che vi vogliono inviare. Un server di chiavi? Certo, il protocollo SKS è stato un gran progresso, ma resta ancora molto instabile in un ambito quotidiano. E, dato che centralizza la gestione delle chiavi, rappresenta una vulnerabilità che rende più fragile il sistema di PGP. Per gli utenti di Caliopen che vorranno creare la propria chiave di cifratura, dovevamo proporre un’altra soluzione.
[expand title=”«Il caso delle chiavi» Articolo di Werner Koch tradotto dal tedesco.” swaptitle=”Il caso delle chiavi (Il testo è in tedesco, perché risponde ad un articolo pubblicato sulla rivista tedesca C’T)”]
Nella rivista C’T 6/2015 del 21 Febbraio, Jürgen Schmidt firma un editoriale nel quale sia augura « Lasciamo morire PGP ». Considera che PGP (e lo standard OpenPGP) siano un «dinosauro zoppo» e superato. Per dimostrarlo, confronta PGP ai servizi in linea di Apple, ed allo strumento di messaggi istantanei Textsecure.
Senza parlare del fatto che, come ogni società americana, le due in esempio possono essere costrette ad integrare delle falle nei loro programmi, è come confrontare dei treni e dei sottomarini. Sono di metallo e trasportano delle cose, sì, ma questo è tutto quello che hanno in comune.
Eppure, nel suo articolo «Il caso delle chiavi», pagina 160, è questo l’angolo che usa per descrivere i suoi problemi.
Confrontare dei protocolli in linea (come TextSecure) con dei protocolli offline (OpenPGP o S/MIME) non è, però, un approccio molto onesto. Una riunione, che abbia luogo in una sala o con una videoconferenza, non impone le stesse limitazioni che uno scambio di comunicazioni epistolare. Molti problemi sono più facili da risolvere in uno scambio simultaneo che non in una discussione asincrona.
Eppure la posta, le e-mail ed i resoconti scritti non sono ancora inutili, anzi; è solo grazie a questi strumenti di corrispondenza offline che le informazioni possono essere conservate in maniera confidenziale e restare a disposizione per essere utilizzate in seguito.
E noi abbiamo bisogno di protocolli offline, che funzionano anche quando non c’è rete. Tra l’altro la rete «Sneakernet» è spesso meno cara (più banda passante, cf. Backups) e più sicura di una connessione in linea. Quelli che hanno visto Citizenfour si ricorderanno di come Snowden differenzi il suo portatile in rete e quello non connesso («air-gapped»). Ebbene, l’e-mail è per sua natura uno strumento offline.
OpenPGP, contrariamente a S/MIME (l’altro protocollo di cifratura offline), è decentralizzato, cosa che presenta enormi vantaggi: si può utilizzarlo ovunque, e non necessita un’autorità di certificazione, così come una riunione non ha bisogno di essere preventivamente confermata da un ufficio matricola (il corrispettivo IRL di un’autorità di certificazione). Desiderare che il server delle chiavi richieda un’e-mail di conferma prima di consentire di inviare la propria chiave significherebbe perdere completamente di vista l’architettura decentralizzata di OpenPGP, dal momento che creerebbe un sistema centralizzato.
Certo, in un sistema centralizzato si può controllare l’identità del soggetto. Ma è impossibile nell’ambito di servizi replicati e decentralizzati, che sono intenzionalmente privi di un controllo centrale.
Quanto ai problemi incontrati da Jürgen Schmidt, alcuni messaggi indecifrabili, potrebbero molto facilmente essere limitati pubblicando le sue coordinate tra le menzioni legali del sito del giornale C’T. Oltre al suo indirizzo di posta, basterebbe aggiungere almeno l’ID della sua chiave, o un indirizzo direttamente.
Non evoca neppure i problemi equivalenti con S/MIME, nonostante sia (parrebbe) l’altro protocollo più diffuso per la cifratura della posta. È tanto più sorprendente dal momento che C’T, da diversi anni a questa parte, pubblicizza S/MIME come soluzione di cifratura semplice da utilizzare.
Ma allora come trovare una chiave quando non è stata allegata ad una prima e-mail? Le supposte garanzie di credibilità delle autorità di certificazioni sono ridicole. Con il loro aiuto qualunque organizzazione di spionaggio -statale o privata che sia- può ottenere qualunque certificato per qualunque inidirizzo. Non sono delle chiavi palesemente false come quelle sui server di chiavi, ma facilitano decisamente la vita della NSA, del GCHQ e del BND.
Usare l’interfaccia di un server web per dimostrare che si possono fornire delle chiavi “false” è un metodo insensato, perché il server di chiavi non può (o vuole) usare dei controlli crittografici. Questo, l’autore dell’articolo, lo dovrebbe sapere, tanto più che mi aveva rivolto la domanda qualche giorno prima. L’uso di OpenPGP avrebbe rapidamente sottolineato che si tratta proprio di chiavi “false”, dato che nessuna sarebbe stata importata, né inserita nella lista del portachiavi.
È vero, si può fornire qualunque chiave. L’esempio più frequente è quello di “president@whitehouse.gov“, con circa 27 chiavi. Ovviamente non è una novità, ed anzi, è qualcosa che ti insegnano in ogni cryptoparty. È del resto la ragione per cui, in certi giornali o su dei biglietti da visita viene indicato ugualmente un’impronta della chiave. Gli utenti più esperti fanno addirittura firmare le loro chiavi in delle “Keysigning Parties” (benché si tratti più di un gioco di società che di una soluzione realmente utile per il pubblico più vasto).
Piuttosto che demolire d’un colpo i server di chiavi ed OpenPGP, sarebbe ben più efficace chiedere ai servizi di posta elettronica di agire: gli indirizzi e-mail sono gestiti tramite il DNS in maniera unica, e quindi si potrebbe -e si dovrebbe- usare anche il DNS per ottenere una chiave.
Certo, si può sempre falsificare il DNS, dato che non è veramente sicuro, ma se non altro ci sarebbe una chiave per ogni indirizzo di posta. Esistono delle RFC a questo proposito da diversi anni, e GnuPG ha implementato questo sistema dal 2006 (vedi http://www.guug.de/veranstaltungen/ffg2006/abstracts.html#4_2_2 ). A questo proposito, nel 2012, con il mio collega Marcus Brinkmann, ho lanciato un progetto chiamato STEED (voir http://g10code.com/steed.html ), riguardo al quale C’T ha pubblicato un articolo, “Fiducia a prima vista”, grossomodo esatto (voir http://www.heise.de/artikel-archiv/ct/2012/20/190_Vertrauen-auf-den-ersten-Blick).
Purtroppo i FAI non vogliono parteciparvi e preferiscono raccontarci le loro storie sulla sicurezza, idiozie come l’e-mail “made in Germany” o proponendo come un riferimento valido il servizio con backdoor integrata che è De-Mail.
(vedi http://www.ccc.de/en/updates/2013/stellungnahmedemail)
[/expand]
Come Werner Koch (del quale abbiamo tradotto la recente risposta ad una critica su PGP), abbiamo scelto di usare il DNS.
- Perché ogni utente di Caliopen ha un identificante unico (utente@dominio) che può, se lo desidera, servire da indirizzo e-mail, ed il DNS permette quindi di trovare facilmente la sua chiave pubblica: basta interrogare il server del nome di domini (ad esempio ‘dig @ns.brainstorm.fr -t cert laurent.brainstorm.fr’ restituirà la chiave PGP di “laurent@brainstorm.fr”). Inutile cercare un server SKS in funzione, inutile passare per un intermediario.
- Perché, da questo punto di vista, il DNS è un sistema decentralizzato: al di fuori degli amministratori della zona, a maggior ragione se questa è gestita con DNSSEC, è estremamente difficile per un terzo modificarla ed inserirvi delle chiavi false.
- Perché le chiavi che vi sono custodite in questo modo sono facili da revocare (che rappresenta, altrimenti, uno dei maggiori difetti di PGP).
Vi sono altre ragioni, ma traducendo l’intervento di Werner Koch, abbiamo scoperto che il progetto STEED, dello stesso Werner Koch, le riassume impeccabilmente in questo documento.
Ancora una volta, non si tratta di costringere in alcun modo l’utente di Caliopen: se questo preferisce altri metodi per diffondere la sua chiave pubblica, più che libero. L’algoritmo di Caliopen attribuirà più o meno punti nel calcolo dell’indice privacy a seconda della tecnica scelta, più o meno sicura, tutte le possibilità saranno però percorribili, ovviamente.
Vi sono altri aspetti della cifratura scelta da Caliopen (generazione delle chiavi, conservazione della chiave privata ed uso su terminali multipli) che saranno trattati in articoli a venire.
Contatti
Speriamo di potere tornare presto a darvi notizie sull’avanzamento dei lavori di Caliopen; nel frattempo, tuttavia, non vi mancano gli strumenti per contattarci:
- IRC, su irc.freenode.org, chan #caliopen oppure, più precisamente nelle questioni di sviluppo del programma #caliopdev
- Twitter, dove ci trovate come @caliopen_org
- Per posta elettronica siamo contact@caliopen.org
- Github: se non avete bisogno di fare domande, non esistate, il codice è tutto in linea, aspettiamo le vostre PR! Caliopen su Github
Questo articolo è disponibile anche in francese ed in inglese.