FORMALIZZAZIONE DEL PROTOCOLLO SAML SSO IMPLEMENTATO DA GOOGLE IN HLPSL

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "FORMALIZZAZIONE DEL PROTOCOLLO SAML SSO IMPLEMENTATO DA GOOGLE IN HLPSL"

Transcript

1 UNIVERSITÀ DEGLI STUDI DI UDINE Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea Specialistica in Informatica Progetto di Laboratorio Avanzato di Reti di Calcolatori e Sicurezza FORMALIZZAZIONE DEL PROTOCOLLO SAML SSO IMPLEMENTATO DA GOOGLE IN HLPSL Docente: Prof. MARINO MICULAN Studente: RICCARDO DI STASI (MAT ) ANNO ACCADEMICO

2

3 Indice 1 Introduzione 1 2 SAML SSO Il protocollo SAML SSO Implementazione Google di SAML ed il relativo attacco Formalizzazione di SAML in HLPSL Formalizzazione con chiavi simmetriche Formalizzazione con chiavi asimmetriche Risultati ottenuti con Avispa Risultati della versione a chiavi simmetriche Risultati della versione a chiavi asimmetriche L implementazione corretta di Google La nuova versione di SAML Conclusione 25 A Codice sorgente prodotto 27 A.1 Sorgente della versione errata a chiavi simmetriche A.2 Sorgente della versione errata a chiavi asimmetriche A.3 Sorgente della versione corretta a chiavi simmetriche A.4 Sorgente della versione corretta a chiavi asimmetriche B Output di Avispa 37 B.1 Output della versione errata a chiavi simmetriche B.1.1 Output di ofmc B.1.2 Output di satmc B.1.3 Output di cl-atse B.2 Output della versione errata a chiavi asimmetriche B.2.1 Output di ofmc iii

4 iv INDICE B.2.2 Output di satmc B.2.3 Output di cl-atse B.3 Output della versione corretta a chiavi simmetriche B.3.1 Output di ofmc B.3.2 Output di satmc B.3.3 Output di cl-atse B.4 Output della versione corretta a chiavi asimmetriche B.4.1 Output di ofmc B.4.2 Output di satmc B.4.3 Output di cl-atse Bibliografia 51

5 Capitolo 1 Introduzione Sempre più spesso, le aziende che forniscono servizi su Internet mettono a disposizione dei loro clienti collezioni di applicazioni, in modo da cercare di esaudire tutte le esigenze informatiche di quest ultimi. Con l aumentare delle funzionalità erogate da un singolo operatore, non è più pensabile gestire le autenticazioni in modo separato per ogni applicazione, in quanto ciò richiederebbe sia la memorizzazione di più coppie username-password per un singolo utente, sia che ogni persona si ricordi delle credenziali di accesso usate per ogni singolo servizio. Una soluzione a questo problema è quella offerta dall uso di SAML, un applicazione XML che permette di esprimere delle asserzioni di sicurezza. SAML mette a disposizione diverse funzionalità, tra cui quella detta single sign on, la quale permette ad un fornitore di servizi di mettere a disposizione degli utenti un insieme di applicazioni a cui si può accedere effettuando l autenticazione una sola volta. Anche Google ha adottato questa soluzione per Google Apps, solo che ha implementato una sua versione del protocollo di autenticazione, discostandosi dallo standard. Tale implementazione, però, è soggetta ad un attacco, descritto per la prima volta in [1], che permette ad un intruso di avere accesso a delle risorse confidenziali. Lo scopo del lavoro svolto è la formalizzazione del protocollo SAML di Google in HLPSL, un linguaggio nato per formalizzare protocolli di sicurezza, in modo da poter verificare se Avispa, un tool per l analisi della correttezza di protocolli Internet, è in grado di rilevare l attacco a cui è vulnerabile Google Apps. Nel primo capitolo si procede introducendo le principali caratteristiche di SAML, la variante del protocollo implementata da Google e l attacco a cui questa è soggetta. Nel secondo capitolo, invece, si prosegue con la descrizione della formalizzazione del protocollo in HLPSL effettuata. Il terzo capitolo illustra i risultati ottenuti dall analisi fatta da Avispa sulla formalizzazione fatta; Avispa dispone di quattro analizzatori, tuttavia è stato possibile testare 1

6 2 Introduzione il codice scritto solo con tre di questi. Il quarto capitolo contiene la descrizione della nuova versione del protocollo SAML adottata da Google dopo la scoperta dell esistenza dell attacco qui descritto; in questo capitolo si descrive anche la formalizzazione fatta del nuovo protocollo ed i risultati ottenuti con Avispa. Nel capitolo conclusivo si commenteranno i risultati ottenuti, mentre nelle due appendici, infine, sono riportati il codice sorgente scritto ed gli output prodotti da Avispa.

7 Capitolo 2 SAML SSO In questo capitolo verrà introdotto il funzionamento del protocollo SAML SSO, in particolare nella prima sezione si spiegherà il funzionamento della versione standard del protocollo, mentre nella restante parte del capitolo verranno introdotte le caratteristiche dell implementazione di Google e del relativo attacco. 2.1 Il protocollo SAML SSO SAML (acronimo per Security Assertion Markup Language) è un applicazione XML che permette lo scambio di messaggi autenticati e confidenziali tra due domini, in particolare tra un identity provider, colui che produce le asserzioni, ed un service provider, il destinatario di tali asserzioni. Questa applicazione è gestita da OASIS, che ne cura lo standard ufficiale e rilascia le nuove versioni ufficiali della stessa (per maggiori dettagli vedere [2]). SAML si basa su due concetti fondamentali, il binding e i profili; per binding si intende il modo in cui le asserzioni vengono mappate in messaggi di un protocollo di trasmissione od in un formato standard di messaggi. La versione attuale del linguaggio, la 2.0, supporta i bindings per i seguenti protocolli: SAML SOAP (basato su SOAP 1.1); Reverse SOAP (PAOS); HTTP Redirect (GET); HTTP POST; HTTP Artifact; SAML URI. 3

8 4 SAML SSO Un profilo, invece, è la descrizione dettagliata di come organizzare gli elementi SAML per ottenere una certa funzionalità; la versione 2.0 del linguaggio prevede i seguenti profili: profili SSO: Web Browser SSO; Enhanced Client or Proxy (ECP); Identity Provider Discovery; Single Logout; Name Identifier Management; Artifact Resolution; Assertion Query/Request; Name Identifier Mapping; SAML Attribute. In questo scritto ci si concentrerà sul profilo più usato, il single sign on, SSO in breve, in particolare nella variante web browser. I protocolli SSO sono nati con lo scopo di permettere ad un utente di autenticarsi in un ambiente contenente diversi servizi. In questo modo si semplifica la gestione delle credenziali di accesso, sia per gli erogatori di servizi, che dovranno memorizzare una sola coppia username-password per persona, sia per gli utenti, i quali dovranno autenticarsi una sola volta per fruire poi di più servizzi liberamente. Un esempio di applicazione di un protocollo SSO è quello di Google Apps, dove l utente, una volta autenticatosi, ha accesso a diversi servizi, quali Gmail, Google Calendar, Talk, Docs e Sites, potendo passare da un applicazione Google all altra, senza riautenticarsi. Il profilo SSO di SAML ed il protocollo (in questo contesto per protocollo si intende il modo in cui gli elementi SAML devono essere elaborati per raggiungere un certo scopo) authentication request forniscono proprio questa funzionalità. La figura 2.1 mostra come avviene una sessione del protocollo authentication request di SAML nella variante in cui l inizializzazione viene fatta dal fornitore di servizi (SP-Initiated SSO con Redirect/POST Bindings). Gli attori del protocollo sono tre, un client (C) che richiede una risorsa ad un service provider (SP) ed un identity provider (IDP) che ha il compito di autenticare C per SP.

9 2.1 Il protocollo SAML SSO 5 Figura 2.1: Una sessione SAML SSO

