Introduzione a Cardspace

1. Introduzione a Cardspace Raffaele Rialdi, Vevy Europe Visual Developer Security MVP Email: malta@vevy.comBlog: http://blogs.ugidotnet.org/raffaele MVP Profile: http://mvp.support.microsoft.com/profile/raffaele

2. Agenda • La teoria • La tecnologia • L'implementazione

3. Crisi di identità Vulnerabile • 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 PKIX.509 Costoso User/Pwd Difficile .... PKIX.509

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

5. Leggi dell'identità 1, 2, 3 • User Control and ConsentL'utente deve essere consapevole quando viene identificato e quali informazioni vengono rivelate • Windows Authentication e Passport non rispettano questo requisito • Minimal disclosure for a constrained useL'identificazione deve avvenire fornendo solo le minime informazioni necessarie • Least identifying information • 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

6. Leggi dell'identità 4, 5 • 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 • 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

7. Leggi dell'identità 6, 7 • 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 • 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

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

9. x.509 Custom Subject SAML Kerberos I protocolli standard IdentityProvider RelyingParty IdentityProvider RelyingParty • WS-SecurityPolicy • descrive il token di sicurezza ei claim richiesti dalla policy • WS-MetadataExchange • permette di richiedere ericevere le policy • WS-Trust • protocollo per richiedere ericevere 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 SecurityTokenService SecurityTokenService WS-SecurityPolicy WS-SecurityPolicy WS-Trust, WS-MetadataExchange IdentitySelector

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

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

12. Agenda • La teoria • La tecnologia • L'implementazione

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

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

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

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

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

18. Self issued cards Identity Provider • 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

19. Managed cards emesse da RP Identity Provider • 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

20. Managed cards con IP indipendente Identity Provider • 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

21. Flusso Identity Provider Token Token 3. filtro delle card / IP che soddisfano RP 4. scelta della card con Cardspace 1. Richiesta di accesso al sito 7. Token ok? 2. Risposta con requisiti di autenticazione Subject Relying Party 5. Richiesta Token 6. 8. Token di autenticazione a RP Infocard

22. STS • Active Directory Security Token Service (AD/STS) • usa kerberos • Linux STS (PingIdentity.com)

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

24. 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 Hacked!

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

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

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

28. Agenda • La teoria • La tecnologia • L'implementazione

29. Integrazione Asp.net - Cardspace • Activex • <object> ... </object> • XHTML behaviour • <ic:>

30. Asp.net e la login mista Token Cardspacepostato User era loggato? Si No registrato con CS? Si Loggato con Usr/Pwd? Aggiorno il profilo No Si No registrato con Usr/Pwd? Si Associo il profilocon Cardspace Utente già loggatocon Cardspace No Associare il profilosolo perché l'emailcoincide, è errato Utente non registrato(nuovo utente) Aggiorno il profilo Creo Utente Aggiorno il profilo L'utente è loggato e l'associazione ha senso

31. Dare i permessi ad un certificato • Aprire una Cmd come administrator • c:\> FindPrivateKey My localmachine • FindPrivateKey è negli esempi del Fx 3.0WCFSamples\TechnologySamples\Tools\FindPrivateKey\CS • Scegliere il certificato ecopiare la voce "Thumbprint"

32. Dare i permessi ad un certificato • Trovare il nome del file per quel certificato:FindPrivateKey my localmachine –t "thumbprint" -a

33. Dare i permessi ad un certificato • Visualizzare i permessi sul fileCacls nomefile • Riassegnare i permessi sul file aggiungendo network_serviceCacls nomefile /G System:F Administrators:F NetworkService:R Full Control Full Control Read • Verificare i permessi nuovamente (punto 5)

34. Domande?