Buongiorno Andrea Zwirner, Di pro la tua soluzione ha che si trovano librerie javascript gia` esistenti e ben collaudate oltre ovviamente all'evitare l'invio della token des per decrittare la chiave rsa privata. Ma ammetto che il far girare le chiavi private mi mette ansia :) Poi si genera il problema della moltiplicazione dei post: se devo inviare un messaggio con tre allegati ad un comitato di cinque persone dovrò eseguire un post per cinque con quindici allegati crittati, cinque testi e cinque chiavi. Il post farebbe molto presto a diventare oneroso in termini di invio con tutti i problemi derivanti....
Io inizialmente avevo pensato di utilizzare le api SubtleCrypto dei nuovi browser per far decrittare il messaggio direttamente dal browser ( vedi https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto ) L'idea era delegare la gestione delle chiavi al browser e memorizzare soltanto le chiavi pubbliche nel server, ma non ho trovato molta documentazione, sembra gestire soltanto RSA e sopratutto non ho trovato nessun riferimento a file; quindi ho lavorato lato server per coprire l'emergenza in attesa di avere un po di tempo di studio. Chi lo avrebbe detto a scuola che un giorno avrei desiderato del tempo libero per studiare :D Grazie per il consiglio, faro` qualche prova per vedere se riesco ad applicarlo. Andrea Ranaldi N.B. aggiungo i cognomi altrimenti sembra che mi parlo da solo On Wed, 13 May 2015 11:57:55 +0200 Andrea Zwirner <[email protected]> wrote: > Buongiorno Andrea, > > che ne dice di questa scaletta? > > * All'iscrizione al sito, per ogni entità (utenti, membri del > comitato, amministratori, etc) viene generata lato client una > coppia di chiavi, privata e pubblica. > * Entrambe vengono passate lato server e salvate a DB (la privata è > protetta da passphrase, che può o meno essere la password di > login, in base ai criteri di sicurezza decisi per password e > passphrase) > * Ad login il sito passa al lato client la sua privata protetta > * Ogni volta che un'entità deve inviare un messaggio ad una o più > entità, lo crittografa lato client con la/le chiave/i pubblica/che > del/dei destinatario/i, che l'applicazione lato server gli > fornisce a richiesta. > * L'invio del messaggio consiste nel passaggio dal client del > mittente al server del messaggio crittografato (e qualunque altro > metadato le possa essere utile, come ad esempio il/ destinatario/i, > timestamp, checksum del messaggio in chiaro, etc) > * Alla prima (o ad ogni, in base al livello di sicurezza che > desidera ottenere) necessità di decrittografare un messaggio ricevuto, > l'applicazione lato client richiede l'inserimento della > passphrase, estrae la chiave privata, decrittografa il messaggio e lo > mostra a video. > > Ovvio che lo spostamento dell'intelligenza lato client richiede un > bello sforzo a livello di progettazione e sviluppo, oltre a rendere > molto rischiose eventuali vulnerabilità lato client (in particolare > xss), ma in questo modo è implementata crittografia end-to-end e > direi che, a meno di brute force sulle passphrase delle chiavi > private - che comunque può evitare "salando" la chiave privata con > una ulteriore password lato client -, è preclusa la possibilità di > leggere alcunché ad alcun amministratore o malintenzionato che > dovesse prendere il controllo della macchina. > > Saluti, > > Andrea Zwirner ________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List
