Posts Tagged Authentication
A Radical New Approach to (MUTUAL) Authentication
Posted by Eashwar Ganapathy in Uncategorized on May 19th, 2009
[This thought paper is from Rel-ID Technologies Inc. - a Uniken venture]
Authors Sanjay Deshpande, Dr. Pat Shankar, Eashwar Ganapathy
Abstract In this article, we present a fundamentally new identity framework – RELATIVE IDENTITY - which addresses and eliminates many of the core problems faced by the current identity technologies. We postulate that authentication necessarily has to be mutual and that the only valid way to perform mutual authentication is to make fundamental changes to the identity representation framework.
This can be accomplished by –
- Changing from end-point entity labeling (like in the case of login/password, biometric, digital certificates, 2-Way SSL and a combination of these) – to labeling the relationship between the end-point entities (which inherently covers the two end-points in its definition)
- Making the authentication protocol truly mutual – and thereby eliminating the susceptibility to man-in-the-middle attacks and phishing
Identity and identification are central to any interaction, both in real and virtual (digital) systems. Especially where the interaction entails access to or manipulation of protected resource(s).
We firmly believe that any identity framework has to address the problem of establishing a mutually-authenticated secure connection BEFORE initiating any data transaction using that connection.
Introduction Identity and Authentication form the central building block of any information security solution/framework. Establishing identity using an authentication protocol is the starting point for any secure transaction. In order to be able to establish identity (be it man or machine), the entity must be characterized by a unique set of symbols (as per the adopted identity representation framework). During the process of actually identifying / authenticating the entity, the same characteristics of the entity are observed and matched against those that were captured earlier and associated with the entity.
The act of establishing identity is identification. Identity Systems must possess the capability represent, provide, maintain and establish identity. The identity representation framework must ensure that it is extremely difficult to compromise the individual identities it is used to represent. In this article we cover the following points:
- Definition of RELative IDentity – the representation
- Fundamental properties of identity (representation)
- Proof that all authentication must necessarily be mutual ( that 1-way authentication basically flawed)
- Fundamental properties of authentication / identification (the process of)
- How is Relative Identity different from other identity schemes
The basic flaws and limitations in current identity technologies for websites prevalent in the World Wide Web SSL/Digital Certificates (when used for AUTHENTICATION) become apparent in the context of the axiomatic frame of reference defined in the following sections.
Definition of Relative Identity The relative identity of an entity is
- Distributed among the relationship of this entity with other entities. Each such valid relationship –
- constitutes a unit “Relative Identity” – an important and inseparable constituent of the identities of each of the entities sharing a valid relationship
- contributes in the definition of the relative identity of each entity
- exists only in the context of two (or more) entities who share a relationship
- Is the union/collection of all such “Relative Identities”
- Is dynamic since new relationships may be established, while old relationships may be discarded, over time
- Is associated with a set of labels/attributes/characteristics – immutable and mutable
- immutable - such as biometrics, which cannot be changed at will
- mutable - such as SSN which are awarded for a life time, log in passwords, bank account numbers which are changed quite often
In practical implementations of identity based transactions, one is concerned only with the specific (relevant) relative identity and associated attributes, and hence the rest of the identity representation is not susceptible to identity theft.
As is evident from the above definition, the concept of identity in the prevalent conventional identity systems that deal with only labels/attributes/characteristics – “What you have”, “What you know” and “What you are”, totally ignore the most relevant concept of “Who you know” – which is how humans establish trusted relationships.
Fundamental Properties of Relative Identity
The unit relative-identity data -
- must be unique (no two relative-identities should have the same identity data)
- must be tamper-proof (difficult to reconstruct and reproduce)
- must be secret - wholly / partially (should not be communicated in full form during authentication; should be known only to the related entities)
- must be used simultaneously and uniquely, to identity all entities involved in the authentication transaction
Most of the prevalent conventional identity systems satisfy properties 1, 2 and 3 above. For example -
- Login/Password would satisfy 1, 2 (partially) and 3 (partially)
- Digital Certificates would satisfy 1, 2 and 3 (partially)
What is Mutual Authentication/Identification? Why does one need it?
As yourself the following questions -
- what is the meaning of authentication if it is not mutual?
- why would I allow someone to authenticate me, if I can’t authenticate him/her?
- would I produce my passport to identify myself to someone who does not (even seemingly) possess the requisite authority?
- Even so, don’t I run the risk of being duped into producing my passport to a person who only looks authentically like he/she has the requisite authority?
The basic flaw in identification over the internet is that an end-user assumes that the website challenging him/her for his/her credentials is indeed the authentic site – so long as interaction with the user-agent application (the web-browser) while accessing the website, is identical to previous such interactions. That is to say – so long as the website looks the same, behaves the same, and does not trigger a negative message from installed security products (due to more recent efforts in the anti-phishing features of these products).
All things considered, are you sure you can trust such a website that asks for your login credentials?
Conclusion: Authentication, to be of any practical use, MUST BE MUTUAL
Fundamental properties of authentication / identification
The process for identification / authentication
- must be tightly integrated with a given/underlying identity representation
- must necessarily have a priori access to the identity data that is to be identified / authenticated
- must necessarily authenticate all identifying/authenticating parties (entities) – preferably simultaneously
These are simple (minimal) properties that any identity/authentication system must possess. Some of them are straightforward while some may not be seem obvious.
Let us now visit some of the prevalent identification/authentication processes in light of the above properties -
- Login/Password – satisfies 1 and 2 above
- Digital Certifications/SSL – does not satisfy 2 and 3, and hence, should NOT be used for authentication
- Hardware/Software Tokens (and OTPs) – satisfy 1 and 2 but do not satisfy 3
Please note that even the use of multi-factors satisfy only properties 1 and 2 and not the property 3
Let us look at the third property above for authentication protocols that essentially says that - the process MUST be mutual and simultaneous. The term mutual has earlier been defined in the context of client-server architecture as “client must authenticate the server and the server must authenticate the client”. Such a definition classifies any “1-way” authentication method executed twice as a valid 2-WAY or mutual authentication process. The fundamental flaws in existing mutual and 1-Way authentication systems are precisely due to the violation of properties (2) and (3) above.
Mutual authentication cannot and should not be implemented using two 1-WAY authentication schemes – e.g. 2-Way SSL, or a combination of login/password and shared secrets/site-key. Any such scheme will be vulnerable to the same attacks that the 1-WAY equivalent is vulnerable to. For example, 2-WAY SSL is susceptible to MITM (man-in-the-middle) in exactly the same way that 1-WAY SSL is - for the same reasons.
How is Relative Identity different from other identity schemes?
Conventionally, identity is associated with the end-point entities (client or server) and authentication involved authenticating the end-points. Authenticating this information for both end-points in sequence is NOT secure mutual authentication – it is a concatenation of 2 instances of 1-WAY authentication.
The REL-ID (relative identity) approach to authentication is to identify and authenticate the ‘link/relationship’ between the end-point entities – not the individual end-points. That is to say – IDENTITY must necessarily be associated with the ‘link’ representing the relationship between the end-points. This is the only representation, and authentication thereof, that can legitimately be termed as MUTUAL – as the end-points are an integral part of the definition of any such representation.
Authenticating such a ‘link’ would necessarily be mutual – would ensure that all end-points are authenticated simultaneously, and makes the identity of every end-point relative to the other end-point(s) axiomatically.