10 6 SAML SSO La sessione inizia con il client che effettua una richiesta di una risorsa al service provider, questi risponde con una richiesta di autenticazione che il client inoltra all identity provider; IDP ha il compito di autenticare C, ciò avviene attraverso l inserimento di uno username e di una password oppure in un qualsiasi altro modo. Una volta che l identity provider ha verificato l identità di C genera e firma una risposta, contenente l asserzione di autenticazione per C, che invia al client; questi inoltra il messaggio ricevuto al service provider, il quale in questo modo può essere sicuro dell identità di C e quindi procede con l invio delle risorse richieste al client. Il protocollo assume che sia IDP che SP siano autenticati per C, questo avviene attraverso lo scambio di certificati X.509 e l uso del protocollo SSL per garantire la sicurezza dei canali, in particolare: 1. le comunicazioni tra C ed SP avvengono attraverso un canale unilaterale SSL 3.0, cioè il service provider deve fornire il suo certificato al client; 2. le comunicazioni tra C ed IDP si effettuano attraverso un canale SSL che inizialmente è unilaterale, in quanto solo IDP fornisce il suo certificato a C, ma che poi diventa bilaterale quando C fornisce le sue credenziali di autenticazione all identity provider. Come ultima cosa va specificato che ciò che si vuole ottenere dopo la sessione della figura 2.1 è che SP autentichi C e che le risorse rimangano segrete tra questi due agenti. 2.2 Implementazione Google di SAML ed il relativo attacco L interpretazione di Google del protocollo SAML SSO, descritta in [1], appare diversa da quella riportata nella figura 2.1 per alcuni particolari che, se pur a prima vista possono sembrare irrilevanti, invece rendendolo il protocollo vulnerabile ad un attacco. La figura 2.2 mostra la variante Google del protocollo. Come si può evincere dall immagine vi sono due differenze con la sessione SAML descritta nella sezione precedente: la prima è che l authentication assertion non comprende più nè ID nè SP, la seconda è che la risposta generata da IDP non comprende più i campi ID ed IDP. Il fatto di non includere più SP nell authentication assertion, generata dall identity provider, è il fattore che rende il protocollo vulnerabile ad un attacco, il quale viene effettuato da un intruso che impersona un service provider malevolo. La figura 2.3 mostra lo schema dell attacco, scoperto molto recentemente

11 2.2 Implementazione Google di SAML ed il relativo attacco 7 Figura 2.2: Una sessione Google di SAML SSO

12 8 SAML SSO da Armando et al. (per maggiori dettagli vedere [1]); le frecce più grosse sono i messaggi inviati dall intruso. Figura 2.3: Attacco all implementazione SAML SSO di Google L attacco si ottiene combinando insieme due sessioni, la prima in cui l intruso gioca il ruolo di service provider e la seconda dove invece funge da client. Le azioni che l intruso deve intraprendere per eseguire l attacco sono le seguenti: 1. prima di tutto deve diventare un service provider fidato per un client, in modo da poter stabilire con lui un canale SSL; 2. appena riceve una richiesta da parte del client lo inoltra a Google cambiando l URI di partenza in uno relativo ad un servizio di Google Apps (ad esempio Gmail); 3. quando riceve da SP la richiesta di autenticazione, l intruso la inoltra al vero client, cambiando l ID con uno nuovo e inserendo l URI richiesto da C al posto di quello di Google Apps, in modo tale che questi possa procedere alla propria autenticazione attraverso l IDP; 4. ricevuta la risposta dal client, l attaccante la spedisce a Google avendo cura di cambiare I con Google e l URI originale con quello della risorsa che desidera ricevere; 5. a questo punto, come ultima cosa, l attacante deve aspettare che SP gli invii le risorse di Google Apps.

13 2.2 Implementazione Google di SAML ed il relativo attacco 9 Alla fine di questo scambio di messaggi l attacco è terminato e l intruso ha avuto accesso a delle risorse che dovevano restare segrete tra C e Google, ingannando quest ultimo sulla sua vera identità.

14 10 SAML SSO

15 Capitolo 3 Formalizzazione di SAML in HLPSL In questo capitolo verrà discussa la modellazione della versione SAML SSO implementata da Google in HLPSL (acronimo di high level protocol security language), linguaggio adottato da Avispa per analizzare la correttezza dei protocolli di sicurezza. Per maggiori informazioni su Avispa e sull uso del linguaggio HLPSL, si possono consultare [4] e [5], che forniscono tutte le nozioni fondamentali su questi temi. Il primo problema in cui si incorre volendo formalizzare in HLPSL SAML è quello della modellazione dei canali SSL, in quanto il linguaggio non fornisce questa tipologia di canale, ma rende disponibile solo il modello del canale Dolev-Yao, secondo il quale l intruso ha il pieno controllo di ciò che transita attraverso il canale di trasmissione, può alterare il contenuto dei messaggi, inviarne di nuovi e venire a conoscenza di ogni messaggio che attraversa il canale di trasmissione. Per risolvere questo problema, si è pensato a due soluzioni: la prima prevede la cifratura di tutti i messaggi attraverso delle chiavi simmetriche, il cui valore è noto soltanto a mittente e destinatario del messaggio, la seconda, invece, fa uso della crittografia a chiave pubblica, attraverso la quale ogni messaggio viene autenticato e reso confidenziale. Il codice delle due formalizzazioni si trova nelle prime due sezioni dell appendice A. 3.1 Formalizzazione con chiavi simmetriche In questa sezione si spiegheranno le caratteristiche principali della modellazione del protocollo SAML attraverso la cifratura a chiave simmetrica. Questa soluzione si basa sull uso di una chiave diversa per ogni coppia di interlocutori, in particolare vi è una chiave condivisa tra C ed SP ed una tra C e IDP. Va 11

16 12 Formalizzazione di SAML in HLPSL detto inoltre che anche l intruso dovrà disporre di una chiave per comunicare con SP, di una per interagire con C e di un altra chiave per comunicare con IDP (in realtà tale chiave risulta inutile al fine di trovare l attacco ma dovendo l intruso impersonare un client deve essere definita anche tale chiave). Figura 3.1: Schema di un protocollo in HLPSL Come mostrato nella figura 3.1, HLPSL prevede che i protocolli vengano specificati definendo dei ruoli semplici, uno per ogni agente che prende parte al protocollo, e dei ruoli composti che stabiliscono come avviene una sessione del protocollo preso in esame. Oltre a ciò vanno definiti gli obiettivi di sicurezza fissati per il protocollo e le conoscenze di base possedute dall intruso. Un ruolo semplice in HLPSL, il cui schema è mostrato nella figura 3.2, è composto da

17 3.1 Formalizzazione con chiavi simmetriche 13 tre parti: la prima è l intestazione del ruolo in cui si dichiarano i valori di input (ad esempio gli agenti del protocollo), la seconda è la dichiarazione delle variabili e delle costanti e la terza è composta dalle transizioni che devono essere attraversate durante l esecuzione di una sessione. Figura 3.2: Struttura di un ruolo semplice Si procede ora con la descrizione della modellazione dei tre ruoli di base. Il ruolo del client riceve in input i tre agenti (C, IDP, e SP), le chiavi simmetriche per comunicare con SP e IDP, la chiave pubblica di IDP, quattro canali di comunicazione (due per inviare e due per ricevere dati sia da SP che da IDP) e una funzione di hash che servirà a modellare le risorse. Le transizioni effettuate dal client sono le seguenti: 1. si inizia la sessione inviando ad SP un messaggio contenente il valore di C, di SP e l URI desiderato; 2. quando si riceve la richiesta di autenticazione da parte di SP la si inoltra ad IDP; 3. nel momento in cui si riceve la conferma di autenticazione da parte di IDP la si invia a SP; 4. quando si ricevono le risorse (modellate come una funzione hash dell URI) da SP si raggiunge lo stato finale. Come già detto in precedenza, si ricorda che ogni messaggio va cifrato con la relativa chiave simmetrica. Come ultima cosa, nella penultima transizione del ruolo, va specificata una asserzione di tipo witness in modo da indicare che quando si è giunti a questo punto della sessione il client dovrebbe essersi autenticato nei confronti di SP attraverso il valore di URI.

18 14 Formalizzazione di SAML in HLPSL Il ruolo del service provider riceve in ingresso i valori degli agenti SP e IDP, una chiave simmetrica che deve essere condivisa con il client, due canali di trasmissione (da e verso C), la chiave pubblica di IDP e la funzione per generare le risorse. Le transizioni sono le seguenti: 1. quando si riceve una richiesta di risorse da parte del client, si risponde con l invio di una richiesta di autenticazione; 2. se arriva una conferma di autenticazione firmata da IDP e proveniente dal client, si procede con l invio delle relative risorse precedentemente richieste da C. All ultima transizione vanno aggiunte due asserzioni di sicurezza, una di tipo request, per indicare che giunti a questo punto SP deve aver autenticato C attraverso il valore di URI, e l altra di tipo secret indicante che le risorse devono restare segrete tra C ed SP. Il ruolo dell identity provider riceve in ingresso i tre agenti del protocollo, una chiave simmetrica per comunicare con il client, la sua chiave pubblica ed una coppia di canali per comunicare con C. IDP ha solo una transizione da eseguire che si attiva quando l agente riceve una richiesta di autenticazione da parte del client; a tale richiesta, l identity provider risponde con un messaggio contenente: il nome del service provider che ha fatto richiesta di autenticazione; i valori di C ed IDP firmati con la sua chiave privata (KIDP); l URI per il quale era stata richiesta l autenticazione. Oltre ai tre ruoli appena descritti ve ne sono altri due composti. Il primo ruolo è chiamato session e riceve in ingresso i tre agenti, tutte le chiavi di cifratura previste dalla modellazione e la funzione di hash che modella le risorse; all interno di questo ruolo vengono creati tutti i canali di comunicazione previsti e vengono composti i tre ruoli semplici in modo da formare una sessione del protocollo SAML valida. Il secondo ruolo composto, chiamato enviroment non ha parametri di ingresso, al suo interno vengono dichiarati, sotto forma di costanti, i valori relativi ai tre agenti, alle chiavi di cifratura, alla funzione generatrice delle risorse e gli identificatori delle asserzioni di sicurezza. In questo ruolo vengono anche dichiarate le informazioni che l intruso dispone all inizio di una sessione, cioè i nomi dei tre agenti (c, sp, idp), le chiavi simmetriche che può usare (kci, kisp) e la chiave pubblica dell identity provider (kidp). Il ruolo compone insieme tre sessioni (cioè il ruolo session viene invocato per tre volte) una tra C e l intruso nel ruolo di service provider, una tra C ed SP e la terza tra l intruso, che impersona un client, ed SP.

