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
On 13/05/2015 09:39, Andrea Ranaldi wrote:
Non so se puó essere utile ma provo a descrivere grossolanamente un
programmino che mi hanno fatto buttare giù al volo e la soluzione che
ho operato.
Titolo: Un portale web, gli utenti devono poter mandare delle
comunicazioni con degli allegati ad un comitato, monitorare gli accessi
ai messaggi e soprattutro io amministratore non voglio e non devo poter
conoscere il contenuto di messaggi ed allegati.
Svolgimento: ad ogni membro del comitato ho creato una chiave rsa, la
privata protetta da password. Quando arriva una comunicazione memorizzo
sul database soltanto il cheksum del testo, id e data. In un'altra
tabella creo un messaggio per ogni membro del comitato con il testo
crittato da una chiave AES casuale e critto la chiave con la chiave
pubblica del membro destinatario, identica cosa per gli allegati. Ad
ogni accesso al messaggio il membro inserisce il token d'accesso alla
chiave privata, il token d'accesso non viene mai memorizzato. Io non
conosco il token quindi non posso decrittare la chiave aes quindi non
posso conoscere il mesaggio.
E venne il cane che morse il gatto che si mangió il topo....
Debolezze: ho la chiave ssl del webserver, tcpdump su 443 e leggo il
post del token..... ma sarebbe un auto attacco con i diritti di
root.... difficile da impedire :) log esterni per monitorare gli
operazioni dell'amministratore ed è passata la paura.
Ovviamente questa é una soluzione economica e casalinga, dipende dal
grado effettivo di sicurezza di cui necessiti, da me é stata accettata.
Appena avró tempo studieró un modo 'buono ed indolore' per delegare la
decrittazione al client.
Il mio temino da due cent
Andrea
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
*Andrea Zwirner*
*email*: [email protected]
*mobile*: +39 366 1872016
Linkspirit Via Luigi Moretti 2 - 33100 Udine UD
*tel:* +39 0432 1845030 - *fax:* +39 0432 309903
*web:* www.linkspirit.it - *email:* [email protected]
Logo Please consider your environmental responsibility before printing
this email.
