Fino ad ora si è scritto e discusso delle regole di SPID e di come queste siano deboli per garantire, dal punto di vista dei processi, un adeguato meccanismo per identificare l’utente ovvero consentono un “facile” furto di identità.
Si è anche discusso che in caso di furto di identità non vi sia chiarezza su come rimborsare il danno o colpire in modo efficace il criminale o l’inadeguatezza dell’identity provider.
Si è anche discusso di come sia impossibile per un cittadino poter tenere sotto controllo le identità digitali che potrebbero essere attivate a suo carico e tutto quanto ne consegue.
Non si è ancora entrato nella parte tecnica che invece è di eguale importanza e in questo articolo proveremo a farlo.
Per la natura dell’articolo, che vuole essere divulgativo, non si entrerà nel merito della vasta letteratura scientifica che nel corso degli anni ha esaminato e documentato problemi di sicurezza nei protocolli utilizzati da SPID (SAML e SSL/TLS).
Dal punto di vista tecnico il documento delle Regole Tecniche di AGID prevede l’uso di SAML e di un canale sicuro SSL/TLS all’ultima versione. SAML è uno standard universalmente adottato per effettuare Single Sign ON, ovvero sistemi che prevedono l’autenticazione degli utenti tramite web attraverso dei soggetti che si occupano di verificare l’identità e poi abilitano all’utilizzo di servizi presso altri soggetti. SSL/TLS è un sistema che consente di rendere “sicura” una comunicazione tra un browser e un web server ed è la modalità più diffusa per le transazioni commerciali).
L’idea di fondo è che l’utente non debba ricordare una password per ogni sito e che possa delegare ad un sistema unico tale autenticazione per poi poter accedere ai diversi servizi senza ulteriore autenticazione.
Le indicazioni di sicurezza emesse nelle regole tecniche di AGID si limitano a richiedere, come accennato prima, che il canale di comunicazione tra utente e Service Provider sia basato su SSL/TLS e che venga utilizzato SAML con tutte le indicazioni del caso (par. 1.2.2.3).
Cercheremo di prendere in considerazione alcuni esempi semplici, potrebbero essere presentati altri attacchi ma è fuori dallo scopo di questo articolo. Gli attacchi che presentiamo sono noti in letteratura, il che significa che sono accaduti. Non faremo una rassegna esaustiva rimandando alla vasta letteratura sull’argomento. Cercheremo di far uso di un linguaggio poco tecnico per favorire la lettura anche di un pubblico non esperto.
Anzitutto il primo attacco che può essere tentato è quello di “iniettare” del codice malevolo presso l’identity Provider in modo che quando gli utenti chiedono di accedere inserendo user e password il codice lo invia ad un sito dove gli hacker possono raccogliere questi dati. Questo tipo di attacco non funziona se il sito è controllato e sottoposto a misure di sicurezza solide e se l’utente deve identificarsi con un meccanismo “a due fasi” (ad esempio tramite conferma via sms) o tramite token.
Tuttavia le specifiche SPID prevedono che il livello base di identificazione sia fatto tramite user e password per alcuni servizi (ad esempio il controllo delle multe da pagare o altri servizi). Tali servizi possono apparire di basso impatto ma se sono fatti attacchi su personalità molto note possono creare notevoli danni economici al personaggio. AGID non ha emanato raccomandazioni su come realizzare “finestre di input” in modo sicuro e su come provarne la sicurezza.
Uno dei principali problemi riscontrato in SAML, ad esempio, è il fatto che il protocollo fa delle asserzioni e una volta che sono verificate non ripete il controllo (per un tempo più o meno lungo). Queste informazioni di sicurezza vengono custodite dal browser che le utilizza negli accessi al Service Provider. Purtroppo sono spesso riscontrati buchi di sicurezza dei browser che possono consentire a codice malevolo di accedere a questi dati e poi cominciare a fare richieste in modo invisibile all’utente. Il protocollo non tiene traccia di informazioni aggiuntive che consentono di capire da dove arriva la richiesta e se è ancora valida. Nelle regole tecniche non è indicato ad esempio il tempo massimo per il quale una asserzione deve essere valida, dunque una volta riconosciuto l‘utente in teoria non perde mai validità, con potenziali enormi problemi in caso di furto.
Sarebbe tutto più sicuro se gli utenti utilizzassero versioni di browser aggiornate all’ultima versione, che spesso contiene tutte le misure di sicurezza per rispondere agli attacchi noti, ma spesso gli utenti non aggiornano il software e continuano ad utilizzare software con versioni superate compromettendo la sicurezza. In caso di furto di identità e richiesta danni gli identity provider potrebbero appellarsi proprio a questa mancanza per vincere cause contro gli utenti.
Il protocollo SAML utilizza una cifratura che identifica il token che chiede accesso ai servizi. E’ stato dimostrato che è possibile manomettere questo token, malgrado la cifratura, e utilizzarlo per chiedere accesso all’insaputa degli utenti.
Tra i problemi riscontrati in letteratura, c’è perfino un certo numero di implementazioni di SAML che facevano uso di parti di codice derivante da esempi diffusi su internet. Tali esempi semplificavano la vita dei programmatori nel comprendere l’uso del protocollo, tuttavia avevano una scarsa attenzione alla sicurezza. Molte delle implementazioni commerciali SAML sono state trovate vulnerabili a diversi attacchi derivante da questo codice.
In generale il protocollo SAML presenta cinque rischi principali suddivisi in un elenco di circa 13 tipologie di attacco[1], anche rafforzando il protocollo con una comunicazione “sicura” TLS/SSL (come prescritto da AGID) rimangono rischi non indifferenti. Esistono tuttavia in letteratura delle contromisure che consentono di ridurre i rischi, è un lavoro costante e continuo che mira ad individuare errori e a prevenirli. Alcune tipologie di attacco prevedono anche il furto di identità attraverso la manomissione del protocollo.
Il protocollo SSL/TLS è il sistema di comunicazione sicura che consente a tutti di connettersi con un sito in modo sicuro. Nel febbraio 2015 è stata pubblicata un documento (RFC7457) che riassume le principali principali tipologie di attacco al protocollo (ne conta circa 14). Nel documento, ad esempio, viene rilevato come molte implementazioni effettuate dai nostri client di posta elettronica e browser consentono di utilizzare “certificati” invalidi inviati da provider rendendo insicuro il protocollo.
Affermare dunque che basta usare il protocollo non è sufficiente, è necessario che vengano disposte precise indicazioni su come deve essere utilizzato SAML e SSL/TLS al fine di ottenere implementazioni il più sicure possibile. Sarebbe più semplice se si utilizzassero questi sistemi in una rete privata dove tutti gli utenti sono riconosciuti e tutti i software sono aggiornati alla medesima versione di software e subiscono il medesimo monitoraggio ma questo non è possibile su internet.
E’ noto che nulla può essere considerato sicuro, tuttavia è possibile adottare contromisure che rendano l’attacco più oneroso e difficile. Esistono delle banche dati di possibili attacchi e contromisure che sono tenute aggiornate, queste rilevano continui problemi ai due protocolli utilizzati per realizzare SPID.
Come si può capire, anche se non si è esperti di sicurezza informatica, ci troviamo di fronte ad un enorme potenziale problema di sicurezza che andrebbe affrontato in modo puntuale. Le linee guida dell’AGID presentano carenze su quali contromisure adottare per proteggere tutto il sistema SPID da possibili attacchi. Delegano agli Identity Provider tale funzione ma questo crea un’area grigia nella quale si può annidare la deresponsabilizzazione dei soggetti coinvolti.
E’ vero che il protocollo SAML e SSL/TLS sono adottati da Google e dai principali vendor che offrono soluzioni Single Sign On ma è vero che molte implementazioni sono state “rafforzate” proprio per fare in modo di adottare le necessarie contromisure. Soprattutto è da considerare che un conto è perdere una mail importante o una transazione, altro conto è permettere di poter avere un passe-partout che apre tutte le informazioni sensibili o meno di un cittadino senza che il cittadino possa disporre di strumenti adeguati per controllare cosa avviene o impedirlo.
Infine un ulteriore attacco a cui sono sensibili i due protocolli utilizzati (SMAL e TLS/SSL) è il “Denial of Service”, questo attacco consente ad un criminale informatico di poter mettere in atto una iniziativa volta a rendere impossibile l’operatività del servizio.
Questa tipologia di attacco è particolarmente problematica nel caso di SPID perché potrebbe bloccare tutti i servizi digitali dello Stato bloccando l’erogazione via internet. SPID non può essere paragonato ad un semplice servizio commerciale perché, per la natura di servizio che offre, rappresenta una infrastruttura critica nazionale e necessita di tutte le misure di sicurezza necessarie a proteggerlo sia da criminali informatici sia da stati esteri che vogliano raccogliere informazioni di intelligence o creare danni al nostro.
Sarebbe stato tutto più semplice se vi fosse stato un solo Identity Provider dove concentrare tutte le attenzioni di sicurezza o apportare alcune modifiche al protocollo per crearne una implementazione più sicura per la PA e i sistemi governativi, la norma istitutiva di SPID si affida ad un sistema articolato.
Ora è necessario riflettere su cosa si può fare per migliorare la sicurezza. E’ necessario che AGID si faccia carico di raccogliere le raccomandazioni di sicurezza relative ai due protocolli e di emanare periodici bollettini con le specifiche a cui gli Identity Provider devono attenersi come misura minima.
A mio avviso è anche necessario costituire un gruppo di lavoro che si occupi di emanare periodici aggiornamenti e raccomandazioni su come deve essere realizzata la implementazione di SPID in modo che essa sia sicura, tale gruppo di lavoro deve vedere coinvolti gli esperti tecnici di sicurezza degli Identity Provider, ricercatori e consulenti esperti in modo da raccogliere le informazioni presenti a livello internazionale e produrre specifiche molto stringenti su come deve essere realizzato il servizio SPID e sulle misure di sicurezza da adottare.
E’ evidente che la costituzione di questo gruppo di lavoro comporta dei costi aggiuntivi a carico di AGID e degli Identity Provider perché non è pensabile che un tale lavoro possa essere fatto gratuitamente dai soggetti coinvolti e richiede costi incrementali per attuare le contromisure. Questo va però in contraddizione con la norma costitutiva di SPID che non prevedeva oneri per lo Stato. E’ anche necessario sensibilizzare i cittadini italiani a mantenere i propri software aggiornati, tanto più se si vogliono utilizzare servizi online della PA o bancari. Sarebbe anche auspicabile che determinati servizi verificassero le versioni di browser che chiedono i servizi e obbligassero ad un aggiornamento in modo da favorire questo cambio culturale degli utenti.
Bibliografia minima per approfondimenti
Sul tema sicurezza SSL/TLS
https://int21.de/slides/auscert-tls/#/
Sul tema sicurezza SAML
Andreas Mayer, Vladislav Mladenov, and Jo ̈rg Schwenk, “On the Security of Holder-of-Key Single Sign-On”,2014
Kirandeep Kaur , Divya Bansal, “Security Vulnerabilities in SAML based Single Sign- On Authentication in Cloud”, 2013
Vinayendra Nataraja “Is SAML An Effective Framework For Secure SSO? ”, 2012
Juraj Somorovsky, Andreas Mayer, Jo ̈rg Schwenk, Marco Kampmann, Meiko Jensen, “On Breaking SAML: Be Whoever You Want to Be” , 2012
Alessandro Armando, Roberto Carbone, Luca Compagna, Jorge Cue ́llar, Giancarlo Pellegrino, and Alessandro Sorniotti. “From Multiple Credentials to Browser-Based Single Sign-On: Are We More Secure?” In Jan Camenisch, Simone Fischer-Hu ̈bner, Yuko Murayama, Armand Portmann, and Carlos Rieder, editors, SEC, volume 354 of IFIP Advances in Information and Communication Technology, pages 68–79. Springer, 2011
[1] “Is SAML An Effective Framework For Secure SSO? ”, Vinayendra Nataraja, 2012