19 3.2 Formalizzazione con chiavi asimmetriche 15 La modellazione termina con la dichiarazione dei due goals di sicurezza che il protocollo dovrebbe rispettare: il primo indica che le risorse dovrebbero restare segrete tra C ed SP (ciò corrisponde all uso di un asserzione di tipo secret presente del ruolo del service provider), il secondo che alla fine di una sessione del protocollo C dovrebbe essersi autenticato nei confronti di SP (per questo goals sono state dichiarate le altre due asserzioni di sicurezza presenti nel ruolo del client e in quello del service provider). 3.2 Formalizzazione con chiavi asimmetriche Questa modellazione risulta molto simile a quella precedentemente illustrata, in particolare la struttura risulta essere la stessa: la formalizzazione contiene tre ruoli semplici che modellano il comportamento dei relativi agenti, e due composti usati per simulare una sessione del protocollo; anche i goals di sicurezza risultano essere i medesimi. Rispetto alla variante a chiave simmetrica, il cambiamento più significativo è il modo in cui vengono modellati i canali SSL, in particolare, dove è richiesta la confidenzialità del canale, i dati vengono cifrati con la chiave pubblica del destinatario, mentre se è richiesta l autenticazione, i messaggi vengono firmati con la chiave privata del mittente. L organizzazione dei canali è la seguente: canale da C a SP: i dati sono cifrati con la chiave publica di SP e firmati con quella privata di C, che viene inviata a SP nel primo messaggio; canale da SP a C: i dati sono firmati da SP e cifrati con la chiave pubblica di C precedentemente inviata a SP (questo canale deve essere fortemente autenticato ma debolmente confidenziale); canale da C a IDP: i dati sono cifrati con la chiave pubblica di IDP, l autenticazione debole è data dall inserimento di username e password da parte di C ; canale da IDP a C: questo canale è fortemente confidenziale ed autenticato, quindi i dati sono firmati e cifrati. Ogni agente, e quindi anche l intruso, deve dunque possedere una chiave pubblica e una privata (in HLPSL la chiave privata viene ottenuta passando la relativa pubblica come argomento alla funzione inv()). L addozione della crittografia a chiave pubbblica ha comportato anche altre modifiche hai ruoli semplici, in particolare ora non ricevono più in input delle chiavi simmetriche, queste sono state sostituite con le relative chiavi pubbliche degli agenti che condividono lo stesso canale; per modellare il fatto che

20 16 Formalizzazione di SAML in HLPSL inizialmente C non è autenticato da SP, il client concatena la sua chiave pubblica al primo messaggio che invia al service provider, ciò viene fatto perchè se SP conoscesse già la chiave pubblica di C, allora il client sarebbe già stato autenticato dal service provider (attraverso l invio di un certificato X.509 ad esempio). I due ruoli composti vengono modificati sostituendo le chiavi simmetriche con quelle pubbliche e cambiando la conoscenza di base dell intruso il quale ora dispone di una coppia di chiavi asimmetriche; dalle conoscenze dell intruso viene esclusa la chiave pubblica di IDP, questo viene fatto perchè altrimenti c è il rischio che gli analizzatori trovino dei falsi attacchi, dovuti al fatto che l intruso possa fingersi IDP con C (ciò in realtà non può succedere con dei canali SSL reali).

21 Capitolo 4 Risultati ottenuti con Avispa In questo capitolo veranno presentati i risultati ottenuti analizzando con Avispa le due modellazioni del protocollo SAML introdotte nel capitolo precedente. Avispa dispone di quattro analizzatori back-end con cui poter testare i protocolli di sicurezza, in questo caso sono stati impiegati tre analizzatori, ofmc, satmc e cl-atse, in quanto il quarto (ta4sp) non era funzionante nell installazione di Avispa utilizzata. I risultati ottenuti sono riportati nelle prime due sezioni dell appendice B 4.1 Risultati della versione a chiavi simmetriche Facendo analizzare ad Avispa la formalizzazione di SAML che modella i canali di comunicazione attraverso le chiavi simmetriche si ottengono risultati diversi in base all analizzatore impiegato. Gli analizzatori trovano degli attacchi leggermente diversi da quello mostrato nella figura 2.3; l attacco precedentemente illustrato prevede l uso di due sessioni parallele, una in cui l intruso impersona un service provider malevolo e l altra in cui, invece, gioca il ruolo di client con il service provider reale. Come si può vedere nella figura 4.1, ofmc rileva un attacco al protocollo che fa uso di due sessioni sequenziali, la prima delle quali è una quasi regolare sessione SAML tra il client e l intruso nel ruolo di service provider, mentre la seconda vede l attaccante nel ruolo di client ed il service provider di Google nel suo ruolo naturale. Nella seconda sessione l intruso usa l authassert ottenuta nel primo scambio di messaggi con il client per ingannare il service provider ed ottenere le risorse al posto del client. L altra differenza rilevata è che i messaggi scambiati tra il client e l identity provider vengono intercettati dall intruso che li inoltra al giusto (passi 3, 4, 5, 6 della prima sessione), mentre nell attacco illustrato nel primo capitolo l attaccante non fa- 17

22 18 Risultati ottenuti con Avispa ceva uso di tali messaggi; tuttavia si tratta di una differenza di poco conto in quanto non modifica la tipologia di attacco rilevato ed in ogni caso l intruso non potrebbe modificare questi messaggi in quanto cifrati con una chiave a lui ignota. Figura 4.1: L attacco rilevato da ofmc L attacco trovato da satmc è simile a quello rilevato da ofmc, tranne per due particolari; il primo è che l uri richiesto dall attaccante è lo stesso desiderato dal client originale, il secondo è che le sessioni non sono più sequenziali, ma la seconda inizia prima che l intruso inoltri la richiesta di autenticazione all identity provider. L ultimo analizzatore usato, cl-atse, trova una variante dell attacco simile a quelle rilevate dagli altri due analizzatori, specialmente ofmc, ma con alcuni passaggi in più che risultano superflui al fine dell attacco, quindi non fornice la soluzione ottima. Questi passaggi in più che vengono forniti in output dall a-

23 4.2 Risultati della versione a chiavi asimmetriche 19 Figura 4.2: L attaco trovato da satmc nalizzatore formano una terza sessione del protocollo, in cui un secondo client fa una richiesta di risorse ad un nuovo service provider, il quale richiede l autenticazione del client ad un altro identity provider, diverso da quello coinvolto nell attacco; i messaggi scambiati tra queste tre entità sono filtrati dall intruso, il quale, tuttavia, non può modificarli in quanto ignaro delle chiavi di cifratura usate dagli agenti. La figura 4.3 mostra lo schema dell attacco appena descritto, dove C2, IDP2, SP2 sono gli agenti della terza sessione superflua. 4.2 Risultati della versione a chiavi asimmetriche I risultati ottenuti con la modellazione del protocollo SAML mediante chiavi assimmetriche sono un po diversi da quelli descritti nella precedente sezione. L unico risultato comune ad entrambe le formalizzazioni è quello fornito da ofmc, infatti, anche nel caso della modellazione qui presa in esame, l attacco rilevato è quello descritto nella figura 4.1. Un risultato completamente diverso è stato ottenuto usando come analizzatore satmc, il quale giudica erroneamente il protocollo safe. Questo è dovuto al fatto che il limite superiore dello spazio di ricerca viene raggiunto prima di

24 20 Risultati ottenuti con Avispa Figura 4.3: L attacco trovato da cl-atse nel caso simmetrico

25 4.2 Risultati della versione a chiavi asimmetriche 21 trovare l attacco. Cl-atse, invece, rileva una variante dell attacco non trovata in precedenza, in cui vi sono dei passi superflui e per tanto non risulta essere una soluzione ottimale. Il risultato ottenuto, mostrato nella figura 4.4, è formato da quattro sessioni SAML, di cui due appartenenti all attacco e altre due, inutili ed incomplete, fra un service provider e l intruso, e tra l intruso ed un client. La soluzione rilevata, presenta anche un ordine dei messaggi scambiati leggermente diverso da quello dell attacco descritto nel primo capitolo, in particolare l intruso inizia la sessione con il service provider mentre il client è ancora in attesa della risposta dell identity provider. Infine anche in questo caso i messaggi tra il client e l identity provider sono intercettati dall attaccante il quale provvede ad inoltrarli a destinazione. Figura 4.4: L attacco trovato da cl-atse nel caso asimmetrico

