Phases of Identity and Corresponding Identity Theft Protection Mechanisms

Liberty Alliance Project   Home  ·  Calendar  ·  Docs  ·  Wiki  · Mail Archives  ·  Events  ·  Polls  ·  Bugzilla  ·   Help   ·

Phases of Identity and Corresponding Identity Theft Protection Mechanisms From Liberty Alliance Member Wiki Jump to: navigation, search

5. Technology Solutions and Tools for Identity Theft Prevention

Figure 2

Figure 2 identifies the technical areas which can be exploited to provide protection against identity theft. A brief description each is given in the following. In Section 6 we describe how these techniques can be applied in each phase of the identity in a federated identity management system.

5.1 Policy Languages

One of the main types of policy is regarding the privacy preferences of the user and the other federation entities alike. Typically privacy policies state who the recipients will be for the user data, the purpose for which this data will be used, and how long the data will be retained. Data in a privacy policy can be represented at different levels of granularity. They can refer to aggregate data, or they can refer to more specific piece of information, such as, last name or social security number. A privacy policy infrastructure will provide to individuals the necessary control over their information, as well as allow the business collecting, using, and potentially sharing that information, to ensure that they abide by appropriate regulatory requirements regarding such data. For the discussion of the different aspects of privacy policy infrastructure and the applicability of various XML-based policy languages to these different aspects please refer to the linked paper . They show how the Liberty's ID-WSF specifications can be applied to the exchange of privacy policy information between principals (specifically, the data subject, the data custodian and the data requester). We describe 2 specific examples of privacy policies as follows:

5.1.1 P3P A P3P privacy policy is specified by one policy element that includes the following major elements: entity, access, extension, and statement. The entity element identifies the legal entity making the representation of privacy practices contained in the policy. The access element indicates whether the site allows users to access the various kind of information collected about them. The extension is an optional element describing a website's self defined extension to the P3P specification. One or more statement elements are defined in a policy. A statement is the core of the policy as it defines the data and the data categories collected by the site, as well as the purposes, recipients and retention of that data. Each statement contain the following: • data denotes a data element. In P3P each DATA element has a set of categories associated with it. Some categories are implicitly specified by the base P3P data schema whereas some others are defined by the policy itself; • purp denotes purposes for data processing; • purpose element assumes on or more pre-defined value in current, admin, tailoring, pseudo-analysis. • retention denotes the type of retention and assumes values in no-retention, stated-purpose, legal-requirement, business-practice, indefinitely according to the P3P standard taxonomy; • recipient is the legal entity, or domain, beyond the service provider and its agents where data may be distributed; recipient can assume one value in ours, legal, delivery, unrelated, ….;

Consider the following P3P policy:

 <STATEMENT>
   <PURPOSE>
    <individual-decision required=
     "opt-out"/> </PURPOSE>
   <RECIPIENT><ours/></RECIPIENT>
   <RETENTION><stated-purpose/>
   </RETENTION>
   <DATA-GROUP>
     <DATA ref="#user.name.given"/>
     <DATA ref="#dynamic.cookies">
       <CATEGORIES><preference/>
        <uniqueid/>
       </CATEGORIES>
     </DATA>
   </DATA-GROUP>
 </STATEMENT>

Since P3P has not been specifically conceived for negotiations within federation, its syntax include data elements that are not of interest to trust negotiations, such as click-stream. In the following, we always limit our analysis to elements having a corresponding concept in our reference ontology. Such data elements can then be used to evaluate privacy concepts.

5.1.2 SAML Assertions: The Security Assertion Markup Language (SAML) , is an XML standard for exchanging authentication and authorization data between security domains, that is, between an identity provider and a service provider. SAML supports the specification of assertions about a subject that can be shared with other applications across system domain boundaries. It allows an entity to make assertions regarding the identity, attributes, and entitlements of a subject or a user to other entities. In a federation system, these assertions are usually transferred from IdP's to SP's. Assertions contain statements that SP's use to make access control decisions. There are three main statements provided by SAML:

 1) Authentication statements: Such a statement asserts to the SP that the principal did indeed authenticate with the IdP at a particular time using a particular method of authentication.
 2) Attribute statements: Such a statement asserts that the specified subject is associated with the supplied attributes.
 3) Authorization decision statements: Such a statement specifies that a given subject has been allowed or denied access to a given resource.

SAML is extensively used for access control information exchange by most of the federated identity management initiatives.

5.1.3 XACML Authorization Policy XACML provides a policy language which allows administrators to define the access control requirements for their application resources. The language and schema support include data types, functions, and combining logic which allow complex (or simple) rules to be defined. XACML also includes an access decision language used to represent the runtime request for a resource. When a policy is located which protects a resource, functions compare attributes in the request against attributes contained in the policy rules ultimately yielding a permit or deny decision. When a client makes a resource request upon a server, the entity charged with access control by enforcing authorization is called the Policy Enforcement Point. In order to enforce policy, this entity will formalize attributes describing the requester at the Policy Information Point and delegate the authorization decision to the Policy Decision Point. Applicable policies are located in a policy store and evaluated at the Policy Decision Point, which then returns the authorization decision. Using this information, the Policy Enforcement Point can deliver the appropriate response to the client.

5.2 Cryptographic Tools

5.2.1 Secret Splitting RSA Laboratories' product Nightingale \cite{rsanight} implements a secret-splitting technology, which is designed to be integrated into application software as a server module for the back-end of any network. Secret splitting is a cryptographic technique that breaks a piece of data into two components. Learning one of these components reveals no information about the original data. Using secret-splitting the sensitive data is cryptographically distributed across two locations – the Nightingale module/server and an application server thus avoiding a single point of failure. The secret data can be of three types: (1) user authentication data like SSN, passwords; (2) business data like customer records and their CCN; (3) the cryptographic keys themselves. Nightingale can thus be used to mitigate identity theft by making it hard to retrieve the stored user information.

