GB2478753A

GB2478753A - Authenticated challenge/response scheme with encrypted time-stamped ID/role messages exchanged and validated by certifying authority

Info

Publication number: GB2478753A
Application number: GB1004391A
Authority: GB
Inventors: Janusz Adamson; Andrew Churchill
Original assignee: Individual
Current assignee: Individual
Priority date: 2010-03-17
Filing date: 2010-03-17
Publication date: 2011-09-21
Also published as: GB201004391D0

Abstract

The invention proposes a `real-time ID' comprising a root ID (eg. based on passport information), a persona/role/attribute (eg. police officer) and a timestamp. The real time ID is encrypted and combined with a plain text request for information into a challenge transmitted from a requesting party 9 to a providing party 10, who forwards it to a certifying authority/authentication broker 11. The certifying authority decrypts the real time ID and validates whether the requestor is authorised to make the request. If allowable the certifying authority responds with a real time ID and the requested data, recovered from secure data depositories. Example uses are bar staff requesting proof of age, customs officials requesting travel details. The real time ID may be displayed as a 2D barcode (see Figs. 1 and 2).

Description

Generating an individual's real-time ID

DESCRIPTION

The invention describes a system that uses a handset-based mobile device (e.g. smart phone, i-pod, blackberry, palm-held computer) for providing an individual's real-time root identity assignment that is only created and presented at the point of requirement. This is ephemeral data that has no value subsequent to its generation and one-time use.

For in-Country nationals, this will be a unique real-time ID and will be an encrypted minimum 24 digit figure consisting of an 11 digit Root Identity, followed by a 3 or more digit persona and digit time stamp.

The key claim within Real time ID, however, is that the identity is only established at the pointitime of requirement, making it a unique bridge between the authonsed request (requesting party) and the identity claimant (providing party/individual).

The claimant (providing party/individual) has no need to be aware of their root identity number, as it will never be required to be presented, but will need to be aware of which persona the individual wishes to verify. The individual merely needs a device capable of calculating the necessary verification of their identity at any given time and the secondary ability to relay this information to the requesting party.

The principle is based on there being a root identity assigned to an individual, and that the individual can then adopt persona with which to make assertions, enabling them to provide tailored business cards' enabling pseudonymity, whilst also enabling authorised bodies (such as law enforcement, port security, medical staff, bar staff etcetera) to have a challenge persona associated with their status providing the requisite information that they are permitted to request with no additional superfluous information.

Therefore, if a police officer was to request ID from an individual then the challenge response would be initiated by the officer with a validated request under, say, persona 999, with name, address, and other pertinent information. In the case of freight movement into/out of a port, the challenge response would be initiated by port gate security with a validated request, say persona 211, for the vehicle driver's name, booking reference, and other pertinent information such as HGV details and freight documentation, etcetera. However, should a challenge be issued by bar staff under, say persona 456, the information provided would be a yes/no answer to the question of being over 18.

For an exemplar of overseas visitors entering Country at an immigration gateway (e.g. airport, seaport) for business, pleasure, etc., should the visit be in connection with an event such as London 2012, the root identity of the visitor would be the country code, passport number and biometric data, and the persona would be the 2012 (digital) ticket The data [7], could be displayed as a block grid [6], and used to provide access to various events, and help prevent ticket touting.

The root identity, combined with the persona would therefore provide only the information required (in line with Kim Cameron's laws of Identity) and an audit trail of the request would be created in the form of the unique real time identity (whether manifesting as a numerical string or an image).

The principle behind the real time nature of Identity under this model holds true regardless of the precise numbers used, but for ease of illustration and to demonstrate the feasibility of the system we use the example of our current 240 block grid [6&7], being an 8 by 30 display, giving 2240 possible variants. This figure is sufficient to build in vast redundancy, and were there to be 100 billion root identities (i.e. people) enrolled, and giving the opportunity for 1000 personae (i.e. 500 claims and 500 role based authorisations), and with real time ID operating each second (all these are clearly excessive assumptions, but are made to illustrate the viability) the following chances of collision are raised.

With 100 billion root identities and 1000 personae giving 100 trillion claims, there are 100 trillion possible valid results every second, enabling an attacker with full access to data to attempt to find a collision of a given string/image at a rate of 100 trillion per second.

Fortunately, however, with only' 100 trillion valid results (being that person a with persona b at time c's identity collides with person x with persona y at time z) then with a given string/image the chance of a collision within the next century would be one in iü°. Had the system been put in place at the time of the Big Bang, the chance of a collision having occurred at some point to date would rise to one in 1 Embodiments of the present invention will now be described with accompanying figures, by way of an example/illustration, with reference to a deployment.

When an authonsed/requesting party requests ID credentials [8, 9] they issue a challenge consisting of a simple timestamp, encrypted under the key relating to their own claim.

Therefore a challenge relating to I am a police/security officer and want your ID is sent in plain text accompanying a cipher text containing the timestamp, root ID of the challenging party, and the persona under which they are requesting information) encrypted under their key.

The responding/providing party, for example vehicle driver, [10] can only see plain text relating to the challenge, which is passed on to the authentication broker/certifying authority [11] (as termed under UK Government Gateway -essentially this is the trusted third party (UP) holding all the root identities) which decrypts the cipher-text to reveal the timestamp of the challenge and verifies that the challenger is authorised to make such an assertion. The UP then relays to the respondent (providing party) the unique real-time ID code [5] together with the requisite information (i.e. name [1], booking reference [2], port exit date [3]) alongside the appropriate security information (e.g. a facial biometric [4]) to establish to the requesting party that the respondent is who they say they are.

This identity code is thereafter of no relevance as it pertains only to that root identify and that persona at that time, and cannot therefore be replayed. In many circumstances this could be a challenge response in real time, or in other uses could be time ranged (e.g. in printing tickets with the unique ID code which will confirm right of entry at a given time (cancellation of ticket by genuine purchaser can then invalidate the unique ID code, and another can be presented).

Claims

CLAIMSA system that uses handset-based mobile devices for providing a unique real-time identity, which for in-Country nationals will be an encrypted minimum 24 digit figure consisting of an 11 digit Root Identity, followed by a 3 or more digit persona and 10 digit time stamp (for in-Country visitors, the root identity would be an encrypted country code, passport number and biometrics, and the persona related to the reason for visiting) that is only created and presented at the point/time of requirement, comprising: (i) A requesting party, and a providing party; and (ii) A certifying authority; and (iii) An operating system, resident software; and (iv) A security component; and (v) Secure data depositories; and (Vi) A means for receiving, deciphering and displaying received information.
2. A system according to claim 1(i), wherein each party has a proximity enabled handset-based mobile device which uses close proximity technologies such as blue-tooth, infra-red, near-field, etc.; and
3. A system according to claim I (ii), wherein the certifying authority is a trusted third party that holds all root identities and decrypts the cipher-text to reveal the timestamp of the challenge and verifies that the requesting party is authonsed to make such a request; and
4. A system according to claim I (iii), wherein the operating system enables routing of an encrypted challenge request to the certifying authority and displays the challenge request in plain text on the providing party's mobile device; and A system according to claim 1(v), wherein one or more secure data depositories are accessed to retrieve the requested information; and 6. A system according to claim 5, wherein the trusted third party relays the information to requested party which is then deciphered and displayed on the requested party's mobile device.