26 22 Risultati ottenuti con Avispa

27 Capitolo 5 L implementazione corretta di Google Dopo essere stata avvisata da Armando et al dell attacco riguardante la sua implementazione del protocollo SAML, Google ha prontamente corretto il problema di sicurezza introducendo una nuova versione del protocollo descritta in [3]. In questa sezione si discuterà della nuova soluzione e della sua formalizzazione in HLPSL il cui codice si trove nelle ultime due sezioni dell appendice A. 5.1 La nuova versione di SAML Come già fatto presente nel primo capitolo, la vulnerabilità dell implementazione Google di SAML sta nel fatto di aver ridotto il contenuto dell authassert ai soli valori di C ed IDP. Per risolvere il problema, Google ha modificato l authassert, includendo anche il valore di SP. La figura 5.1 illustra come la correzione apportata da Google impedisca l attacco precedentemente illustrato. Se l identity provider firma anche il nome del service provider che ha richiesto l autenticazione del client, il service provider ha modo di accorgersi che l authassert non è stata generata per lui e non procede con l invio delle risorse. L intruso, inoltre, non ha modo di manipolare la risposta generata dall identity provider in quanto questa è firmata con una chiave privata che non ha modo di reperire. Per verificare formalmente la correttezza della modifica apportata, sono state fatte due modellazioni della stessa in HLPSL. Le due modellazioni differiscono, ancora una volta, soltanto per il modo di modellare i canali SSL, pertanto le modifiche da apportare alle formalizzazioni già descritte in precedenza sono minime. Ciò che è stato fatto è cambiare le transizioni relative all invio, 23

28 24 L implementazione corretta di Google Figura 5.1: La nuova versione Google di SAML od alla ricezione, della risposta dell IDP, in modo che l authassert includesse anche il valore di SP. Se ad esempio la transizione del ruolo dell identity provider nella versione a chiavi simmetriche era 1.State=7 /\ RCV({C.IDP.(ID.SP).URI }_KCIDP) = > State :=9 /\ SND({SP.{(C.IDP)}_inv(KIDP).URI }_KCIDP), ora nella nuova versione diventa 1.State=7 /\ RCV({C.IDP.(ID.SP).URI }_KCIDP) = > State :=9 /\ SND({SP.{(C.IDP.SP)}_inv(KIDP).URI }_KCIDP). Usando i tre analizzatori di Avispa già sfruttati in precededenza, si trova sempre lo stesso risultato, per entrambe le formalizzazioni: ora il protocollo risulta safe, anche se pure in questo caso satmc raggiunge il limite di ricerca per entrambe le modellazioni, quindi la sua risposta non è da considerarsi affidabile. Nelle ultime due sezioni dell appendice B si riportano tutti i risultati delle analisi fatte.

Elementi di Sicurezza e Privatezza Lezione 19 SAML e sicurezza della posta elettronica

Elementi di Sicurezza e Privatezza Lezione 19 SAML e sicurezza della posta elettronica Elementi di Sicurezza e Privatezza Lezione 19 SAML e sicurezza della posta elettronica Chiara Braghin chiara.braghin@unimi.it SAML Security Assertion Markup Language Dalla lezione precedente (1) Single

Dettagli

Elementi di Sicurezza e Privatezza Lezione 18 Autenticazione: Single Sign On

Elementi di Sicurezza e Privatezza Lezione 18 Autenticazione: Single Sign On Elementi di Sicurezza e Privatezza Lezione 18 Autenticazione: Single Sign On Chiara Braghin chiara.braghin@unimi.it! Autenticazione cont d (1) Dalle lezioni precedenti: w L autenticazione è un prerequisito

Dettagli

Manuale di Integrazione IdM-RAS

Manuale di Integrazione IdM-RAS IdM-RAS Data: 30/11/09 File: Manuale di integrazione IdM-RAS.doc Versione: Redazione: Sardegna IT IdM-RAS Sommario 1 Introduzione... 3 2 Architettura del sistema... 4 2.1 Service Provider... 4 2.2 Local

Dettagli

Attori nella Federazione e Profili SAML. Massimiliano Pianciamore massimiliano.pianciamore@cefriel.it

Attori nella Federazione e Profili SAML. Massimiliano Pianciamore massimiliano.pianciamore@cefriel.it Attori nella Federazione e Profili SAML Massimiliano Pianciamore Agenda Ruoli e Attori in una infrastruttura federata Service Provider Identity Provider Attribute Authorities Lo standard SAML 2.0 Asserzioni

Dettagli

La Sicurezza delle Reti. La Sicurezza delle Reti. Il software delle reti. Sistemi e tecnologie per la multimedialità e telematica.

La Sicurezza delle Reti. La Sicurezza delle Reti. Il software delle reti. Sistemi e tecnologie per la multimedialità e telematica. Sistemi e tecnologie per la multimedialità e telematica Fabio Burroni Dipartimento di Ingegneria dell Informazione Università degli Studi di Siena burronif@unisi unisi.itit La Sicurezza delle Reti La presentazione

Dettagli

Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security con token SAML

Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security con token SAML Master Universitario di II livello in Interoperabilità Per la Pubblica Amministrazione e Le Imprese Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security

Dettagli

Elementi di Sicurezza e Privatezza Lezione 18 Autenticazione: Single Sign On

Elementi di Sicurezza e Privatezza Lezione 18 Autenticazione: Single Sign On Elementi di Sicurezza e Privatezza Lezione 18 Autenticazione: Single Sign On Chiara Braghin chiara.braghin@unimi.it Lab 8 Visti i problemi con la macchina virtuale e la rete, l assignment è sospeso 1 Autenticazione

Dettagli

[TS-CNS-INFRA] Gestione del ciclo di vita della Tessera sanitaria e della Carta nazionale dei servizi (TS-CNS)

[TS-CNS-INFRA] Gestione del ciclo di vita della Tessera sanitaria e della Carta nazionale dei servizi (TS-CNS) Progetto cofinanziato dall Unione Europea Fondo Europeo di Sviluppo Regionale POR FESR Sardegna 2007-2013 [TS-CNS-INFRA] Gestione del ciclo di vita della Tessera sanitaria e della Carta nazionale dei servizi

Dettagli

SPID: Avvio regolamentazione e pilota. 9 Giugno 2014

SPID: Avvio regolamentazione e pilota. 9 Giugno 2014 SPID: Avvio regolamentazione e pilota 9 Giugno 2014 CONTENUTI 1. SPID 2. Obiettivo dell incontro 3. Presentazione team AgID 4. Elementi dello Schema di Decreto e normativa UE (S. Arbia) 5. Architettura

Dettagli

Integrazione di Service Provider e Identity Provider SiRAC e INF3

Integrazione di Service Provider e Identity Provider SiRAC e INF3 Integrazione di Service Provider e Identity Provider SiRAC e INF3 SOMMARIO 1. Introduzione... 4 1.1. Contenuti del Documento... 4 1.2. Distribuzione... 5 1.3. Acronimi... 5 2. Integrazione di Service Provider...

Dettagli

SSL: applicazioni telematiche SSL SSL SSL. E-commerce Trading on-line Internet banking... Secure Socket Layer

SSL: applicazioni telematiche SSL SSL SSL. E-commerce Trading on-line Internet banking... Secure Socket Layer : applicazioni telematiche Secure Socket Layer E-commerce Trading on-line Internet banking... Protocollo proposto dalla Netscape Communications Corporation Garantisce confidenzialità e affidabilità delle

Dettagli

Shibboleth e Google Apps

Shibboleth e Google Apps Università di Modena e Reggio nell Emilia 17 giugno 2009 Panoramica funzionamento di default di Shibboleth; autenticazione SAML con Google Apps; indicazioni su come integrare Google Apps con Shibboleth

Dettagli

OPENID CONNECT 1.0 VERIFICA FORMALE DEL PROTOCOLLO IN HLPSL UNIVERSITÀ DEGLI STUDI DI MILANO DIPARTIMENTO DI INFORMATICA SEDE DI CREMA

OPENID CONNECT 1.0 VERIFICA FORMALE DEL PROTOCOLLO IN HLPSL UNIVERSITÀ DEGLI STUDI DI MILANO DIPARTIMENTO DI INFORMATICA SEDE DI CREMA UNIVERSITÀ DEGLI STUDI DI MILANO DIPARTIMENTO DI INFORMATICA SEDE DI CREMA VIA BRAMANTE 65 26013 CREMA (CR) ITALIA OPENID CONNECT 1.0 VERIFICA FORMALE DEL PROTOCOLLO IN HLPSL Progetto per l'esame di Sicurezza