5.2.2 Zero Knowledge Proofs In cryptography, a zero-knowledge proof or zero-knowledge protocol is an interactive method for one party to prove to another that a (usually mathematical) statement is true, without revealing anything other than the veracity of the statement.

A zero-knowledge proof must satisfy three properties:

 1. Completeness: if the statement is true, the honest verifier (that is, one following the protocol properly) will be convinced of this fact by an honest prover.
 2. Soundness: if the statement is false, no cheating prover can convince the honest verifier that it is true, except with some small probability.
 3. Zero-knowledge: if the statement is true, no cheating verifier learns anything other than this fact. This is formalized by showing that every cheating verifier has some simulator that, given only the statement to be proven (and no access to the prover), can produce a transcript that "looks like" an interaction between the honest prover and the cheating verifier.

The first two of these are properties of more general interactive proof systems. The third is what makes the proof zero-knowledge.

Research in zero-knowledge proofs has been motivated by authentication systems where one party wants to prove its identity to a second party via some secret information (such as a password) but doesn't want the second party to learn anything about this secret. This is called a "zero-knowledge proof of knowledge". However, a password is typically too small or insufficiently random to be used in many schemes for zero-knowledge proofs of knowledge. A zero-knowledge password proof is a special kind of zero-knowledge proof of knowledge that addresses the limited size of passwords.

5.2.3 Anonymous Credentials In anonymous credential systems, organizations know the users only by pseudonyms. Different pseudonyms of the same user cannot be linked. Yet, an organization can issue a credential to a pseudonym, and the corresponding user can prove possession of this credential to another organization (who knows her by a different pseudonym), without revealing anything more than the fact that she owns such a credential . The main idea regarding use of pseudonyms in IdM systems is in that ``the identity provider generates an opaque handle that serves as the name identifier the service provider and the identity provider use in referring to the user when communicating with each other \cite{libertydoc}. Rudimentary non-linkability is achieved, since an outside observer cannot infer any information about the actual user based on the random session based opaque handles. The first approach that proposed to replace user identifiers by pseudonyms is by Chaum ; the key idea was to use one time pseudonyms for a series of transactions to provide unlinkability among different transactions with organizations, yet at the same time transfer certified attributes among these organizations.

Selective disclosure is often associated with anonymous credentials. The key aim of selective disclosure is to allow the individual to control the dissemination of personal information. An anonymous credential system introduced by Chaum is one of the most well known starting points of such a system. Selective disclosure is just one of the many properties of such systems. In the industry there are 2 known implementation of anonymous credential systems— 1. IBM's Idemix [Project Lead -- Jan Camenisch] The main paper explaining the main concepts and crypto details of the idemix system -- "An Efficient System for Non-transferable Anonymous Credentials with Optional Anonymity Revocation" 2. Credentica [Project Lead -- Stefan Brands] Whitepapers on selective disclosure and digital credential concepts are given provided here .

5.3 Trust Management

Trust management, introduced in the PolicyMaker system, is a unified approach to specifying and interpreting security policies, credentials, and relationships; it allows direct authorization of security-critical actions. A trust-management system provides standard, general-purpose mechanisms for specifying application security policies and credentials. Trust-management credentials describe a specific delegation of trust and subsume the role of public key certificates; unlike traditional certificates, which bind keys to names, credentials can bind keys directly to the authorization to perform specific tasks.

A trust-management system has five basic components:

• A language for describing `actions', which are operations with security consequences that are to be controlled by the system. • A mechanism for identifying `principals', which are entities that can be authorized to perform actions. • A language for specifying application `policies', which govern the actions that principals are authorized to perform. • A language for specifying `credentials', which allow principals to delegate authorization to other principals. • A `compliance checker', which provides a service to applications for determining how an action requested by principals should be handled, given a policy and a set of credentials.

The trust-management approach has a number of advantages over other mechanisms for specifying and controlling authorization, especially when security policy is distributed over a network or is otherwise decentralized.

5.3.1 Anti Phishing Tools Phishing is the act of sending an e-mail to a user falsely claiming to be an established legitimate enterprise in an attempt to scam the user into surrendering private information that will be used for identity theft . Several anti-phishing tools are being developed for example Yahoo Seal where the basis of the antiphishing service is a Yahoo sign-in seal that will be associated with an individual computer; users will need to install it on every computer they use. Once installed, the seal will appear on Yahoo sign-in screens, letting visitors know that the site is genuine.

5.4 Database Security Database security can be divided into the following key points of interest.

• Server Security • Database Connections • Table Access Control • Restricting Database Access Retrieved from "https://members.projectliberty.org/wiki/index.php/Phases_of_Identity_and_Corresponding_Identity_Theft_Protection_Mechanisms" Views

   * Article
   * Discussion
   * Edit
   * History
   * Protect
   * Delete
   * Move
   * Watch

Personal tools

   * Brett@projectliberty.org
   * My talk
   * My preferences
   * My watchlist
   * My contributions
   * Log out

Navigation

   * Wiki Main Page
   * Brussels Plenary
   * Recent changes
   * Coordinating Editors
   * Standards Liason
   * SAEG
   * EGov
   * Open Mike
   * Discussions
   * Help
   * Back to Members Area

Search

Toolbox

   * What links here
   * Related changes
   * Upload file
   * Special pages
   * Printable version
   * Permanent link

Powered by MediaWiki

   * This page was last modified 05:27, 15 February 2007.
   * This page has been accessed 5 times.
   * Privacy policy
   * About Liberty Alliance Member Wiki
   * Disclaimers