Transcript Privacy in Cloud Computing Identity Management System for Cloud Microsoft CardSpace Purdue University.

Privacy in Cloud Computing
Identity Management System for Cloud Microsoft CardSpace
Purdue University
Outline
1.
2.
3.
4.
5.
Introduction
Laws of Identity Management
Microsoft CardSpace’s Model of Identity Management
CardSpace Framework
Improving Security of CardSpace
5.1 Proposed Approaches
6. Conclusion
Here comes your footer
Identity Management System
 Manages the digital identity of cloud users.
 Creates digital identities for its user entities and protects their Personally
Identifiable Information (PII).
 Allow users to authenticate themselves, without revealing their actual identity
to either vendors or network providers.
 The user has the ownership of the identity management data.
 Control the flow of dynamic personal information by the user, over the cloud.
 Support pseudonyms and multiple and discrete identities to protect user
privacy .
 Minimize the amount of the personal data which a user needs to share with
the Relying Party .
 Having a store of multiple digital identities (Gmail account, network account)
with various service providers like e-bay, Gmail available to one entity (e.g.,
application) helps to uniquely identify a single person.
- If not properly protected maybe exploited and abused.
- Identity management data may be accessed from the cloud by authorized entities
Here comes your footer
Page 3
2.. Laws of Identity Management
 Kim Camerson (Microsoft) has identified 7 laws which are meant to be
fundamentals of a conformed Identity Management System, of which the
following three laws must be basics of any IDM system: [1]
• User Control and Consent: An identity management system must only reveal
information identifying user with a user’s consent (Law 1)
• Minimal Disclosure for a constrained Use: An identity system must disclose the
least amount of identifying information possible. (Law 2)
• Justifiable Parties: Identity systems must be designed so the disclosure of
identifying information is limited to parties having a necessary and justifiable
place in a given identity relationship. (Law 3)
• Directed Identity: An identity system should support both Omni-directional
identifiers for use by public entities, and unidirectional identifiers for use by
private entities, in order to facilitate discovery while preventing unnecessary
release of correlation handles. (Law 4 )
Here comes your footer
http://www.identityblog.com
3. CardSpace Model of Identity Management
[2]
Here comes your footer
4.
Microsoft Windows CardSpace
 Windows CardSpace is an Identity-metasystem which provides a way,
for managing multiple digital identities of a user [2] .It is a new claims
based access platform/ architecture, developed for windows XP and is a
plug-in for Internet explorer 7 browser. [3] The CardSpace is designed to
comply with the seven Laws of identities by Kim Cameron of Microsoft
[4].
 In CardSpace every digital identity transmitted on the network contains
some kind of security token. A security token consists of a set of one or
more claims, such as a username, a user's first name, last name, home
address and even more sensitive information such as SSN, credit card
numbers. These security tokens provide information in order to prove
that these claims really do belong to the user who's presenting them
{authenticating the identity of the user}. To make it user friendly,
CardSpace implements an intuitive user interface for working with digital
identities in form of a visual “information card”, Infocard, for them to
make good decisions about using their digital identities, hence usercentric.
Here comes your footer
4.
CardSpace Framework
The CardSpace makes use of “open” XML-based protocols, including Web services (WS-*) protocols
and SOAP. The following steps describe message flows of the CardSpace framework: [5]
(1)CEUA (CardSpace enabled user agent/service requestor) → RP
The CardSpace enabled user agent, CEUA (CardSpace enabled browser) requests a service from the relying
party, using HTTP and gets a HTTP gets Login HTML Page Request.
(2) RP → CEUA: HTML Login Page + InfoCard Tags (XHTML or HTML object tags)
The RP identifies itself using a public key certificate (e.g. a SSL/TLS certificate) and declares itself as a
CardSpace enabled RP using XHTML or HTML object tags, i.e. a CardSpace enabled website or service provider.
(3) CEUA ↔ RP: CEUA retrieves security policy via WS-Security Policy
If the RP is card enabled, the CEUA obtains the RP’s security policy described using WS-Security, this policy is
retrieved using WS-Metadata Exchange (protocol suites for establishing/ verifying identity and any aspects
necessary for using that protocol suite). This policy includes things such as what security token formats the RP
will accept, exactly what claims those tokens must contain, and which Idp (identity provider) are trusted to makes
such assertions, in order for this user to be granted the service.
(4) CEUA ↔ User: User picks an InfoCard
In this step the User matches the RP’s security policy with an appropriate InfoCard (containing the type of
security token required by the RP), which satisfies the RP’s policy. After the user selects an Infocard, the CEUA
initiates a connection with the Idp that issued the Infocard, and step 5 follows.
Here comes your footer
Page 7
4.
CardSpace Framework
(5) CEUA ↔ IdP : User Authentication
The user performs authentication process with the Idp, either using username/password
login or using self-issued InfoCard. This is done for the user to prove the ownership of the
InfoCard being used.
(6) CEUA ↔ IdP: CEUA retrieves security token via WS-Trust
If the authentication is successful the user requests the Idp to provide a security token
which holds an assertion of the truth of the claims listed within the selected InfoCard. The
CEUA obtains the security token using WS-trust.
(7) CEUA → RP: CEUA presents the security token via WS-Security
Finally the CEUA forwards the security token to the RP using WS-Security.
(8) RP → CEUA: Welcome, you are now logged in!
If the RP is able to verify the security token, the service is granted to the user.
Here comes your footer
Page 8
5.
Improving Security of CardSpace
 Although CardSpace replaces Password-Based Web logins (preventing Phishing),