Dettagli

Sicurezza nei Sistemi Distribuiti

Sicurezza nei Sistemi Distribuiti Sicurezza nei Sistemi Distribuiti Aspetti di Sicurezza La sicurezza nei sistemi distribuiti deve riguardare tutti i componenti del sistema e coinvolge due aspetti principali: Le comunicazioni tra utenti

Dettagli

Sicurezza nei Sistemi Distribuiti

Sicurezza nei Sistemi Distribuiti Sicurezza nei Sistemi Distribuiti Aspetti di Sicurezza La sicurezza nei sistemi distribuiti deve riguardare tutti i componenti del sistema e coinvolge due aspetti principali: Le comunicazioni tra utenti

Dettagli

Firma digitale Definizione

Firma digitale Definizione FIRMA DIGITALE Firma digitale Definizione La definizione di firma digitale è contenuta nel Dlgs. Del 4/04/2006 n.159 che integra il Codice dell amministrazione digitale in vigore dal 1/01/2006. Firma digitale

Dettagli

Il modello ICAR per la gestione dell Identit

Il modello ICAR per la gestione dell Identit Il modello ICAR per la gestione dell Identit Identità Digitale Federata Architettura, opportunità e prospettive di convergenza Forum PA 2008, Roma 15 maggio 2008 Massimiliano Pianciamore massimiliano.pianciamore@cefriel.it

Dettagli

Corso di Laurea in Informatica Reti e Sicurezza Informatica

Corso di Laurea in Informatica Reti e Sicurezza Informatica Corso di Laurea in Informatica Reti e Sicurezza Informatica Esercitazione 6 Autenticazione in Tomcat per lo sviluppo di Web Service. In questo documento si presentano i meccanismi fondamentali che consentono

Dettagli

SIRV-INTEROP Sicurezza basata sui ruoli

SIRV-INTEROP Sicurezza basata sui ruoli SIRV-INTEROP (UML-A8.2-0) 06 ottobre 2004 Approvazioni Il presente documento è stato approvato da: UML-A8.2-0 18/11/05 16.25 2 Storia delle Modifiche Versione Data Descrizione Riferimenti Numero Titolo

Dettagli

Meccanismi di Identity Management per la fruizione di servizi offerti da diversi Service Provider in modalità Single Sign On nel cloud

Meccanismi di Identity Management per la fruizione di servizi offerti da diversi Service Provider in modalità Single Sign On nel cloud Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in protocolli per reti mobili Meccanismi di Identity Management per la fruizione di servizi offerti

Dettagli

Web Services Dogane LINEE GUIDA

Web Services Dogane LINEE GUIDA Web Services Dogane LINEE GUIDA Pagina 1 di 17 Indice Indice... 2 1. INTRODUZIONE... 3 2. TEST FUNZIONALI SUI WEB SERVICES... 8 3. SICUREZZA... 14 4. FIRMA... 14 5. TRASFORMAZIONE CERTIFICATO DI FIRMA...

Dettagli

REGIONE BASILICATA DIPARTIMENTO INFRASTRUTTURE, OO.PP. E MOBILITA

REGIONE BASILICATA DIPARTIMENTO INFRASTRUTTURE, OO.PP. E MOBILITA REGIONE BASILICATA DIPARTIMENTO INFRASTRUTTURE, OO.PP. E MOBILITA Ufficio Difesa del Suolo di Potenza SISTEMA FEDERATO DI AUTENTICAZIONE Informatizzazione dell iter procedurale e dei controlli relativi

Dettagli

Gli XML Web Service. Prof. Mauro Giacomini. Complementi di Informatica Medica 2008/2009 1

Gli XML Web Service. Prof. Mauro Giacomini. Complementi di Informatica Medica 2008/2009 1 Gli XML Web Service Prof. Mauro Giacomini Medica 2008/2009 1 Definizioni i i i Componente.NET che risponde a richieste HTTP formattate tramite la sintassi SOAP. Gestori HTTP che intercettano richieste

Dettagli

Comunicazioni sicure su Internet: https e SSL. Fisica dell Informazione

Comunicazioni sicure su Internet: https e SSL. Fisica dell Informazione Comunicazioni sicure su Internet: https e SSL Fisica dell Informazione Il servizio World Wide Web (WWW) Come funziona nel dettaglio il Web? tre insiemi di regole: Uniform Resource Locator (URL) Hyper Text

Dettagli

Messa in esercizio, assistenza e aggiornamento di una Piattaform Open Source Liferay plug-in per ARPA

Messa in esercizio, assistenza e aggiornamento di una Piattaform Open Source Liferay plug-in per ARPA Messa in esercizio, assistenza e aggiornamento di una Piattaform Open Source Liferay plug-in per ARPA Pag. 1 di 16 Redatto da F. Fornasari, C. Simonelli, E. Croci (TAI) Rivisto da E.Mattei (TAI) Approvato

Dettagli

La sicurezza nelle comunicazioni Internet

La sicurezza nelle comunicazioni Internet Accesso remoto sicuro a intranet e a server aziendali di posta elettronica Un esempio Cosa ci si deve aspettare di sapere alla fine del corso La sicurezza nelle comunicazioni Internet Esiste un conflitto

Dettagli

SICUREZZA. Sistemi Operativi. Sicurezza

SICUREZZA. Sistemi Operativi. Sicurezza SICUREZZA 14.1 Sicurezza Il Problema della Sicurezza Convalida Pericoli per i Programmi Pericoli per il Sistema Difendere i Sistemi Scoperta di Intrusioni Cifratura Esempio: Windows NT 14.2 Il Problema

Dettagli

Sistemi Operativi SICUREZZA. Sistemi Operativi. D. Talia - UNICAL 14.1

Sistemi Operativi SICUREZZA. Sistemi Operativi. D. Talia - UNICAL 14.1 SICUREZZA 14.1 Sicurezza Il Problema della Sicurezza Convalida Pericoli per i Programmi Pericoli per il Sistema Difendere i Sistemi Scoperta di Intrusioni Cifratura Esempio: Windows NT 14.2 Il Problema

Dettagli

PROCEDURA APERTA (AI SENSI DEL D.LGS.163/2006 E S.M.I.)

PROCEDURA APERTA (AI SENSI DEL D.LGS.163/2006 E S.M.I.) PROCEDURA APERTA (AI SENSI DEL D.LGS.163/2006 E S.M.I.) PER L'ACQUISIZIONE DEL SERVIZIO EVOLUTIVO E DI ASSISTENZA SPECIALISTICA DEL SISTEMA INFORMATIVO LAVORO BASIL DELLA REGIONE BASILICATA P.O. FSE Basilicata

Dettagli

Guida Utente della PddConsole. Guida Utente della PddConsole

Guida Utente della PddConsole. Guida Utente della PddConsole Guida Utente della PddConsole i Guida Utente della PddConsole Guida Utente della PddConsole ii Copyright 2005-2015 Link.it srl Guida Utente della PddConsole iii Indice 1 Introduzione 1 2 I protocolli di

Dettagli

Sicurezza: credenziali, protocolli sicuri, virus, backup

Sicurezza: credenziali, protocolli sicuri, virus, backup Sicurezza: credenziali, protocolli sicuri, virus, backup La sicurezza informatica Il tema della sicurezza informatica riguarda tutte le componenti del sistema informatico: l hardware, il software, i dati,

Dettagli

Vallarino Simone. Corso di sicurezza A.A. 2003/2004 HTTPS

Vallarino Simone. Corso di sicurezza A.A. 2003/2004 HTTPS Vallarino Simone Corso di sicurezza A.A. 2003/2004 HTTPS INTRODUZIONE Per cominciare a parlare di https è necessario aprire la discussione ricordando le caratteristiche dell http: HTTP Nel sistema telematico

Dettagli

Sicurezza nelle applicazioni multimediali: lezione 7, sicurezza dei protocolli. Sicurezza dei protocolli (https, pop3s, imaps, esmtp )

Sicurezza nelle applicazioni multimediali: lezione 7, sicurezza dei protocolli. Sicurezza dei protocolli (https, pop3s, imaps, esmtp ) Sicurezza dei protocolli (https, pop3s, imaps, esmtp ) Stack di protocolli nella trasmissione della posta elettronica 2 Sicurezza a livello applicativo Ma l utilizzo di meccanismi di cifratura e autenticazione

Dettagli

Informatica per la comunicazione" - lezione 13 -

Informatica per la comunicazione - lezione 13 - Informatica per la comunicazione" - lezione 13 - Funzionamento di una password" 1: l utente tramite il suo browser richiede l accesso a una pagina del server; 2: il server richiede il nome utente e la

Dettagli

PRINCIPI DI COMPUTER SECURITY. Andrea Paoloni