Conventional Identity System

Relative-Identity System
We believe that, in order to (a) represent the above information correctly at the end-points and (b) arrive at the correct protocols for identification/authentication, one must develop the necessary mathematical frameworks and algorithms. However, before starting to derive them, one must accept and acknowledge the fundamental paradigm shift in the desired properties of such representations and algorithms.
The set of identity representations and identification/authentication algorithms constituting the REL-ID© Security Suite is one such implementation of the identity paradigm described here. Assuming that authentication must necessarily be mutual and simultaneous to be of any value, authentication schemes such as tokens, digital-certificates/SSL, login/password… cannot be compared with REL-ID – since they offer only 1-WAY authentication, at best. Furthermore, methods/products that claim to provide mutual authentication, but in reality implement two 1-WAY authentications (like SITE-KEY – flash-persistent object; Shared Secrets…), will remain vulnerable to man-in-the-middle attacks due to the inherent vulnerability in the conventional end-point identity representation scheme.
There are no known contemporary technologies/products that are built using mutual authentication protocols, which have the properties mentioned in this article, and which are available commercially.
Website Identity - the root cause for Internet Fraud
Posted by Eashwar Ganapathy in Uncategorized on May 14th, 2009
[This thought paper is from Rel-ID Technologies Inc. - a Uniken venture]
Authors Sanjay Deshpande, Dr. Pat Shankar, Eashwar Ganapathy
Abstract On the internet there are 2 types of websites - ones that take sensitive information from you and ones that don’t. Online banking applications, shopping applications, stock-trading applications are examples of the former; while CNN, Google etc are examples of the latter. This article deals with the very real insecurities of working with applications of the former variety.
How do you know that you are at an authentic website? What if you are not?
Authenticating a website implicitly assumes you already know what to look for in the website, in order to establish the websites identity - which in turn implicitly assumes you know what constitutes the identity of a website. Let us define WEBSITE IDENTITY to be a set of identifiers that can be authenticated to prove the identity of the website. Currently, there are only 3 identifiers that constitute WEBSITE IDENTITY - (1) URL, (2) CONTENT, and (3) SSL/TLS CERTIFICATE. Furthermore, let us note that - any kind of authentication of any identity mandatorily requires a priori knowledge of the identity information.
In this article we shall delve deeper into the above constituents of WEBSITE IDENTITY, and conclusively prove that they are fundamentally incomplete, leaving you - the internet-user, at the mercy of fraudsters who use this knowledge to their benefits, by sending fraudulent emails with links to similar looking websites.
The Website URL - when one sets up a website the first thing one does is to register the domain name (www.mywebsite.com) - that is the primary identifier for the website. More often than not, this is the ONLY identifier - for first-time visitors.
Let us say the website’s domain name is communicated to you by the owner of the website directly/indirectly through trusted channels. In this case, since the identity information for the website has been communicated from a trusted source, the problem of authenticating the website reduces to authenticating the identifier - ensuring that the website you are visiting is authentic.
What if the website’s domain name is communicated to you through channels that you cannot necessarily trust - the first question that arises is how would you know for sure that this identifier indeed belongs to the correct website.
For example, let us assume you are a customer of Bank of America. How would you know for sure that www.bankofamerica.com is the correct website if it has not been communicated to you by the bank? What if someone told you or you searched on the internet and got the website name to be www.boa.com instead, what would you do?
Do you know how to confirm the ownership of a given URL/Domain Name before using it? Further, even if the OWNER (let’s say the bank in this case) told you what to check (assuming there was a way to get this information) - if you have not received the information from a TRUSTED source, how do you verify that the information is correct?
NOTE that the DOMAIN REGISTRATION entities (companies that issue the domain name) do not verify the information provided by the individual who is registering the domain (website address).
NOTE that there is no central TRUSTED repository where you can find the WEBSITE NAME for a given OWNER. There are services like www.who.is – that give you information about who has registered the DOMAIN. However, since the domain registration entities do not authenticate or validate the owner of the website name – which means any one can register any name and own it – what use is this information anyway!
Website Content - Let us move on to the next identifier of the website – the content. Most users confirm the authenticity of the website based on just the visual cues and verifying the visual cues every time they visit the website.
The very nature of HTTP and HTML (the protocol and language used to retrieve and render website content, respectively) allows one to stream information/content from multiple sources. Which means, even if the visual cues are the same, how do you confirm the validity of the content - what if someone has tampered the content and/or it is being served from somewhere else? Further, if you are visiting the website for the first time – and the owner has NEVER communicated what the website should look like in the first place, how would you authenticate the website’s content?
The website content – the HTML document - is available for any one to view, copy and save. It is a trivial task to scrape content off an authentic website (using a browser or wget or website copiers such as HTTrack etc), register a similar (but not identical) website, and put up the same content there - a COUNTERFEIT WEBSITE.
Let us say there are 2 URLs A and B that are displaying contents Ca and Cb - each implying that the website belongs to the same company X. If the company X has not communicated the correct URL(s) to its users - how would you confirm that the URL you are browsing (A/B) indeed belongs to the company X? If you conclude incorrectly, you could end up providing valuable information to a counterfeit / fraudulent website!
Digital Certificates - By far the most popular method of registering, certifying and verifying identity on internet.
The anti-trust laws in this part of the business world are laughable - to become a valid certification authority one just has to be affiliated to the company called VERISIGN directly or indirectly - isn’t this a fundamental violation of the anti-trust laws? VERISIGN (www.verisign.com) is neither a government nor an international body.
If you navigate to www.patentoffice.nic.in, the official website of India’s Patent Office and visit their e-filing section, most browsers say this could be a fraudulent website - because the certificate is not issued by VERISIGN or any of its affiliated certification authorities (it is issued by a company called NCODE SOLUTIONS - one of the valid root certificate authorities in India). Not just that, the address-bar turns RED.
Who decided that one has to trust VERISIGN? And why does that mean one has to trust all certification authorities certified by VERISIGN? Most consumers do not even know VERISIGN - MicroSoft, maybe, but not VERISIGN. In their defence - given the fundamental flaw with the Certification Authority scheme - there really was no solution but to pick up a bunch of ‘root CAs’ and declare them as the TRUSTED AUTHORITY.
An end-user has no A PRIORI knowledge of the certificate issued to an entity. The transaction (or act) of getting a certificate is a private transaction between the entity (for eg. a bank) and the CA (Certification Authority). This information is never distributed to the end-user and he/she in turn is in no way equipped to verify this information. How can a 3rd party (the CA) vouch for the authenticity of an entity to the end-user? Does it make sense for a child to ask a visitor (a stranger) to vouch for the authenticity of his/her mother? But that is what it is. Why is there a necessity for a 3rd party like VERISIGN (or its derivative CAs) to verify the identity between 2 parties who already share a primary relationship (like bank-customer or enterprise-employee …)?
The original premise of the SSL protocol (that uses these certificates) was to establish an encrypted communication channel between two UNTRUSTED parties. What completely defies logic is - what good would an encrypted channel be between two UNTRUSTED parties?!
Banks and other e-commerce websites boldly declare that they are secure - they have SSL/TLS enabled websites. What good is it when the user does not know what to verify? He/She does not have a-priori knowledge of the information that should be present in the website’s certificate - such as the signed content, the public-key in use etc.
The CA infrastructure and the current SSL protocol violate the basic principles of IDENTITY and AUTHENTICATION - that IDENTITY must be established first and then verified between 2 (now) trusted parties - using information shared during IDENTITY ESTABLISHMENT.
The above discussion conclusively proves that the three primary identifiers – WEBSITE URL, CONTENT and (optionally) PKI-based CERTIFICATES are incomplete as website identifiers. They leave the user at the mercy of fraudsters who use this knowledge to their benefit - sending fraudulent emails with links of similar looking counterfeit websites, luring the ignorant users to divulge sensitive information to the wrong websites.

Recent Comments