Nell'ultima lezione del corso abbiamo detto che in tutte le applicazioni pratiche della crittografia a chiave pubblica l'associazione tra Subject e KPUB è descritta da dei certificati.
La nozione di certificato è molto semplice in prima approssimazione ("la verità dell'associazione è garantita da una terza parte meritevole di fiducia; questa terza parte è la certification authority che ha generato il certificato") ma, come sappiamo, molto complicata nei dettagli.
I certificati servono per fare in modo che il castello di garanzie offerte dalla crittografia non sia sostenuto dall'ipotesi "per ogni Subject, l'associazione Subject-KPUB è reale" ma sia invece sostenuto dall'ipotesi "per ogni certification authority CA-X, l'associazione CA-X-KPUB è reale e CA-X genera affermazioni vere".
Si tratta in entrambi i casi di ipotesi, cioè di atti di fede: affermazioni che si considerano vere a priori. Se l'ipotesi è vera allora il castello di garanzie sta in piedi, se l'ipotesi non è vera allora il castello può stare in piedi o meno.
La cosa fondamentale da notare è che l'uso dei certificati e l'esistenza delle certification authority non significa che le ipotesi sono automaticamente e necessariamente vere nella pratica. Possono essere vere ma possono anche non esserlo. Dipende.
Seguono alcuni aneddoti interessanti da questo punto di vista (estratti da http://www.diigo.com/user/bartolialberto/ssl):
Nel 2011, un hacker è riuscito a falsificare certificati della CA Comodo (presente in molte TrustList e KeyList, ad esempio in Windows). E' riuscito a generare associazioni fasulle per Subject molto importanti quali "www.google.com, login.yahoo.com, login.skype.com, addons.mozilla.com, and Microsoft's login.live.com." (http://www.theregister.co.uk/2011/03/23/gmail_microsoft_web_credential_forgeries/)
Nel 2008, varie CA importanti e rispettabili hanno generato erroneamente certificati per Subject mooooolto importanti:
In 2008, he applied for an SSL certificate that would allow him to pose as the rightful operator of Microsoft's Live.com domain, which is used to logon to Hotmail and other sensitive online services. In about two hours, VeriSign subsidiary Thawte issued the credential with almost no questions asked. Zusman's sole qualification was his control of the email address sslcertificates@live.com, which was enough to convince the automated processes at Thawte that he was authorized to own the certificate.
In December of that same year, a Comodo reseller issued a similar no-questions-asked certificate for Mozilla.com to a separate researcher who had no affiliation with the open-source software outfit.
(estratto da http://www.theregister.co.uk/2011/04/11/state_of_ssl_analysis/)
Non entriamo nel dettaglio degli errori software, che sono il vero grosso problema pratico per la sicurezza, in quanto gli aneddoti sarebbero in quantità quasi infinita...(solo uno: http://www.theregister.co.uk/2009/10/05/fraudulent_paypay_certificate_published/)
AGGIORNAMENTO: "The certificate signing trust model under stress as an industrial security model"
La nozione di certificato è molto semplice in prima approssimazione ("la verità dell'associazione è garantita da una terza parte meritevole di fiducia; questa terza parte è la certification authority che ha generato il certificato") ma, come sappiamo, molto complicata nei dettagli.
I certificati servono per fare in modo che il castello di garanzie offerte dalla crittografia non sia sostenuto dall'ipotesi "per ogni Subject, l'associazione Subject-KPUB è reale" ma sia invece sostenuto dall'ipotesi "per ogni certification authority CA-X, l'associazione CA-X-KPUB è reale e CA-X genera affermazioni vere".
Si tratta in entrambi i casi di ipotesi, cioè di atti di fede: affermazioni che si considerano vere a priori. Se l'ipotesi è vera allora il castello di garanzie sta in piedi, se l'ipotesi non è vera allora il castello può stare in piedi o meno.
La cosa fondamentale da notare è che l'uso dei certificati e l'esistenza delle certification authority non significa che le ipotesi sono automaticamente e necessariamente vere nella pratica. Possono essere vere ma possono anche non esserlo. Dipende.
Seguono alcuni aneddoti interessanti da questo punto di vista (estratti da http://www.diigo.com/user/bartolialberto/ssl):
Nel 2011, un hacker è riuscito a falsificare certificati della CA Comodo (presente in molte TrustList e KeyList, ad esempio in Windows). E' riuscito a generare associazioni fasulle per Subject molto importanti quali "www.google.com, login.yahoo.com, login.skype.com, addons.mozilla.com, and Microsoft's login.live.com." (http://www.theregister.co.uk/2011/03/23/gmail_microsoft_web_credential_forgeries/)
Nel 2008, varie CA importanti e rispettabili hanno generato erroneamente certificati per Subject mooooolto importanti:
In 2008, he applied for an SSL certificate that would allow him to pose as the rightful operator of Microsoft's Live.com domain, which is used to logon to Hotmail and other sensitive online services. In about two hours, VeriSign subsidiary Thawte issued the credential with almost no questions asked. Zusman's sole qualification was his control of the email address sslcertificates@live.com, which was enough to convince the automated processes at Thawte that he was authorized to own the certificate.
In December of that same year, a Comodo reseller issued a similar no-questions-asked certificate for Mozilla.com to a separate researcher who had no affiliation with the open-source software outfit.
(estratto da http://www.theregister.co.uk/2011/04/11/state_of_ssl_analysis/)
Nel 2010, i Mac e Firefox contenevano un elemento in TrustList (lista di CA fidate) ed in KeyList (lista di associazioni CA-KPUB) che nessuno sapeva a chi corrispondesse. Il legittimo proprietario (RSA, una delle società più grandi e rinomate) non si era neanche accorta che fosse suo e se n'è accorta dopo vari giorni.
Non entriamo nel dettaglio degli errori software, che sono il vero grosso problema pratico per la sicurezza, in quanto gli aneddoti sarebbero in quantità quasi infinita...(solo uno: http://www.theregister.co.uk/2009/10/05/fraudulent_paypay_certificate_published/)
AGGIORNAMENTO: "The certificate signing trust model under stress as an industrial security model"
Commenti