with that of using digital security certificates/ tokens, there are certain security
limitations in it’s framwork [5]:
1. User’s Judgements of RP Trustworthiness – In the CardSpace framework, the user is prompted
for its consent to be authenticated to an RP using a particular InfoCard, the user makes a
judgment regarding the trustworthiness of the RP (step 2). Although, Microsoft recommends
that the user should only make use of a high assurance certificate such as an X.509 certificate.
Most users do not pay much attention when they are asked to approve a digital certificate,
either because they do not understand the importance of the approval decision or because they
know that they must approve the certificate in order to get access to a particular website. RPs
without any certificates at all can be used in the CardSpace framework.
Even if the RP presents a higher-assurance certificate, the user still needs to rely on an Idp who
is providing that certificate to the RP and the user need to trust the Idp. Therefore, higherassurance certificates do not solve this problem completely.
Here comes your footer
5.
Improving Security of CardSpace
2. Reliance on a Single Layer of Authentication
The security of the CardSpace identity metasystem relies on the authentication of the user
by the IdP (step 5). In a case where a single IdP and multiple RPs are involved in a single
working session, which we expect to be a typical scenario, the security of the identity
metasystem within that working session will rely on a single layer of authentication, that is,
the authentication of the user to the IdP. This user authentication can be achieved in a
variety of ways (e.g., using an X.509 certificate, Kerberos v5 ticket, self-issued token or
password); however, it seems likely that, in the majority of cases, a simple
username/password authentication technique will be used. If a working session is hijacked
(e.g., by compromising a self-issued token) or the password is cracked (e.g., via guessing,
brute-force, key logging, or dictionary attacks), the security of the entire system will be
compromised.
How do we bypass these Security Limitations?
The goal is to prevent the need to reveal the actual values of the claims to any party within
the CardSpace framework, this way no party will have to trust any other party to the level
that it has to reveal the actual values of the claims to it.
Here comes your footer
Page 10
5.1
Proposed Approaches
1. Use of Zero-Knowledge Proofing and Selective Disclosure with a ZKP,
it is possible to prove a claim or assertion without actually disclosing
any credentials.
 The solution using a ZKP works as follows. For instance, a service
requires a user to be over 18. The user wants to satisfy the relying
party’s technical policy but tell the party nothing or as little as possible.
He need not to reveal his date of birth, just needs to somehow prove
being over 18. This proves something without revealing all.
Fig. Use of ZKP during Negotiation
Here comes your footer
5.1 Zero-Knowledge Proofing, Selective Disclosure
 ZKPs are possible with cryptography. Few popular ZKP schemes that are available for
example Fiat-Shamir proof of identity protocol: [6]
1. A trusted center chooses n=pq, and publishes n but keeps p and q secret.
2. Each prover A chooses a secret s with gcd(s,n)=1, and publishes v=s2 mod n.
3. A proves knowledge of s to B by repeating:
(a) A chooses random r and sends r2 mod n to B.
(b) B chooses random e in {0,1}, and sends it to A.
(c) A responds with a=rse mod n.
(d) B checks if a2 = ve r2 mod n.
 If A follows the protocol and knows s, then B's check will always work
 Iff A does not know s, then they can only answer the question with probability 1/2.
The value of n should be digitally signed by the Idp by including it within the security token
for example: XML- signature within a SAML assertion.
Here comes your footer
5.2 ZKP in SAML security token
Security Assertions Markup Language (SAML) tokens are XML representations of
claims. [7]
C#
Claim myClaim = new Claim(
ClaimTypes.GivenName, "Martin", Rights.PossessProperty);
SamlAttribute sa = new SamlAttribute(myClaim);
Here comes your footer
6. Conclusion
1. Improve security of cardspace using ZKP.
2. Adopt CardSpace for cloud as apposed to just for Web Services Access.
Information on CardSpace Implementation:
----The CardSpace Login Control for Asp.Net
http://www.qualitydata.com/products/windows-cardspace/asp-net-informationcard-login.aspx
--- Project CardSpae
http://www.codeproject.com/KB/WC/Introducing_Cardspace.aspx
Here comes your footer
Page 14
REFERENCES:
 [1] K. Camerson et al. Proposal for a Common Identity Framework: A user-Cenctric
Identity Metasystem, http://www.identityblog.com/, October 05, 2008.
 [2] Introducing Windows CardSpace
http://msdn.microsoft.com/en-us/library/aa480189.aspx
 [3] http://en.wikipedia.org/wiki/Windows_Live_ID
 [4] CLAIMS-BASED IDENTITY FOR WINDOWS
http://download.microsoft.com/download/7/D/0/7D0B5166-6A8A-418A-ADDD95EE9B046994/Claims-Based%20Identity%20for%20Windows.pdf
 [5] W. A. Alrodhan, C. J. Mitchell, Improving the Security of CardSpace, EURASIP
Journal on Information Security Vol. 2009, doi:10.1155/2009/167216, 2009.
 [6] Zero knowledge example Fiat-Shamir proof of identity
http://pages.swcp.com/~mccurley/talks/msri2/node24.html
 [7] SAML Tokens and Claims -msdn
http://msdn.microsoft.com/en-us/library/ms733083.aspx
Here comes your footer
Page 15