PRINCIPI DI COMPUTER SECURITY. Andrea Paoloni PRINCIPI DI COMPUTER SECURITY Andrea Paoloni 2 Cade il segreto dei codici cifrati Corriere della Sera 26 febbraio 2008 3 Gli hacker sono utili? 4 Safety vs Security SAFETY (salvezza): protezione, sicurezza

Dettagli

Sicurezza e virtualizzazione per il cloud

Sicurezza e virtualizzazione per il cloud Sicurezza e virtualizzazione per il cloud Con il cloud gli utenti arrivano ovunque, ma la protezione dei dati no. GARL sviluppa prodotti di sicurezza informatica e servizi di virtualizzazione focalizzati

Dettagli

l identità digitale federata nel progetto ICAR

l identità digitale federata nel progetto ICAR l identità digitale federata nel progetto ICAR Francesco Meschia Roma, 16 febbraio 2006 agenda generalità sul progetto ICAR e sul task INF-3 situazione e problemi dell identità digitale in Italia l approccio

Dettagli

TRASMISSIONE DI DATI VIA INTERNET

TRASMISSIONE DI DATI VIA INTERNET TRASMISSIONE DI DATI VIA INTERNET 2.0 1 11 Sommario SOMMARIO...2 1. STORIA DELLE MODIFICHE...3 2. TRASMISSIONE DATI VIA INTERNET...4 2.1 SCOPO DEL DOCUMENTO...4 2.2 INTRODUZIONE...4 3. FORMATO DEI DOCUMENTI...5

Dettagli

Visione Generale. Versione 1.0 del 25/08/2009

Visione Generale. Versione 1.0 del 25/08/2009 Visione Generale Versione 1.0 del 25/08/2009 Sommario 1 Premessa... 4 2 Le componenti applicative... 6 2.1 Porta di dominio... 7 2.2 Infrastrutture per la cooperazione... 9 2.2.1 Registro degli Accordi

Dettagli

Guida Utente della PddConsole. Guida Utente della PddConsole

Guida Utente della PddConsole. Guida Utente della PddConsole Guida Utente della PddConsole i Guida Utente della PddConsole Guida Utente della PddConsole ii Copyright 2005-2014 Link.it srl Guida Utente della PddConsole iii Indice 1 Introduzione 1 2 I protocolli di

Dettagli

Accordi. Tecnologie di cooperazione. Cooperazione fra Amministrazioni

Accordi. Tecnologie di cooperazione. Cooperazione fra Amministrazioni Alcune considerazioni nell ambito di un sistema di cooperazione informatico che preveda lo scambio di dati tra due o più organizzazioni. Quando parliamo di un sistema di cooperazione informatico ci riferiamo

Dettagli

Obiettivo: realizzazione di reti sicure TIPI DI ATTACCO. Politica di sicurezza: a) scelte tecnologiche b) strategie organizzative

Obiettivo: realizzazione di reti sicure TIPI DI ATTACCO. Politica di sicurezza: a) scelte tecnologiche b) strategie organizzative Obiettivo: realizzazione di reti sicure Politica di sicurezza: a) scelte tecnologiche b) strategie organizzative Per quanto riguarda le scelte tecnologiche vi sono due categorie di tecniche: a) modifica

Dettagli

AREA SERVIZI ICT. Servizi di hosting offerti dall'area Servizi ICT. Integrazione con l'anagrafica Unica di Ateneo. hosting.polimi.

AREA SERVIZI ICT. Servizi di hosting offerti dall'area Servizi ICT. Integrazione con l'anagrafica Unica di Ateneo. hosting.polimi. AREA SERVIZI ICT Servizi di hosting offerti dall'area Servizi ICT Integrazione con l'anagrafica Unica di Ateneo hosting.polimi.it Indice 1. Anagrafica unica di Ateneo... 4 1.1. Introduzione all anagrafica

Dettagli

Sicurezza nelle reti

Sicurezza nelle reti Sicurezza nelle reti A.A. 2005/2006 Walter Cerroni Sicurezza delle informazioni: definizione Garantire la sicurezza di un sistema informativo significa impedire a potenziali soggetti attaccanti l accesso

Dettagli

MODELLO DI GESTIONE FEDERATA DELLE IDENTITÀ DIGITALI (GFID)

MODELLO DI GESTIONE FEDERATA DELLE IDENTITÀ DIGITALI (GFID) MODELLO DI GESTIONE FEDERATA DELLE IDENTITÀ DIGITALI (GFID) Versione 1.5 INDICE 1. PREFAZIONE...5 1.1. Autori... 5 1.2. Modifiche Documento... 5 1.3. Riferimenti... 6 1.4. Acronimi e Definizioni... 6 2.

Dettagli

RETI DI CALCOLATORI. Crittografia. La crittografia

RETI DI CALCOLATORI. Crittografia. La crittografia RETI DI CALCOLATORI Crittografia La crittografia La crittografia è la scienza che studia la scrittura e la lettura di messaggi in codice ed è il fondamento su cui si basano i meccanismi di autenticazione,

Dettagli

SMS API. Documentazione Tecnica YouSMS HTTP API. YouSMS Evet Limited 2015 http://www.yousms.it

SMS API. Documentazione Tecnica YouSMS HTTP API. YouSMS Evet Limited 2015 http://www.yousms.it SMS API Documentazione Tecnica YouSMS HTTP API YouSMS Evet Limited 2015 http://www.yousms.it INDICE DEI CONTENUTI Introduzione... 2 Autenticazione & Sicurezza... 2 Username e Password... 2 Connessione

Dettagli

Cenni sulla Sicurezza in Ambienti Distribuiti

Cenni sulla Sicurezza in Ambienti Distribuiti Cenni sulla Sicurezza in Ambienti Distribuiti Cataldo Basile < cataldo.basile @ polito.it > Politecnico di Torino Dip. Automatica e Informatica Motivazioni l architettura TCP/IPv4 è insicura il problema

Dettagli

Man-in-the-middle su reti LAN

Man-in-the-middle su reti LAN Università degli Studi di Udine Dipartimento di Ingegneria Gestionale, Elettrica e Meccanica 21 Marzo 2011 Scaletta 1 2 LAN switched ARP Alcuni attacchi MITM 3 4 5 Che cos è L attacco man-in-the-middle

Dettagli

XACML. Cos'è XACML? URI Cos'è XACML? Componenti controllo accessi policy-based. Componenti controllo accessi policy-based

XACML. Cos'è XACML? URI Cos'è XACML? Componenti controllo accessi policy-based. Componenti controllo accessi policy-based extensible Access Control Markup anguage Antonio ioy < lioy XACM @ polito.it > extensible Access Control Markup anguage Politecnico di Torino Dip. Automatica Antonio e ioy Informatica < lioy @ polito.it

Dettagli

SMS API. Documentazione Tecnica YouSMS SOAP API. YouSMS Evet Limited 2015 http://www.yousms.it

SMS API. Documentazione Tecnica YouSMS SOAP API. YouSMS Evet Limited 2015 http://www.yousms.it SMS API Documentazione Tecnica YouSMS SOAP API YouSMS Evet Limited 2015 http://www.yousms.it INDICE DEI CONTENUTI Introduzione... 2 Autenticazione & Sicurezza... 2 Username e Password... 2 Connessione

Dettagli

Appl. di emissione PKCS#11. API (Metacomandi) Resource Manager Windows. Drivers PC/SC dei lettori

Appl. di emissione PKCS#11. API (Metacomandi) Resource Manager Windows. Drivers PC/SC dei lettori Roma, 30 gennaio 2003 La realtà della carta di identità elettronica (nel seguito CIE) e della carta nazionale dei servizi (nel seguito CNS) rende ineluttabile l individuazione di servizi da erogare in

Dettagli

Vendere online. Andrea Marin. Università Ca Foscari Venezia SVILUPPO INTERCULTURALE DEI SISTEMI TURISTICI SISTEMI INFORMATIVI PER IL TURISMO

Vendere online. Andrea Marin. Università Ca Foscari Venezia SVILUPPO INTERCULTURALE DEI SISTEMI TURISTICI SISTEMI INFORMATIVI PER IL TURISMO Andrea Marin Università Ca Foscari Venezia SVILUPPO INTERCULTURALE DEI SISTEMI TURISTICI SISTEMI INFORMATIVI PER IL TURISMO a.a. 2013/2014 Section 1 Introduzione Parliamo di acquisti online quando a seguito

Dettagli

Sicurezza nelle Grid. Sommario. Page 1. Il Problema della Sicurezza nelle Grid. Grid Security Infrastructure Autorizzazione

Sicurezza nelle Grid. Sommario. Page 1. Il Problema della Sicurezza nelle Grid. Grid Security Infrastructure Autorizzazione Sommario Il Problema della Sicurezza nelle Grid Sicurezza nelle Grid Grid Security Infrastructure Autorizzazione 2 Page 1 Il Problema della Sicurezza nelle Grid (1) Le risorse sono presenti domini amministrativi

