Addressing privacy issues in CardSpaceWaleed A. Alrodhan and Chris J. MitchellRoyal Holloway, University of London,Egham, Surrey, TW20 0EX, United Kingdom{W.A.Alrodhan, C.Mitchell}@rhul.ac.ukAbstractCardSpace (formerly known as InfoCard) is a DigitalIdentity Management system that has recently been adoptedby Microsoft. In this paper we identify two security flawsin CardSpace that may lead to a serious privacy violation.The first flaw is the reliance on Internet user judgementsof the trustworthiness of service providers, and the secondis the reliance of the system on a single layer of authen-tication. We also propose a solution designed to addressboth flaws. Our solution is compatible with the currentlydeployed CardSpace identity metasystem, and should en-hance the privacy of the system with minor changes to thecurrent CardSpace framework. We also provide a securityand performance analysis of the proposed solution.1 IntroductionAlong with the growing reliance on Internet web appli-cations in our daily life, comes the problem of managing thenecessary digital identities and preserving their privacy. Inan open large-scale domain such as the Internet, preservinguser privacy is not a straightforward task. Identity theft,which occurs when an impostor uses a legitimate user’sidentifying information without his/her consent, is becom-ing one of the biggest concerns for organisations offeringservices on the Internet.Many solutions have been proposed in the last few yearsto address the threat of identity theft, and to tackle identity-oriented attacks such as phishing and pharming. Most ofthose solutions are based on the concept of Identity Feder-ation (different identities that belong to the same user in aparticular trust domain are “federated”), and Single Sign-On(where a user performs an authentication process only oncein a single working session).Recently, Microsoft has proposed a new identity man-agement framework named CardSpace. CardSpace hassome similarities to other identity federation systems; how-ever it is not a single sign-on system. CardSpace is designedto reduce the reliance on passwords for Internet user authen-tication by service providers, and to improve the privacy ofpersonal information.In this paper we identify significant security and privacyissues in the CardSpace scheme. We focus on two partic-ular security problems, namely the reliance by the systemon Internet user judgements of the trustworthiness of ser-vice providers, and the dependency on a single layer of userauthentication with the Identity Provider. In this paper wepropose a solution for these two problems, using the con-cept of Secured from Identity Theft (SIT) attributes [2], andzero-knowledge cryptographic techniques.The remainder of this paper is organised as follows. Insection 2 we provide a brief overview of the CardSpaceframework. In section 3 we describe two security flaws inCardSpace. In section 4 we propose a solution for the se-curity problems discussed in section 3, and in section 5 asecurity and performance analysis of the proposed solutionis given. Section 6 concludes the paper.2 Microsoft CardSpaceIn this section we provide a brief overview of CardSpace.We then describe the CardSpace framework and messageflow.2.1 An OverviewCardSpace is the name for a Microsoft WinFX set ofsoftware components that form an identity managementsystem or an identity metasystem, since it is a system ofsystems. This identity metasystem is designed to complywith the Laws of Identity promulgated by Microsoft1.Digital identities in CardSpace are represented as claimsmade by one digital subject (e.g. an Internet user) aboutitself or another digital subject. A claim is an assertionthat certain identifying information (e.g. given name, SSN,credit card number, etc.) belongs to a given digital subject[3]. According to this definition, identifiers (e.g. username)1and attributes (e.g. user gender) are both treated as claimswithin the identity metasystem.CardSpace can be integrated with Microsoft WindowsXP and Internet Explorer version 7 (a toolkit is freely avail-able from Microsoft), and has been distributed with Win-dows Vista. Since CardSpace is an “open” XML-basedframework, CardSpace plug-ins for browsers other than Mi-crosoft Internet Explorer can also be developed, such as theFirefox Plug-in.22.2 The CardSpace FrameworkThe CardSpace framework is based on the identificationprocess we experience in the real world using physical iden-tification cards. Within the CardSpace framework, an iden-tity provider issues Internet users with virtual cards calledInfoCards, that hold non-sensitive meta-information relatedto them. Subsequently, the Internet users can use their In-foCards to identify themselves to any service provider (orrelying party) who trusts the identity provider that issuedthe InfoCards. InfoCards can also be self-issued by the In-ternet users themselves.Figure 1. CardSpace Framework.Figure 2 provides a simplified sketch of the CardSpaceframework. In the figure it is assumed that the user hasalready been issued an InfoCard by the identity provider(henceforth abbreviated to IdP). In step 1, the CardSpace-enabled user agent or the Service Requestor (henceforthabbreviated to CEUA), which is essentially a CardSpace-enabled web browser, requests a service from the relyingparty or service provider (henceforth abbreviated to RP).In step 2, the RP identifies itself using a public key certifi-cate (e.g. a certificate used for SSL/TLS), and declares itselfas a CardSpace-enabled RP using XHTML code or HTML1http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx2http://xmldap.blogspot.com/2006/05/firefox-identity-selector.htmlobject tags. After recognising that the RP is CardSpace-enabled, the CEUA retrieves the RP security policy in step3. This policy contains a list of the claims that must beasserted about the Internet user (henceforth abbreviated touser) in order for this user to be granted the service, theIdPs that are trusted to make such assertions, and the typesof security token holding the assertions that are acceptableto the RP. The security policy also specifies requirementsthat must be met by the retrieved security token (e.g. thetype of proof key and the maximum token age). It is impor-tant to emphasise here that CardSpace identity metasystemdoes not demand specific types of tokens; any token typecan be used within the framework.In step 4 the CEUA matches the RP’s security policywith the InfoCards
View Full Document
Unlocking...