Alla faccia della sorveglianza diffusa in Internet, abbiamo bisogno di un mezzo
pratico e sicuro per parlare a vicenda dai nostri telefoni e computer.
Molte aziende offrono prodotti “secure messaging” — ma in realtà, sono sicuri questi sistemi?
Questa che segue e’ parte di una campagna dell’ EFF per una crittografia Sicura & Utilizzabile.
I risultati della tabella sottostante non devono essere letti come approvazioni dei singoli strumenti
o garanzie della loro sicurezza; indicano solo che i progetti sono sulla pista giusta.
In fondo alla Tabella/scorecard i criteri usati per le valutazioni di sicurezza dei vari strumenti di comunicazione
.
METODOLOGIA
1. La tua comunicazione è crittata quando e’ in transito?
Questo criterio richiede che tutte le comunicazioni dell’utente siano crittate lungo tutti i collegamenti/link del percorso della comunicazione. Si noti che noi non si richiede la crittazione dei dati che vengono trasmessi su una rete aziendale, oddio sarebbe l’ideale. Non si richiede che i metadati (ad esempio nomi utente o indirizzi) siano crittati.
2. La tua comunicazione e’ crittata con una chiave a cui il provider non può accedere?
Questo criterio richiede che tutte le comunicazioni dell’utente vengono crittate end-to-end/da estremità a estremità. Questo significa che le chiavi necessarie per decrittare i messaggi devono essere generate e memorizzate dagli endpoint (cioè dagli utenti, non dai server). Le chiavi non dovrebbero mai lasciare gli endpoint tranne per azione esplicita dell’utente, es. eseguire il backup di una chiave o sincronizzare le chiavi tra due dispositivi. Va bene se le chiavi pubbliche degli utenti sono scambiate usando un server centralizzato.
3. Puoi verificare in modo indipendente l’identità del tuo corrispondente?
Questo criterio richiede l’esistenza di un metodo incorporato per agli utenti per poter verificare l’identità dei corrispondenti con cui stanno parlando e l’integrità del canale, anche se il fornitore del servizio o altre terze parti sono compromessi. Due soluzioni accettabili sono:
⁕Un’interfaccia per gli utenti in modo da visualizzare la fingerprint/l’impronta digitale (hash) delle chiavi pubbliche del loro corrispondente cosi’ per le loro , gli utenti possono verificarle manualmente o out-of-band/ su canali dedicati.
⁕Un protocollo di scambio di chiavi con short-authentication-string SAS come il protocollo Socialist Millionaire.
Altre soluzioni sono possibili, ma qualsiasi soluzione deve verificare un vincolo/associazione tra utenti e il canale crittografico che è stato istituito. Per la scorecard/tabella si chiede semplicemente che un meccanismo sia attuato e non tanto valutare l’usabilità e la sicurezza di tale meccanismo.
4. Le comunicazioni prededenti sono sicure se vi vengono rubate le chiavi?
Questo criterio richiede che l’app assicuri l’uso di forward secrecy FS; vale a dire, tutte le comunicazioni devono essere crittate con chiavi effimere che regolarmente vengono eliminate (insieme ai valori casuali utilizzati per ricavarle). È imperativo che queste chiavi dopo il fatto non possano essere ricostruite da nessuno, garantendo che, se gli utenti scelgano di eliminare le copie locali di corrispondenza (memorizzate sul disco rigido), siano eliminate definitivamente. Si noti che questo criterio richiede il criterio 2, crittografia end-to-end/da estremità a estremità. 1
5. il codice è aperto per una revisione indipendente?
Questo criterio richiede che sia stato reso pubblico codice-sorgente sufficiente da rendere possibile un’implementazione compatibile che possa essere compilata in modo indipendente. Anche se è preferibile, non si richiede che il codice sia rilasciato con una licenza specificatamente free/open source_. Abbiamo solo bisogno che tutto il codice che poteva influenzare la comunicazione e la crittografia eseguita dal cliente sia disponibile per la revisione al fine di rilevare *_bug* , back doors /porte di servizio/sul retro e problemi strutturali 2
6. il design della crittazione è ben documentato?
Questo criterio richiede spiegazioni chiare e dettagliate della crittografia utilizzata dall’applicazione. Preferibilmente si dovrebbe assumere la forma di un white paper/libro bianco scritto per la revisione da un pubblico di crittografi professionisti.. Deve fornire risposte alle seguenti domande:
⁕Quale algoritmi e parametri (ad esempio le dimensioni delle chiavi o gruppi di curve ellittiche) vengono utilizzati in ogni fase del processo di crittografia e autenticazione
⁕Come sono generate le chiavi , archiviate e scambiate tra gli utenti
⁕Il ciclo di vita delle chiavi e il processo per gli utenti per modificare o revocare la loro chiave
⁕Una chiara dichiarazione delle proprietà e protezioni che il software/programma mira a fornire (in modo implicito, questo tende a fornire anche un modello di rischio, sarebbe bene avere anche un modello per la minaccia esplicita). Ciò dovrebbe anche includere una chiara dichiarazione di scenari in cui il protocollo non è sicuro.
7. C’è stato una revisione della sicurezza indipendente?
Questo criterio richiede che una revisione indipendente della sicurezza sia stata effettuata 12 mesi prima della valutazione. Questo esame deve coprire sia la progettazione e l’implementazione dell’applicazione e deve essere eseguito da qualcuno nominato per la revisione che sia indipendente dal team di sviluppatori principale dello strumento. Sono sufficienti controlli effettuati da un team di sicurezza indipendente all’interno di un’organizzazione di grandi dimensioni. Riconoscendo che revisioni inedite possono essere preziose, non si richiede che i risultati della revisione siano stati resi pubblici, solo che chi sia nominato sia disposto a verificare che la revisione sia stata fatta.
1 Per questa tabella si accettano un approccio ibrido di forward secrecy a livello di trasporto (ad es. attraverso TLS con una suite di crittografia Diffie-Hellman_) e non-_forward-secret end-to-end encryption,, oltre a una garanzia esplicita che testi cifrati non sono registrati dal provider. Si tratta di un compromesso, che richiede la fiducia che il provider non registri testi cifrati, ma preferiamo questa configurazione ad non avere del tutto forward secrecy.
2 quando gli strumenti vengono forniti da un venditore di sistemi operativi, ai fini della scorecard/tabella si richiede solo il codice dello strumento e non l’intero sistema operativo. Si tratta di un compromesso, ma il compito di proteggere i sistemi operativi e loro aggiornamenti esula dall’ambito di questa tabella.
.
Tratto da: www.eff.org