Dettagli

Framework di sicurezza della piattaforma OCP (Identity & Access Management)

Framework di sicurezza della piattaforma OCP (Identity & Access Management) Smart Cities and Communities and Social Innovation Bando MIUR D.D. 91/Ric. del 5 luglio 2012 Framework di sicurezza della piattaforma OCP (Identity & Access Management) AAI: Il problema che OCP ha affrontato

Dettagli

Protocollo HTTP. Alessandro Sorato

Protocollo HTTP. Alessandro Sorato Un protocollo è un insieme di regole che permettono di trovare uno standard di comunicazione tra diversi computer attraverso la rete. Quando due o più computer comunicano tra di loro si scambiano una serie

Dettagli

Ministero del Lavoro e delle Politiche Sociali

Ministero del Lavoro e delle Politiche Sociali Ministero del Lavoro e delle Politiche Sociali Prospetto Informativo on-line Standard tecnici del sistema informativo per l invio telematico del Prospetto Informativo Documento: UNIPI.StandardTecnici Revisione

Dettagli

Servizi di hosting offerti dall'area Servizi ICT Integrazione con l'anagrafica Unica di Ateneo. Area Servizi ICT

Servizi di hosting offerti dall'area Servizi ICT Integrazione con l'anagrafica Unica di Ateneo. Area Servizi ICT Area Servizi ICT Servizi hosting di Ateneo - Integrazione con l'anagrafica Unica di Ateneo Versione 1.1 http://hosting.polimi.it Servizi di hosting offerti dall'area Servizi ICT Integrazione con l'anagrafica

Dettagli

L'ARCHIVIO DIGITALE Documento Elettronico e Firma Digitale

L'ARCHIVIO DIGITALE Documento Elettronico e Firma Digitale L'ARCHIVIO DIGITALE Documento Elettronico e Firma Digitale Docente: http:// massimo@massimofarina.it 1 Documento Elettronico & Firma Digitale La forma elettronica Forma libera e Forma vincolata Firma elettronica

Dettagli

ASPETTI DI SICUREZZA NELLA

ASPETTI DI SICUREZZA NELLA ASPETTI DI SICUREZZA NELLA COOPERAZIONE TRA I SERVIZI Versione 1.0 INDICE 1. PREFAZIONE...3 1.1. Autori... 3 1.2. Modifiche Documento... 3 1.3. Riferimenti... 4 1.4. Acronimi e Definizioni... 4 2. OBIETTIVI

Dettagli

Approfondimento di Marco Mulas

Approfondimento di Marco Mulas Approfondimento di Marco Mulas Affidabilità: TCP o UDP Throughput: banda a disposizione Temporizzazione: realtime o piccoli ritardi Sicurezza Riservatezza dei dati Integrità dei dati Autenticazione di

Dettagli

CONCETTI DI NAVIGAZIONE IN RETE

CONCETTI DI NAVIGAZIONE IN RETE CONCETTI DI NAVIGAZIONE IN RETE Internet (La rete delle reti) è l insieme dei canali (linee in rame, fibre ottiche, canali radio, reti satellitari, ecc.) attraverso cui passano le informazioni quando vengono

Dettagli

Single Sign On sul web

Single Sign On sul web Single Sign On sul web Abstract Un Sigle Sign On (SSO) è un sistema di autenticazione centralizzata che consente a un utente di fornire le proprie credenziali una sola volta e di accedere a molteplici

Dettagli

Sommario. Introduzione alla Sicurezza Web

Sommario. Introduzione alla Sicurezza Web Sommario Introduzione alla Sicurezza Web Considerazioni generali IPSec Secure Socket Layer (SSL) e Transport Layer Security (TLS) Secure Electronic Transaction (SET) Introduzione alla crittografia Introduzione

Dettagli

Cifratura a chiave pubblica Sicurezza nelle reti di TLC - Prof. Marco Listanti - A.A. 2008/2009

Cifratura a chiave pubblica Sicurezza nelle reti di TLC - Prof. Marco Listanti - A.A. 2008/2009 Cifratura a chiave pubblica Crittografia a chiave privata Chiave singola Crittografia simmetrica La stessa chiave è utilizzata sia per la cifratura che per la decifratura dei messaggi La chiave rappresenta

Dettagli

Appendice:: Spunti sulla sicurezza e Internet Materiale fuori programma dedicato rigorosamente solo ai curiosi. prof.

Appendice:: Spunti sulla sicurezza e Internet Materiale fuori programma dedicato rigorosamente solo ai curiosi. prof. Operatore Informatico Giuridico Informatica Giuridica di Base A.A 2003/2004 I Semestre Appendice:: Spunti sulla sicurezza e Internet Materiale fuori programma dedicato rigorosamente solo ai curiosi prof.

Dettagli

Glossario servizi di Sicurezza Informatica offerti

Glossario servizi di Sicurezza Informatica offerti Glossario servizi di Sicurezza Informatica offerti Copyright LaPSIX 2007 Glossario servizi offerti di sicurezza Informatica SINGLE SIGN-ON Il Single Sign-On prevede che la parte client di un sistema venga

Dettagli

Protocolli di autenticazione ione per la connessione alle reti sociali. Le tecnologie del Web 2.0

Protocolli di autenticazione ione per la connessione alle reti sociali. Le tecnologie del Web 2.0 Protocolli di autenticazione ione per la connessione alle reti sociali Le tecnologie del Web 2.0 OAuth: cos è Semplice standard aperto per l autenticazione sicura delle API Protocollo aperto per permettere

Dettagli

La sicurezza nelle reti di calcolatori

La sicurezza nelle reti di calcolatori La sicurezza nelle reti di calcolatori Contenuti del corso La progettazione delle reti Il routing nelle reti IP Il collegamento agli Internet Service Provider e problematiche di sicurezza Analisi di traffico

Dettagli

Seminario di Sistemi Distribuiti RPC su SOAP

Seminario di Sistemi Distribuiti RPC su SOAP Seminario di Sistemi Distribuiti RPC su SOAP Massimiliano Vivian [777775] Massimiliano Vivian 1 Introduzione La comunicazione delle informazioni è l elemento fondamentale per lo sviluppo dei sistemi. SOAP

Dettagli

S.E.T. (SECURE ELECTRONIC TRANSACTION)

S.E.T. (SECURE ELECTRONIC TRANSACTION) UNIVERSITÀ DEGLI STUDI DI PERUGIA FACOLTÀ DI SCIENZE MATEMATICHE FISICHE E NATURALI Sicurezza Informatica S.E.T. (SECURE ELECTRONIC TRANSACTION) Andrea Valentini Albanelli Fabrizio Cardellini Introduzione

Dettagli

NETASQ V9: PKI & Controllo accessi. Presentation Marco Genovese Presales engineer marco.genovese@netasq.com

NETASQ V9: PKI & Controllo accessi. Presentation Marco Genovese Presales engineer marco.genovese@netasq.com NETASQ V9: PKI & Controllo accessi Presentation Marco Genovese Presales engineer marco.genovese@netasq.com Alcuni concetti Alcuni concetti prima di incominciare per chiarire cosa è una PKI e a cosa serve

Dettagli

Seminario di Sistemi Distribuiti: RPC su SOAP

Seminario di Sistemi Distribuiti: RPC su SOAP Corso di Sistemi Distribuiti Prof. S. Balsamo Seminario di Sistemi Distribuiti: RPC su SOAP [ 777775] 1 INTRODUZIONE 3 2 RPC 3 3 SOAP (SIMPLE OBJECT ACCESS PROTOCOL) 3 4 UTILIZZO DI SOAP COME PROTOCOLLO

Dettagli

Architetture Web. parte 1. Programmazione in Ambienti Distribuiti A.A. 2003-04

Architetture Web. parte 1. Programmazione in Ambienti Distribuiti A.A. 2003-04 Architetture Web parte 1 Programmazione in Ambienti Distribuiti A.A. 2003-04 Architetture Web (1) Modello a tre livelli in cui le interazioni tra livello presentazione e livello applicazione sono mediate

Dettagli

Sicurezza a livello IP: IPsec e le reti private virtuali

Sicurezza a livello IP: IPsec e le reti private virtuali Sicurezza a livello IP: IPsec e le reti private virtuali Davide Cerri Sommario L esigenza di proteggere l informazione che viene trasmessa in rete porta all utilizzo di diversi protocolli crittografici.

Dettagli

Laboratorio di RETI DI CALCOLATORI

Laboratorio di RETI DI CALCOLATORI Laboratorio di RETI DI CALCOLATORI A.A. 2009-2010 I WEB SERVICES Carlo Mastroianni Laboratorio di Reti di Calcolatori - Orario lunedì, 11:30-13:30, aula 40B mercoledì, 10:00-11:30, laboratorio settimo

Dettagli

Crittografia e Protocolli di Sicurezza

