Quanto è sicuro SPID?
Sono già stati utilizzati fiumi di inchiostro per raccontare SPID e molto si è detto di come non siano ben tratteggiate le regole per garantire che l’identificazione dell’utente non sia soggetta ad un “facile” furto di identità. Purtroppo ancora non sono chiarissime neanche le regole su come sarà rimborsato il danno in caso di furto di identità, come colpire in modo efficace il criminale, o l’eventuale inadeguatezza dell’identity provider.
Questi dubbi, in attesa di risposte concrete, restano, ora invece, senza entrare nei dettagli tecnologici, diamo uno sguardo molto veloce alle soluzioni tecniche adottate perché, anche su questo versante, si sono rilevate alcune criticità. Riporteremo anche qualche esempio di alcuni degli attacchi che hanno messo in evidenza alcune debolezze delle tecnologie scelte per SPID.
AGID, dal punto di vista tecnico prevede l’uso di Security Assertion Markup Language (SAML), e di un canale sicuro SSL/TLS all’ultima versione. SAML, lo ricordiamo, è uno standard adottato per effettuare Single Sign ON, ovvero sistemi che prevedono l’autenticazione degli utenti tramite web e attraverso soggetti che dopo aver verificato l’identità, abilitano all’utilizzo di servizi presso terzi. SSL/TLS, invece, è un sistema che consente di rendere “sicura” una comunicazione tra un browser e un web server ed è anche la modalità più diffusa per le transazioni commerciali.
Tali scelte discendono dalla volontà di dare all’utente una unica password e di poter ricorrere ad un unico sistema di autenticazione per accedere ai servizi.
Le indicazioni di sicurezza emesse nelle regole tecniche di AGID si limitano a richiedere che il canale di comunicazione tra utente e Service Provider sia basato su SSL/TLS e che venga utilizzato SAML.
Ma cosa accade se un hacker inserisce codice malevolo negli apparati dell’identity Provider? In questo caso si potrebbe verificare che gli utenti che chiedono di accedere, inserendo user e password, siano indirizzati ad un sito dove gli hacker possono raccogliere questi dati sensibili. Questo tipo di attacco può essere evitato solo se il sito è sotto controllo e sottoposto a misure di sicurezza solide e se all’utente è richiesta una identificazione con un meccanismo “a due fasi” ad esempio tramite conferma via sms o con un token.
AGID non ha emanato raccomandazioni su come realizzare “finestre di input” in modo sicuro e su come provarne la sicurezza. Le specifiche SPID prevedono le “2 fasi” solo per alcuni servizi, mentre per quelli ritenuti a basso impatto è previsto soltanto l’inserimento di user Id e password.
Anche lo standard SAML ha dato già qualche problema. Il protocollo, dopo aver fatto le asserzioni, una volta che sono state verificate, non ripete il controllo anche per un tempo piuttosto lungo. Ora, visto che queste informazioni di sicurezza sono custodite dal browser che le utilizza negli accessi al Service Provider, qualora ci fossero buchi di sicurezza dei browser, un codice malevolo potrebbe accedere ai dati e fare richieste in modo invisibile all’utente. Purtroppo Il protocollo non tiene traccia di informazioni aggiuntive che consentono di capire da dove arriva la richiesta e se è ancora valida. Nelle regole tecniche di SPID non è indicato, solo per fare un esempio, il tempo massimo per il quale una asserzione deve essere valida quindi, una volta riconosciuto l‘utente, in teoria non perde mai validità e questo, in caso di furto, potrebbe creare molti problemi.
Se gli utenti utilizzassero versioni di browser sempre aggiornate, il sistema sarebbe più sicuro, ma troppo spesso non viene aggiornato il software e, questa cattiva abitudine, in caso di furto di identità, potrebbe diventare una buona scappatoia per gli identity provider nelle vertenze e nelle richieste di danni.
Sempre sul protocollo SAML, esso utilizza una cifratura che identifica il token che chiede accesso ai servizi, ma purtroppo anche il token non è immune alle possibili manomissioni, malgrado la cifratura, e può essere utilizzato per chiedere accesso senza che gli utenti se ne accorgano.
Ricordiamo, poi, che un certo numero di implementazioni di SAML facevano uso di parti di codice prese da esempi diffusi su internet; questi esempi, se da un lato hanno facilitato i programmatori nella comprensione dell’uso del protocollo, non hanno curato con particolare attenzione la sicurezza e, infatti, molte implementazioni commerciali SAML sono state trovate vulnerabili a diversi attacchi.
In generale SAML presenta più di qualche problema in termini di sicurezza e, anche rafforzando il protocollo con una comunicazione “sicura” TLS/SSL, come prescritto da AGID, permangono alcuni rischi. Esistono contromisure, certo, ma è un lavoro costante che mira ad individuare errori e a prevenirli. Alcuni attacchi, in ogni caso, prevedono anche il furto di identità attraverso la manomissione del protocollo.
Passiamo ora al protocollo SSL/TLS. E’ il sistema di comunicazione che consente a tutti di connettersi con un sito in modo sicuro. Nel febbraio 2015, però, è stato pubblicato un documento (RFC7457) che riassume le principali tipologie di attacco al protocollo. Il documento rileva come molte implementazioni effettuate dai nostri client di posta elettronica e browser consentono di utilizzare “certificati” invalidi, inviati da provider, rendendo insicuro il protocollo.
Il protocollo, dunque, non è sufficiente, è invece necessario che siano disposte precise indicazioni su come devono essere utilizzati SAML e SSL/TLS.
Esistono banche dati che catalogano tutti i casi di possibili attacchi e delle contromisure da adottare, proprio queste banche dati rilevano continui problemi ai due protocolli utilizzati per realizzare SPID. Anche se nulla può essere considerato sicuro al 100%, è comunque sempre possibile adottare misure che rendano l’attacco più oneroso e difficile.
Purtroppo le linee guida dell’AGID presentano carenze e delegano agli Identity Provider la ricerca delle soluzioni più adeguate, ma questa scelta crea un’area grigia che potrebbe diventare utile a deresponsabilizzare i soggetti coinvolti.
Infine, e non perché meno importante, un ulteriore attacco ai due protocolli, SMAL e TLS/SSL, potrebbe derivare dal “Denial of Service” che consente ad un hacker di mettere in atto il blocco dell’operatività del servizio. Un attacco che, nel caso di SPID, potrebbe significare il blocco temporaneo dei servizi digitali dello Stato. Si potrebbe eccepire, dopo queste spiegazioni, che Il protocollo SAML e SSL/TLS sono adottati da Google e dai principali vendor che offrono soluzioni Single Sign On, ma un conto è perdere una mail importante o una transazione, tutt’altra cosa è violare un sistema e avere disponibili tutte le informazioni sensibili di un cittadino senza che il cittadino possa disporre di strumenti adeguati per controllare cosa avviene o impedirlo.
SPID non può essere paragonato ad un semplice servizio commerciale perché, per la natura del servizio che offre, rappresenta una infrastruttura critica nazionale e necessita di tutte le misure di sicurezza necessarie a proteggerlo, sia da criminali informatici che da stati esteri che vogliano raccogliere informazioni di intelligence o creare danni al nostro.
Alcuni sostengono che sarebbe stato più semplice accreditare un solo Identity Provider e concentrare tutte le attenzioni di sicurezza o apportare alcune modifiche al protocollo per crearne una implementazione più sicura e ad hoc per la PA e i sistemi governativi.
Poiché ad oggi gli Identity Provider sono tre e potrebbero anche aumentare, è necessario che AGID monitori la situazione ed emani bollettini periodici con le specifiche a cui gli Identity Provider devono attenersi per garantire la sicurezza dei dati che essi custodiscono.
Come già accennato, è veramente importante che i cittadini italiani, specialmente se utilizzano servizi online della PA, ma in generale se utilizzano il web, mantengano i propri software aggiornati.
Questi dubbi, in attesa di risposte concrete, restano, ora invece, senza entrare nei dettagli tecnologici, diamo uno sguardo molto veloce alle soluzioni tecniche adottate perché, anche su questo versante, si sono rilevate alcune criticità. Riporteremo anche qualche esempio di alcuni degli attacchi che hanno messo in evidenza alcune debolezze delle tecnologie scelte per SPID.
AGID, dal punto di vista tecnico prevede l’uso di Security Assertion Markup Language (SAML), e di un canale sicuro SSL/TLS all’ultima versione. SAML, lo ricordiamo, è uno standard adottato per effettuare Single Sign ON, ovvero sistemi che prevedono l’autenticazione degli utenti tramite web e attraverso soggetti che dopo aver verificato l’identità, abilitano all’utilizzo di servizi presso terzi. SSL/TLS, invece, è un sistema che consente di rendere “sicura” una comunicazione tra un browser e un web server ed è anche la modalità più diffusa per le transazioni commerciali.
Tali scelte discendono dalla volontà di dare all’utente una unica password e di poter ricorrere ad un unico sistema di autenticazione per accedere ai servizi.
Le indicazioni di sicurezza emesse nelle regole tecniche di AGID si limitano a richiedere che il canale di comunicazione tra utente e Service Provider sia basato su SSL/TLS e che venga utilizzato SAML.
Ma cosa accade se un hacker inserisce codice malevolo negli apparati dell’identity Provider? In questo caso si potrebbe verificare che gli utenti che chiedono di accedere, inserendo user e password, siano indirizzati ad un sito dove gli hacker possono raccogliere questi dati sensibili. Questo tipo di attacco può essere evitato solo se il sito è sotto controllo e sottoposto a misure di sicurezza solide e se all’utente è richiesta una identificazione con un meccanismo “a due fasi” ad esempio tramite conferma via sms o con un token.
AGID non ha emanato raccomandazioni su come realizzare “finestre di input” in modo sicuro e su come provarne la sicurezza. Le specifiche SPID prevedono le “2 fasi” solo per alcuni servizi, mentre per quelli ritenuti a basso impatto è previsto soltanto l’inserimento di user Id e password.
Anche lo standard SAML ha dato già qualche problema. Il protocollo, dopo aver fatto le asserzioni, una volta che sono state verificate, non ripete il controllo anche per un tempo piuttosto lungo. Ora, visto che queste informazioni di sicurezza sono custodite dal browser che le utilizza negli accessi al Service Provider, qualora ci fossero buchi di sicurezza dei browser, un codice malevolo potrebbe accedere ai dati e fare richieste in modo invisibile all’utente. Purtroppo Il protocollo non tiene traccia di informazioni aggiuntive che consentono di capire da dove arriva la richiesta e se è ancora valida. Nelle regole tecniche di SPID non è indicato, solo per fare un esempio, il tempo massimo per il quale una asserzione deve essere valida quindi, una volta riconosciuto l‘utente, in teoria non perde mai validità e questo, in caso di furto, potrebbe creare molti problemi.
Se gli utenti utilizzassero versioni di browser sempre aggiornate, il sistema sarebbe più sicuro, ma troppo spesso non viene aggiornato il software e, questa cattiva abitudine, in caso di furto di identità, potrebbe diventare una buona scappatoia per gli identity provider nelle vertenze e nelle richieste di danni.
Sempre sul protocollo SAML, esso utilizza una cifratura che identifica il token che chiede accesso ai servizi, ma purtroppo anche il token non è immune alle possibili manomissioni, malgrado la cifratura, e può essere utilizzato per chiedere accesso senza che gli utenti se ne accorgano.
Ricordiamo, poi, che un certo numero di implementazioni di SAML facevano uso di parti di codice prese da esempi diffusi su internet; questi esempi, se da un lato hanno facilitato i programmatori nella comprensione dell’uso del protocollo, non hanno curato con particolare attenzione la sicurezza e, infatti, molte implementazioni commerciali SAML sono state trovate vulnerabili a diversi attacchi.
In generale SAML presenta più di qualche problema in termini di sicurezza e, anche rafforzando il protocollo con una comunicazione “sicura” TLS/SSL, come prescritto da AGID, permangono alcuni rischi. Esistono contromisure, certo, ma è un lavoro costante che mira ad individuare errori e a prevenirli. Alcuni attacchi, in ogni caso, prevedono anche il furto di identità attraverso la manomissione del protocollo.
Passiamo ora al protocollo SSL/TLS. E’ il sistema di comunicazione che consente a tutti di connettersi con un sito in modo sicuro. Nel febbraio 2015, però, è stato pubblicato un documento (RFC7457) che riassume le principali tipologie di attacco al protocollo. Il documento rileva come molte implementazioni effettuate dai nostri client di posta elettronica e browser consentono di utilizzare “certificati” invalidi, inviati da provider, rendendo insicuro il protocollo.
Il protocollo, dunque, non è sufficiente, è invece necessario che siano disposte precise indicazioni su come devono essere utilizzati SAML e SSL/TLS.
Esistono banche dati che catalogano tutti i casi di possibili attacchi e delle contromisure da adottare, proprio queste banche dati rilevano continui problemi ai due protocolli utilizzati per realizzare SPID. Anche se nulla può essere considerato sicuro al 100%, è comunque sempre possibile adottare misure che rendano l’attacco più oneroso e difficile.
Purtroppo le linee guida dell’AGID presentano carenze e delegano agli Identity Provider la ricerca delle soluzioni più adeguate, ma questa scelta crea un’area grigia che potrebbe diventare utile a deresponsabilizzare i soggetti coinvolti.
Infine, e non perché meno importante, un ulteriore attacco ai due protocolli, SMAL e TLS/SSL, potrebbe derivare dal “Denial of Service” che consente ad un hacker di mettere in atto il blocco dell’operatività del servizio. Un attacco che, nel caso di SPID, potrebbe significare il blocco temporaneo dei servizi digitali dello Stato. Si potrebbe eccepire, dopo queste spiegazioni, che Il protocollo SAML e SSL/TLS sono adottati da Google e dai principali vendor che offrono soluzioni Single Sign On, ma un conto è perdere una mail importante o una transazione, tutt’altra cosa è violare un sistema e avere disponibili tutte le informazioni sensibili di un cittadino senza che il cittadino possa disporre di strumenti adeguati per controllare cosa avviene o impedirlo.
SPID non può essere paragonato ad un semplice servizio commerciale perché, per la natura del servizio che offre, rappresenta una infrastruttura critica nazionale e necessita di tutte le misure di sicurezza necessarie a proteggerlo, sia da criminali informatici che da stati esteri che vogliano raccogliere informazioni di intelligence o creare danni al nostro.
Alcuni sostengono che sarebbe stato più semplice accreditare un solo Identity Provider e concentrare tutte le attenzioni di sicurezza o apportare alcune modifiche al protocollo per crearne una implementazione più sicura e ad hoc per la PA e i sistemi governativi.
Poiché ad oggi gli Identity Provider sono tre e potrebbero anche aumentare, è necessario che AGID monitori la situazione ed emani bollettini periodici con le specifiche a cui gli Identity Provider devono attenersi per garantire la sicurezza dei dati che essi custodiscono.
Come già accennato, è veramente importante che i cittadini italiani, specialmente se utilizzano servizi online della PA, ma in generale se utilizzano il web, mantengano i propri software aggiornati.
