34
Introduzione a Cardspace Email: [email protected] Blog: http://blogs.ugidotnet.org/raffaele MVP Profile: http://mvp.support.microsoft.com/profile/raffae le Visual Developer Security MVP Raffaele Rialdi, Vevy Europe

Introduzione a Cardspace

  • Upload
    doria

  • View
    147

  • Download
    0

Embed Size (px)

DESCRIPTION

Introduzione a Cardspace. 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. La teoria La tecnologia L'implementazione. Crisi di identità. - PowerPoint PPT Presentation

Citation preview

Page 1: Introduzione a Cardspace

Introduzione a Cardspace

Email: [email protected]: http://blogs.ugidotnet.org/raffaele

MVP Profile: http://mvp.support.microsoft.com/profile/raffaele

Visual Developer Security MVPRaffaele Rialdi, Vevy Europe

Page 2: Introduzione a Cardspace

Agenda

1. La teoria2. La tecnologia3. L'implementazione

Page 3: Introduzione a Cardspace

Crisi di identità• Problemi di privacy

– Identificare pur restando anonimi (forum, chat, ...)– Identificare in modo certo (banche, sportelli

virtuali)• 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

User/Pwd

PKIX.509

PKIX.509

Vulnerabile

Costoso

Difficile

....

Page 4: Introduzione a Cardspace

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

Page 5: Introduzione a Cardspace

Leggi dell'identità 1, 2, 3

1. User Control and ConsentL'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 useL'identificazione deve avvenire fornendo solo le minime informazioni necessarie

– Least identifying information

3. Justifiable PartiesIl 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

Page 6: Introduzione a Cardspace

Leggi dell'identità 4, 5

4. Directional IdentityL'identità deve essere direzionale. Se è omnidirezionale è pubblica a tutti. Se è monodirezionale è contestuale a quel server

– 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

5. Pluralism of operators and technologiesÈ necessario un metasystemUn 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

Page 7: Introduzione a Cardspace

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 contextsL'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

Page 8: Introduzione a Cardspace

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)

Page 9: Introduzione a Cardspace

I protocolli standard

• WS-SecurityPolicy– descrive il token di sicurezza e

i claim richiesti dalla policy• WS-MetadataExchange

– permette di richiedere ericevere le policy

• WS-Trust– protocollo per richiedere e

ricevere il token (STS)• Request for a Security Token (RST)• Request for a Security Token Response (RSTR)

• 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

SecurityToken

ServiceWS-Security

Policy

Kerberos SAML

SecurityToken

ServiceWS-Security

Policy

x.509 Custom

IdentityProvider

RelyingParty

IdentityProvider

RelyingParty

IdentitySelector

Subject

WS-Trust, WS-MetadataExchange

Page 10: Introduzione a Cardspace

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à

Page 11: Introduzione a Cardspace

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

Page 12: Introduzione a Cardspace

Agenda

1. La teoria2. La tecnologia3. L'implementazione

Page 13: Introduzione a Cardspace

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

Page 14: Introduzione a Cardspace

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

Page 15: Introduzione a Cardspace

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

Page 16: Introduzione a Cardspace

Le Infocard

• Un Infocard store per user (Cardspace.db)

• 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

\Users\<user>\AppData\Local\Microsoft\ CardSpace\ Vista\Documents and Settings\<user>\Local Settings\Application Data\Microsoft\ CardSpace\ XP/2K3

Page 17: Introduzione a Cardspace

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

Page 18: Introduzione a Cardspace

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

Identity Provider

Page 19: Introduzione a Cardspace

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

Identity Provider

Page 20: Introduzione a Cardspace

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 Identity Provider

Page 21: Introduzione a Cardspace

Flusso

Subject

Relying Party

Identity Provider

1. Richiesta di accesso al sito

2. Risposta con requisiti di autenticazione

3. filtro delle card / IP che soddisfano RP

4. scelta della card con Cardspace

Infocard

5. Richiesta Token6. Token

7. Token ok?

8. Token di autenticazione a RP

Token

Page 22: Introduzione a Cardspace

STS

• Active Directory Security Token Service (AD/STS)– usa kerberos

• Linux STS (PingIdentity.com)

Page 23: Introduzione a Cardspace

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 ...

Page 24: Introduzione a Cardspace

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

Page 25: Introduzione a Cardspace

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

Page 26: Introduzione a Cardspace

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-0aae-

472b-9e9c-bb8ca878bc341033.mspx– http://snipr.com/1nbn9

Page 27: Introduzione a Cardspace

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

Page 28: Introduzione a Cardspace

Agenda

1. La teoria2. La tecnologia3. L'implementazione

Page 29: Introduzione a Cardspace

Integrazione Asp.net - Cardspace

• Activex– <object> ... </object>

• XHTML behaviour– <ic:>

Page 30: Introduzione a Cardspace

Asp.net e la login mista

Creo UtenteAggiorno il profilo

Utente già loggatocon Cardspace

Token Cardspacepostato

User era loggato?

Associo il profilocon Cardspace

registrato con CS?

registrato con

Usr/Pwd?

Utente non registrato(nuovo utente)

NoSi

Loggato con Usr/Pwd?

Aggiorno il profilo

NoSi

No

NoAssociare il profilosolo perché l'emailcoincide, è errato

Aggiorno il profilo

Si

Si

L'utente è loggato e l'associazione ha senso

Page 31: Introduzione a Cardspace

Dare i permessi ad un certificato

1. Aprire una Cmd come administrator2. c:\> FindPrivateKey My localmachine

– FindPrivateKey è negli esempi del Fx 3.0WCFSamples\TechnologySamples\Tools\FindPrivateKey\CS

3. Scegliere il certificato ecopiare la voce "Thumbprint"

Page 32: Introduzione a Cardspace

Dare i permessi ad un certificato

4. Trovare il nome del file per quel certificato:FindPrivateKey my localmachine –t "thumbprint" -a

Page 33: Introduzione a Cardspace

Dare i permessi ad un certificato

5. Visualizzare i permessi sul fileCacls nomefile

6. Riassegnare i permessi sul file aggiungendo network_serviceCacls nomefile /G System:F Administrators:F NetworkService:R

Full Control Full ControlRead

7. Verificare i permessi nuovamente (punto 5)

Page 34: Introduzione a Cardspace

Domande?