Distributed Identity Based on Relationships

From IIW

Conference Notes_iiw8 Room/Time: 1/C

Convener: Pat Sankar, Rel-ID Technologies

Notes-taker:

Attendees: Ariel Gordon, Ben Sapior, Hank Mantchin, Eric Darghi, Jeff(Jeffrey) Shaw and Mary Ruddy

Technology Discussed/Considered:

The current Identity representation based on what you know, what you have and what you are is inadequate. This label based identity can be easily stolen or compromised. Hacking attacks such as phishing and pharming, man in the middle attack, man in the browser attack, replay attack , attacks by viruses and Trojans are the reason for compromising identity. (not considering stupid mistakes by users giving away their identity)

Distributed Identity is based on a new paradigm on who you know, in addition to what you know, what you have and what you are. This is how trusted identity is established in the real world.

Digital certificates, multi factor token, site-key images, soft-key pads do not provide the security that they are claimed to provide. The most effective way to protect identity theft from the above mentioned attacks is through mutual authentication.

In distributed/relative identity we ID the link/relationship and split it (mathematically) in to two or more parts. The mathematical is known as the Distributed Identity Graph (DIG).

REL-ID prevents phishing and pharming, man in the middle attack, man in the browser attack, replay attack , attacks by viruses and Trojans. The properties of REL-ID are:

  • 2-WAY (or split) IDENTITY REPRESENTATION
  • 2-WAY AUTHENTICATION PROTOCOL
  • ZERO-POSSESS
  • ZERO-TRANSMIT
  • MULTI-IDENTITY (server side)
  • MULTI-IDENTITY (client side)
  • MULTI-FACTOR
  • DYNAMIC IDENTITY (one time use)

REL-ID properties and deployment are consistent and compatible with the requirements of Kim Cameron’s Seven Basic Laws of Identity.

REL-ID product suite:

TruSite: A Website Authentication Product Automatically checks the websites’ identity for the end-user Form factors include – IE Toolbar, FireFox Toolbar

TruTerm: Secure Branded Online Banking Terminal Secure banking terminal with in-built multi-factor, mutual authentication Protects against all known attacks on Internet Banking

TruAccess: Corporate ExtraNet An EXTRANET landing platform for providing access to enterprise applications

TruNet: Corporate VPN/Secure Internet Access Point A VPN solution for providing access to enterprise network resources

TruMessage: Secure Corporate Messaging A Secure Enterprise eMail solution that removes all security vulnerabilities in the current eMail infrastructure

httpr:// Instead of or in addition to https://

Future plan for federated identity, Multi Level Security

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Key Understandings

  • Use of relationships of links in addition to labels/attributes
  • Identity is inherently distributed in terms of high value relationships
  • We are really protecting the relationship and not just the label based identity part.
  • Even if one link is compromised, the other links are operative
  • In order to spoof the bank one needs to steal a million split identities of the customers, and at the same time keep pace with the dynamic changing identity in each case.

Outstanding Questions:

Why do call mutual authentication as a piece of identity? Why not call it just authentication? This was the problem of separating authentication as part of the identity representation that led to the current limitation. Each relationship link (authentication is just a means for validating it) is a piece of the identity in the distributed identity paradigm.

How do you generate keys? What about revocation? The keys are generated similar to the RSA algorithm and the secure communication is similar to Diffie Hellman algorithm. However, the REL_ID keys are not limited like the PKI keys. The practically unlimited equal to the number of atoms. Revocation is not needed since there is no practical limit on the leys, and hence there is no need to revoke and reuse. Each party can stop a relationship (terminate a REL-ID) transaction at any time. The client and the bank are on equal footing. However, to create a REL-ID they need to follow a process and establish a prior trust.

How is the REL-ID split identity generated? What is the Z-ID server tries to keep a copy of the client piece of the split identity. The Z-ID server is implanted behind the de-militarized zone of the bank so that when it generates a split ID (Rel-id) it keeps the bank’s part and sends the customer’s part. BY policy it is not allowed to keep the hashed version of the customer’s part. In the current PKI implementation, that is the biggest weakness. Though the private keys are not supposed to be kept, they are kept by the server, so as to be re-used when the keys are revoked. In REL-ID implementation, since practically there is an unlimited number of REL-ID keys available, there is no need for key revocation, and hence there is no need to keep the client part. Even if the worst scenario if it is kept, it may be practically useless, because the REL-ID keys change with every authentication. With millions of customers with thousands of transactions, the need to manage billions of keys by itself becomes nightmare, simply not worth the trouble.

Observations/Suggestions:

If possible do not propose httpr://, instead hide it under https://

REL-ID may very relevant for Active cards vendors. Talk to them.

Action Items:

Arrange another session to demo REL-ID and answer further questions

Retrieved from "https://iiw.idcommons.net/index.php?title=Distributed_Identity_Based_on_Relationships&oldid=977"