Raffaele Rialdi, Vevy Europe
Visual Developer Security MVP
Email: [email protected]
Blog: http://blogs.ugidotnet.org/raffaele
MVP Profile: http://mvp.support.microsoft.com/profile/raffaele
Agenda
1. La teoria
2. La tecnologia
3. L'implementazione
Crisi di identità
• Problemi di privacy
– Identificare pur restando anonimi (forum, chat, ...)
– Identificare in modo certo (banche, sportelli
virtuali)
Vulnerabile
User/Pwd
Costoso
• L'identità cambia a seconda del contesto
– Identità virtuali diverse per ogni dominio non in
trust
– Identità virtuali spesso differenti da quella fisica
• L'identità custodita da un sito A potrebbe
essere riutilizzata dall'utente nel sito B
– Il sito A potrebbe usare la password all'insaputa
dell'utente
• Password deboli o difficili da ricordare
PKI
X.509
Difficile
PKI
X.509
....
Si parla di identità
• È un insieme di informazioni che descrivono in
qualche modo un utente o una entità
• Le applicazioni usano queste informazioni per
– Identificare in modo univoco (nel proprio dominio)
– Autorizzare ciò che l’utente può fare nell’applicazione
– Personalizzare il contenuto erogato all’utente/entità
• Il contenitore sulle informazioni relative all’identità è
normalmente chiamato “Token”
– Il formato cambia a seconda del metodo di autenticazione
Leggi dell'identità 1, 2, 3
1.
User Control and Consent
L'utente deve essere consapevole quando viene identificato e
quali informazioni vengono rivelate
– Windows Authentication e Passport non rispettano questo requisito
2.
Minimal disclosure for a constrained use
L'identificazione deve avvenire fornendo solo le minime
informazioni necessarie
– Least identifying information
3.
Justifiable Parties
Il sistema di identificazione deve coinvolgere solo le parti che
sono coinvolte nel dialogo
– Passport implicava l'identificazione da parte di Microsoft anche per su siti
non Microsoft
http://www.identityblog.com
Leggi dell'identità 4, 5
4.
Directional Identity
L'identità deve essere direzionale. Se è omnidirezionale è
pubblica a tutti. Se è monodirezionale è contestuale a quel server
–
–
5.
Il provider delle identità deve supportare sia identità pubbliche che
private
L’utente non sempre desidera che il server a cui si collega possa rivelare
informazioni su di se
Pluralism of operators and technologies
È necessario un metasystem
Un utente può avere più identità da spendere in contesti
differenti (banche, forum, sportelli comunali, ...) e
l'interoperabilità tra provider di identificazione deve essere
possibile
http://www.identityblog.com
Leggi dell'identità 6, 7
6. Human Integration
L'essere umano deve poter gestire e scegliere
l'identità in modo chiaro e semplice. Il canale
uomo-macchina è difficile da proteggere.
– password difficili da ricordare e facili da trovare o sniffare
7. Consistent experience across contexts
L'utente deve poter scegliere l'identità in modo
semplice e trasparente a prescindere dal contesto
(tecnologie e provider coinvolte in quel contesto)
http://www.identityblog.com
Identity Metasystem
• Consiste nell’uso di una serie di protocolli standard
(WS-*) che permettono di far dialogare tre attori:
– Subject: l'utente o il servizio che deve dimostrare la
propria identità
– Relying Party (RP): il sito web/servizio che deve
identificare chi si collega
– Identity Provider (IP): l'entità che genera il token con le
informazioni e che ne garantisce la veridicità
• Il Security Token Service (STS) permette di convertire
un token in un altro formato o trasformare i claim
• Il security token è espresso nel formato standard
SAML (Security Assertion Markup Language)
I protocolli standard
• WS-SecurityPolicy
– descrive il token di sicurezza e
i claim richiesti dalla policy
• WS-MetadataExchange
– permette di richiedere e
ricevere le policy
Identity
Provider
Relying
Party
Identity
Provider
Relying
Party
Kerberos
SAML
x.509
Custom
Security
Token
Service
WS-Security
Policy
Security
Token
Service
WS-Security
Policy
• WS-Trust
– protocollo per richiedere e
ricevere il token (STS)
• Request for a Security Token (RST)
• Request for a Security Token Response (RSTR)
WS-Trust, WS-MetadataExchange
Identity
Selector
Subject
• Gli Identity Provider hanno al loro interno un Security Token Service (STS)
• Cardspace (cioè la gestione dell'interfaccia utente) è "ignorante" nei
confronti dei formati dei token
I claim (asserzioni)
• Chi ci autentica ha bisogno di asserzioni che servono per il
processo di autorizzazione
• Alcuni claim per Raffaele Rialdi
–
–
–
–
È uno developer
È sposato
Ha ricevuto l'award MVP
Ha un blog all'indirizzo http://blogs.ugidotnet.org/raffaele
• L'identità digitale di un soggetto è data da un insieme di
asserzioni fornite in modo sicuro e verificabile da un provider
di identità
Role Claim based authentication
• I ruoli forniscono diritti agli utenti per eseguire azioni o accedere a risorse
– Presuppone di identificare l'utente e poi verificare se ha un certo diritto
– Il Principal di .NET incapsula utente e rispettivi ruoli
• I Claim sono asserzioni che viaggiano all'interno del token
– La loro veridicità dipende dall'Identity Provider
– Anche una carta di identità può essere falsa, nonostante il suo IP sia credibile
• È veramente necessario identificare un utente per assegnargli un diritto?
– Per verificare l'età di una persona non è necessario conoscerne il nome
• I token di accesso di Windows
– non sono stati progettati per essere cross-platform
– sono erogati da sistemi operativi (i claim possono essere erogati anche da
altre entità)
– I SID e le ACL nei token sono utili solo all'interno dell'OS. I Claim hanno
significato ovunque il loro Identity Provider sia trusted
Agenda
1. La teoria
2. La tecnologia
3. L'implementazione
Cos'è Cardspace?
• Cardspace è l'implementazione Windows per la scelta delle
Infocard che rappresentano le identità dell'utente
• I vantaggi di Cardspace sono
– Rendere all'utente semplice ed economico l'uso dei certificati digitali
(PKI)
– Niente più username/password
– Addio Phishing
• Mono è in Work-in-progress su Cardspace
• Firefox ha un plugin funzionante
• Linux ha un Identity Provider di PingIdentity.com
Interazione uomo - PC
• Niente più password, solo "Card"
• UI isolata in un altro desktop
• L'infrastruttura completa comprende:
– Il motore principale (Infocard.exe)
• gira come Localsystem, dialoga con UI via RPC
• Include un Identity Provider locale
– L'interfaccia utente di CardSpace (icardgt.exe)
• gira con l'account utente
– Un control panel applet (InfoCardCpl.Cpl)
– I componenti per aprire la UI da IE7 e WCF
Le Infocard
• Contengono metadati sui Claim compilati, non i
valori effettivi
• I dati delle Infocard non escono mai dal PC (se non
quando sono esportate dall'utente)
• È l'utente a chiedere all'IP il token e a passarlo, solo
se vuole, alla RP
– Il token non è usabile neppure dal Subject ma transita solo
tramite l'utente
– Il Subject può chiedere un secondo token di "preview" per
verificare le informazioni prima di inviarle
Le Infocard
• Un Infocard store per user (Cardspace.db)
\Users\<user>\AppData\Local\Microsoft\ CardSpace\
\Documents and Settings\<user>\Local Settings\Application Data\Microsoft\ CardSpace\
Vista
XP/2K3
• Le ACL dello store abilitano solo Localsystem
• Criptato due/tre volte con:
– Machine Key. Se lo store è copiato su un'altra installazione è
inutilizzabile
• In caso di crash recovery le card sono perse. Backup!!!
– User Key (basato sulle credenziali utente). Se l'utente non è loggato, la
chiave non è neppure presente sulla macchina
• Se la password viene resettata, le card sono perse. Backup!!!
– Pin. Se l'utente vuole, può proteggere ogni card con un pin
• Il backup esporta le card criptandole con una password
chiesta al momento dell'esportazione
Contenuto di una Infocard (.crd)
• Uno o più URL dell'indirizzo IP dell'STS
– Necessario per recuperare il Security Token che contiene i
Claim
• I tipi di Claim che saranno contenuti dentro il
Security Token
– L'IP li cripta con la chiave pubblica della Relying Party
• I tipi di Security Token creabili dall'Identity Provider
• I valori dei Claim sono sempre e solo custoditi dentro
l'Identity Provider
Self issued cards
• L'utente è Identity provider di se stesso
• È lo scenario più diffuso in internet
– Forum, community, siti aziendali, ...
• I Claim sono garantiti dall'IP e quindi non necessariamente
"veri"
• La distinzione tra registrazione iniziale e login non ha più
senso
– Cardspace ci ricorda quali cards sono state usate su un sito
Subject
Relying Party
Managed cards emesse da RP
• L'Identity Provider è il sito web / servizio
• Scenario comune dove l'utente possa accedere solo dopo
approvazione della relying party
– Listini rivenditore, siti come ebay, banche, ...
• I Claim sono stabiliti da RP e perciò affidabili
• La RP deve erogare una cards al Subject prima che questo
possa accedere
Subject
Relying Party
Managed cards con IP indipendente
• La Relying Party deve fidarsi dell'Identity Provider
– Cardspace può nascondere all'IP l'identità della RP
• Scenario dove una sola card abilita più relying party
– Equivalente di una "carta di identità"
– Siti governativi, aziende associate ("federate"),
• I Claim sono affidabili
• La IP deve erogare una card al Subject
Subject
Relying Party
3. filtro delle card / IP
che soddisfano RP
4. scelta della card
con Cardspace
1. Richiesta di
accesso al sito
Relying Party
7. Token ok?
2. Risposta con requisiti
di autenticazione
Subject
6.
5. Richiesta
Token
8. Token di autenticazione a RP
STS
• Active Directory Security Token Service (AD/STS)
– usa kerberos
• Linux STS (PingIdentity.com)
Self issued cards
• Le personal cards possono avere solo 12 Claim:
– GivenName, Surname, EmailAddress, StreetAddress, Locality,
StateOrProvince, PostalCode, Country, PrimaryPhone, DateOfBirth,
Gender
– PrivatePersonalIdentifier (PPID, non appare nella UI)
• PPID viene generato la prima volta che viene usato
• PPID viaggia dentro il token criptato e non è intercettabile
– RP lo legge in chiaro
• PPID non viene mostrato all'utente (Social Engineering)
• PPID è differente per ogni Relying Party
– RP non può usare il PPID per rubare info su altri siti
• Quindi PPID è già più sicuro di una password, ma ...
Private Personal Identifier (PPID)
• Se l'hacker ruba il PPID alla relying party
• Se l'hacker si scrive un suo Identity Provider
• Se l'hacker genera una propria card con quel PPID
• Soluzione: Non usare PPID ma una combinazione tra
PPID e la public key dell'Issuer (l'Identity Provider)
• Come: In TokenProcessor.cs viene esposta la
proprietà UniqueID che combina queste due cose
PPID
• L'unico Claim di una personal card che l'utente non ha
modo di modificare
• Derivato dalla master key del certificato SSL
– Se il certificato è EV, usa Organization, Location, State, Country
– Se il certificato è standard, usa il campo subject di tutte le
certification authority concatenate
– Quindi il PPID è sempre differente, da website a website
• La classe TokenProcessor espone una proprietà
(UniqueID) che è l'hash di PPID e la public key dell'issuer
Prerequisiti: certificato SSL
• Cardspace richiede un certificato SSL sul webserver/servizio
• La certificate authority deve essere valida e la certificate revocation
list deve essere raggiungibile
– Commerciale (indispensabile per Internet)
• Certificato Standard: ~18 … 250$ / anno
• Certificato Extended Validation (EV): ~400 … 900$ / anno
– Win2K3 Certificate Authority per Intranet / Test
– OpenSSL Certificate Authority per Intranet / Test
• Chi, come, cosa, ... sui certificati
– http://technet2.microsoft.com/windowsserver/en/library/fb3df0cd-0aae472b-9e9c-bb8ca878bc341033.mspx
– http://snipr.com/1nbn9
Certificati di test
• Affinché i certificati siano validi è necessario che:
–
–
–
–
La Certificate Authority sia valida. Es: Adatum.com
Il certificato server sia valido. Es: Fabrikam.com
La revocation List sia disponibile. Es: Adatum.crl
Il file Hosts mappi su localhost la Adatum e Fabrikam
• One-time WCF Setup
– http://msdn2.microsoft.com/en-us/library/ms751527.aspx
– Tools: Fx3Samples\WCF_Samples\Setup\CS
• Cardspace Certificates Setup
– http://msdn2.microsoft.com/en-us/library/aa967570.aspx
– Tools: Fx3Samples\CardSpace_Samples\CreatingManagedCards\CS
Agenda
1. La teoria
2. La tecnologia
3. L'implementazione
Integrazione Asp.net - Cardspace
• Activex
– <object> ... </object>
• XHTML behaviour
– <ic:>
Asp.net e la login mista
Token Cardspace
postato
Si
User era
loggato?
No
Si
Loggato con
Usr/Pwd?
Si
Aggiorno il profilo
registrato
con CS?
No
No
Si
Associo il profilo
con Cardspace
Utente già loggato
con Cardspace
registrato
con
Usr/Pwd?
No
Associare il profilo
solo perché l'email
coincide, è errato
Utente non registrato
(nuovo utente)
Aggiorno il profilo
Creo Utente
Aggiorno il profilo
L'utente è loggato e
l'associazione ha senso
Dare i permessi ad un certificato
1. Aprire una Cmd come administrator
2. c:\> FindPrivateKey My localmachine
–
FindPrivateKey è negli esempi del Fx 3.0
WCFSamples\TechnologySamples\Tools\FindPrivateKey\CS
3. Scegliere il certificato e
copiare la voce "Thumbprint"
Dare i permessi ad un certificato
4. Trovare il nome del file per quel certificato:
FindPrivateKey my localmachine –t "thumbprint" -a
Dare i permessi ad un certificato
5. Visualizzare i permessi sul file
Cacls nomefile
6. Riassegnare i permessi sul file aggiungendo
network_service
Cacls
nomefile
/G System:F Administrators:F NetworkService:R
Full Control
Full Control
7. Verificare i permessi nuovamente (punto 5)
Read
Domande?