Crittografia e Protocolli di Sicurezza Crittografia e Protocolli di Sicurezza Ing. Emilio Spinicci 07/04/2004 1 Argomenti della lezione Introduzione Principi di Crittografia Protocolli di Sicurezza Attacchi ai Protocolli di Sicurezza 07/04/2004

Dettagli

Servizio. Governance e linee guida tecnicoorganizzative

Servizio. Governance e linee guida tecnicoorganizzative Servizio Governance e linee guida tecnicoorganizzative della Federazione INDICE 1. Introduzione 3 1.1 Definizione e Acronimi 3 1.2 Scopo del documento 4 1.3 Destinatari 4 2. Il Sistema FedERa 5 3. Il governo

Dettagli

3 OpenID Protocol and Messages

3 OpenID Protocol and Messages 3 OpenID Protocol and Messages OpenID è un sistema che consente a un utente di utilizzare una Uniform Resource Identifier o URI (come l URL del sito web) per scopi di autenticazione. Questo URI viene utilizzato

Dettagli

La sicurezza nel Sistema Pubblico di Connettività Prima parte

La sicurezza nel Sistema Pubblico di Connettività Prima parte La sicurezza nel Sistema Pubblico di Connettività Prima parte Ing. Gianfranco Pontevolpe Responsabile Ufficio Tecnologie per la sicurezza Centro Nazionale per l Informatica nella Pubblica Amministrazione

Dettagli

Sicurezza dei sistemi SIP: analisi sperimentale di possibili attacchi e contromisure

Sicurezza dei sistemi SIP: analisi sperimentale di possibili attacchi e contromisure UNIVERSITÀ DEGLI STUDI DI PISA FACOLTÀ DI INGEGNERIA Corso di Laurea in INGEGNERIA DELLE TELECOMUNICAZIONI Tesi di Laurea Sicurezza dei sistemi SIP: analisi sperimentale di possibili attacchi e contromisure

Dettagli

Sicurezza dei sistemi e delle reti 1. Lezione VI: IPsec. IPsec. La suite TCP/IP. Mattia Monga. a.a. 2014/15

Sicurezza dei sistemi e delle reti 1. Lezione VI: IPsec. IPsec. La suite TCP/IP. Mattia Monga. a.a. 2014/15 Sicurezza dei sistemi e delle 1 Mattia Lezione VI: Dip. di Informatica Università degli Studi di Milano, Italia mattia.monga@unimi.it a.a. 2014/15 1 cba 2011 15 M.. Creative Commons Attribuzione Condividi

Dettagli

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO Standard tecnici Gli standard tecnici di riferimento adottati sono conformi alle specifiche e alle raccomandazioni emanate dai principali

Dettagli

MANUALE UTENTE FORMULA PEC

MANUALE UTENTE FORMULA PEC MANUALE UTENTE FORMULA PEC Stampato il 03/12/10 16.22 Pagina 1 di 22 REVISIONI Revisione n : 00 Data Revisione: 01/04/2010 Descrizione modifiche: Nessuna modifica Motivazioni: Prima stesura Stampato il

Dettagli

Applicazioni per l autenticazione Sicurezza nelle reti di TLC - Prof. Marco Listanti - A.A. 2008/2009

Applicazioni per l autenticazione Sicurezza nelle reti di TLC - Prof. Marco Listanti - A.A. 2008/2009 Applicazioni per l autenticazione Kerberos Kerberos Servizio di autenticazione sviluppato dal MIT Fornisce un server di autenticazione centralizzato Basato su crittografia simmetrica (chiave privata) Permette

Dettagli

Dimitris Gritzalis (a), Costas Lambrinoudakis (b)

Dimitris Gritzalis (a), Costas Lambrinoudakis (b) Dimitris Gritzalis (a), Costas Lambrinoudakis (b) a Department of Informatics, Athens University of Economics and Business, 76 Patission Street, Athens GR 10434, Greece b Department of Information and

Dettagli

Sicurezza dei sistemi e delle reti 1. Lezione XIV: Single sign-on sul web. Il SSO sul web. OpenID. Mattia Monga. a.a. 2015/16

Sicurezza dei sistemi e delle reti 1. Lezione XIV: Single sign-on sul web. Il SSO sul web. OpenID. Mattia Monga. a.a. 2015/16 Sicurezza dei sistemi e delle 1 Mattia cache Lezione XIV: Single sign-on sul web cache Dip. di Informatica Università degli Studi di Milano, Italia mattia.monga@unimi.it a.a. 2015/16 1 cba 2011 15 M..

Dettagli

Sicurezza: credenziali, protocolli sicuri, virus, backup

Sicurezza: credenziali, protocolli sicuri, virus, backup Sicurezza: credenziali, protocolli sicuri, virus, backup prof. Monica Palmirani Lezione 13 Sicurezza Sicurezza dell autenticazione dei soggetti attori autenticazione Sicurezza degli applicativi autorizzazione

Dettagli

Analisi dei Requisiti

Analisi dei Requisiti Analisi dei Requisiti Pagina 1 di 16 Analisi dei Requisiti Indice 1 - INTRODUZIONE... 4 1.1 - OBIETTIVO DEL DOCUMENTO...4 1.2 - STRUTTURA DEL DOCUMENTO...4 1.3 - RIFERIMENTI...4 1.4 - STORIA DEL DOCUMENTO...4

Dettagli

Capitolo 8 La sicurezza nelle reti

Capitolo 8 La sicurezza nelle reti Capitolo 8 La sicurezza nelle reti Reti di calcolatori e Internet: Un approccio top-down 4 a edizione Jim Kurose, Keith Ross Pearson Paravia Bruno Mondadori Spa 2008 Capitolo 8: La sicurezza nelle reti

Dettagli

Robustezza crittografica della PEC

Robustezza crittografica della PEC Robustezza crittografica della PEC Prof. Massimiliano Sala Università degli Studi di Trento, Lab di Matematica Industriale e Crittografia Trento, 21 Novembre 2011 M. Sala (Università degli Studi di Trento)

Dettagli

CAPITOLO 27 SCAMBIO DI MESSAGGI

CAPITOLO 27 SCAMBIO DI MESSAGGI CAPITOLO 27 SCAMBIO DI MESSAGGI SCAMBIO DI MESSAGGI Sia che si guardi al microkernel, sia a SMP, sia ai sistemi distribuiti, Quando i processi interagiscono fra loro, devono soddisfare due requisiti fondamentali:

Dettagli

Guida ai certificati SSL User Guide

Guida ai certificati SSL User Guide Guida ai certificati SSL User Guide PROBLEMATICHE DEL WEB... 2 PRIVACY...3 AUTORIZZAZIONE/AUTENTICAZIONE...4 INTEGRITA DEI DATI...4 NON RIPUDIO...4 QUALI SONO I PRINCIPALI STRUMENTI UTILIZZATI PER GARANTIRE

Dettagli

Sistemi informativi e Telemedicina Anno Accademico 2008-2009 Prof. Mauro Giacomini

Sistemi informativi e Telemedicina Anno Accademico 2008-2009 Prof. Mauro Giacomini Sistemi informativi e Telemedicina Anno Accademico 2008-2009 Prof. Mauro Giacomini Concetti di base Tre funzioni fondamentali: Autenticazione: riceve le credenziali, le verifica presso un autorità, se

Dettagli

Tracciabilità degli utenti in applicazioni multipiattaforma

Tracciabilità degli utenti in applicazioni multipiattaforma Tracciabilità degli utenti in applicazioni multipiattaforma Case Study assicurativo/bancario Yann Bongiovanni y.bongiovanni@integra-group.it Roma, 4 ottobre 2006 Retroscena Un azienda multinazionale del

Dettagli

Sistema per la gestione delle identità digitali della Regione Sardegna. Identity Management System IdM RAS

Sistema per la gestione delle identità digitali della Regione Sardegna. Identity Management System IdM RAS Sistema per la gestione delle identità digitali della Regione Sardegna Identity Management System IdM RAS Data documento: 19.03.2013 File: Allegato 1 - Modalita di integrazione sistema di Identity Management

Dettagli

La rete è una componente fondamentale della

La rete è una componente fondamentale della automazioneoggi Attenti alle reti La telematica si basa prevalentemente sulle reti come mezzo di comunicazione per cui è indispensabile adottare strategie di sicurezza per difendere i sistemi di supervisione

Dettagli

Sommario. Modellazione di Kerberos mediante DASM. Kerberos (1) Descrizione Kerberos. Descrizione Kerberos Modellazione Analisi di Correttezza

Sommario. Modellazione di Kerberos mediante DASM. Kerberos (1) Descrizione Kerberos. Descrizione Kerberos Modellazione Analisi di Correttezza Sommario Modellazione di Kerberos mediante DASM Descrizione Kerberos Modellazione Analisi di Correttezza DASM per Kerberos 1 DASM per Kerberos 2 Kerberos (1) Descrizione Kerberos Kerberos è traslitterazione

Dettagli