GB2561875A - System and method for authenticating a non-transferrable access token - Google Patents

System and method for authenticating a non-transferrable access token Download PDF

Info

Publication number
GB2561875A
GB2561875A GB1706650.7A GB201706650A GB2561875A GB 2561875 A GB2561875 A GB 2561875A GB 201706650 A GB201706650 A GB 201706650A GB 2561875 A GB2561875 A GB 2561875A
Authority
GB
United Kingdom
Prior art keywords
identity information
access token
way hash
transferrable
user identity
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
GB1706650.7A
Other versions
GB201706650D0 (en
Inventor
Garry Kelly Michael
John McLaughlin Barry
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SITA Advanced Travel Solutions Ltd
Original Assignee
SITA Advanced Travel Solutions Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by SITA Advanced Travel Solutions Ltd filed Critical SITA Advanced Travel Solutions Ltd
Priority to GB1706650.7A priority Critical patent/GB2561875A/en
Publication of GB201706650D0 publication Critical patent/GB201706650D0/en
Publication of GB2561875A publication Critical patent/GB2561875A/en
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B11/00—Apparatus for validating or cancelling issued tickets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2240/00—Transportation facility access, e.g. fares, tolls or parking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Tourism & Hospitality (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Theoretical Computer Science (AREA)
  • Storage Device Security (AREA)

Abstract

A non-transferrable access token e.g. boarding pass or event ticket is generated and authenticated, the token comprising access token data and a one-way hash of user identity information (Fig 1). The access token is authenticated by performing the one-way hash on received further identity information 26, comparing 30 the two hashes, and authenticating the token if the hashes match. Alternatively the user identity information may instead be encrypted (Fig 4) using a symmetric encryption key based on a public key and a subset of the access token data, the access token being authenticated by decrypting the user identity information and comparing it to the further identity information. The one-way hash may be performed on the user identity information combined with access token data. The type of user identity information may be encoded in the token to prompt the user. The access token may be digitally signed. The further identity information may be retrieved from a database upon receiving secondary identification from a user such as a biometric scan. The hash may be stored upon authentication to prevent repeated authentication using the same hash. The identity of the individual that presents the token is authenticated without storing plaintext identity information.

Description

(71) Applicant(s):
SITA Advanced Travel Solutions Limited Royal Pavilion, Wellesley Road, Aldershot, HAMPSHIRE, GU11 1PZ, United Kingdom (72) Inventor(s):
Michael Garry Kelly Barry John McLaughlin (56) Documents Cited:
WO 2017/136879 A1 US 20110246369 A1 US 20050021474 A1
US 7093130 B1 US 20080133924 A1 US 20040162787 A1 (58) Field of Search:
INT CL B42D, G06Q, G07B, G07F, H04L Other: EPODOC, WPI, Patent Fulltext (74) Agent and/or Address for Service:
Reddie & Grose LLP The White Chapel Building,
Whitechapel High Street, London, E1 8QS, United Kingdom (54) Title of the Invention: System and method for authenticating a non-transferrable access token
Abstract Title: Generating and authenticating a non-transferrable access token e.g. a boarding pass, by hashing or encrypting user identity information (57) A non-transferrable access token e.g. boarding pass or event ticket is generated and authenticated, the token comprising access token data and a one-way hash of user identity information (Fig 1). The access token is authenticated by performing the one-way hash on received further identity information 26, comparing 30 the two hashes, and authenticating the token if the hashes match. Alternatively the user identity information may instead be encrypted (Fig 4) using a symmetric encryption key based on a public key and a subset of the access token data, the access token being authenticated by decrypting the user identity information and comparing it to the further identity information. The one-way hash may be performed on the user identity information combined with access token data. The type of user identity information may be encoded in the token to prompt the user. The access token may be digitally signed. The further identity information may be retrieved from a database upon receiving secondary identification from a user such as a biometric scan. The hash may be stored upon authentication to prevent repeated authentication using the same hash. The identity of the individual that presents the token is authenticated without storing plaintext identity information.
Figure GB2561875A_D0001
FIG. 2
1/5
JD
Figure GB2561875A_D0002
£Z — j» £ c r- o CO Ό ω — o cn < =)
FIG. 1
2/5 ο
C\J
Figure GB2561875A_D0003
FIG. 2
3/5
CM
CO
Figure GB2561875A_D0004
FIG. 3
4/5
Figure GB2561875A_D0005
FIG. 4 sz — α
£ c r- o CO Ό ω — o cn < =)
5/5
Figure GB2561875A_D0006
FIG. 5
Application No. GB1706650.7
RTM
Date :25 October 2017
Intellectual
Property
Office
The following terms are registered trade marks and should be read as such wherever they occur in this document:
IATA
Intellectual Property Office is an operating name of the Patent Office www.gov.uk/ipo
SYSTEM AND METHOD FOR AUTHENTICATING A NON-TRANSFERRABLE ACCESS TOKEN
FIELD OF THE INVENTION
The present application relates to a system and method for generating and authenticating a non-transferrable access token for accessing a given service, such as access to an entertainment event or access to a mode of transport, such as by rail, air or road. In particular, the application relates to a system and method for enabling automated authentication whilst maintaining the privacy of user identity information.
BACKGROUND TO THE INVENTION
There are many examples of situations where a distributor of an access token may want to limit the use of the token to an identified individual that has been issued the access token, such that the access is non-transferrable and is only valid for the individual that the access token has been issued to. For example, this may be to maintain the security of the service, area or event that the access token permits access to.
In the context of air travel, airlines are typically required to submit passenger information to government authorities in advance of a given flight, accordingly it is important to the airline to ensure that only the individual that was issued the access token (a boarding pass in this example), and identified in the passenger information, typically known as advanced passenger information, is able to board the flight using that access token. Another example may be to maintain the control of the distribution channel and pricing, if any, of the access tokens so that they can only be sold through licenced sellers in accordance with the terms and conditions of the ticketing and at a fair pricing for the individual or consumer.
It is known to include the name of the individual that has been issued the access token on the access token itself; however, this identifying information is not unique as many different individuals may have the same name. Moreover, this field may have a limited number or type of characters available and thus the accurate full name may not be displayed on the passport, further increasing the likelihood that this information may not be unique. For example, the field may be limited to 20 characters and in particular it may not accept special characters with accents or umlauts etc.
Similarly, an image of the user may be included on the access token in order to improve the identification of the individual that has been issued the access token. However, the user may look somewhat different on any given day, for example if the individual has recently returned from holiday then their skin tones may have changed due to tanning, the individual may be wearing glasses in the image on the access token but not when the individual presents the access token for verification and access to the relevant service, area or event, or vice versa, or due to aging etc.
Moreover, including this personally identifying information on the access token in this manner may have implications on the data protection requirements set down in legislation that apply to the access token. Specifically, the inclusion of this personally identifying information may require otherwise unnecessary data protection systems to be put into place in order to protect this personally identifying information in accordance with data protection legislation. This is particularly problematic if it is necessary or desirable to share the access token between a number of different entities that may support the provision and authentication of the access token or the associated service or event and any corresponding storage of the access token.
In view of the above, the inventor has appreciated that it would be desirable to provide an improved system and method for generating and authenticating access tokens such that they are non-transferrable whilst maintaining the simplicity of the associated authentication process and requiring minimal changes to existing systems and processes. As a by-product, this may also simplify the application of the requirements of data protection legislation.
SUMMARY OF THE INVENTION
The invention is defined in the independent claims to which reference should now be directed. Advantageous features are set out in the dependent claims.
In a first aspect, the invention relates to a system for generating a non-transferrable access token, the system comprising: a first receiver device configured to receive access token data and user identity information; an encryption unit configured to perform a one-way hash function on the user identity information to generate a one-way hash; and a token generating unit configured to generate a non-transferrable token comprising the access token data and the one-way hash. The non-transferrable access token generated by the system is authenticated by receiving further identity information, performing the one-way hash function on the further user identity information to generate a further one-way hash, comparing the one-way hash and the further one-way hash, and authenticating the nontransferrable access token if the one-way hash and the further one-way hash are determined to match.
Advantageously, this enables the system to generate a non-transferrable access token that contains user identity information that may be used to authenticate the identity of the individual that presents the non-transferrable access token. Moreover, since this user identity information is stored on the non-transferrable access token in the form of a oneway hash ofthe user identity information, this data is neither human readable nor machine readable, but may be authenticated by the individual providing the user identity information in its original format for hashing and comparison. This advantageously overcomes many data protection requirements whilst still tying, binding or linking the non-transferrable access token to the individual that it was issued to.
Optionally, the encryption unit of the system may be configured to perform the one-way hash function on user identity information that uniquely identifies a given individual that has been issued the non-transferrable access token. By using uniquely identifying information, the accuracy of the authentication process is improved. Optionally, the encryption unit may be configured to perform the one-way hash function on user identity information comprising one or more of: passport information, a personal identification number, biometric data, a credit card number, address data, a drivers licence number, a private cryptography key or date of birth and gender.
Optionally, the encryption unit may be configured to perform the one-way hash function on user identity information in combination with access token data to generate the one-way hash. In this manner, the system advantageously generates a one-way hash that is unique to both the individual and the specific service or event that the access token relates to.
This means that multiple access tokens associated with the individual cannot be linked using the one-way hash and thus the security and privacy of the individual’s data is further improved.
Optionally, the token generating unit may be configured to generate the non-transferrable access token further comprising an encoded identification of the type of user identity information used to generate the one-way hash. This can be used in an advantageous manner during the authentication of the non-transferrable access token as will be discussed below. Optionally, the one-way hash function is a cryptographic hash function.
Optionally, the token generating unit may be configured to generate the non-transferrable access token forming a boarding pass for access to a flight on an aircraft. In this embodiment, the non-transferrable access token is for access to and boarding of an aircraft flight and the access token may be known as a boarding pass. Optionally, the token generating unit is configured to record the one-way hash in an airline custom field of the boarding pass. This enables the one-way hash to be added to the boarding pass whilst still allowing the boarding pass to meet the IATA requirements for boarding pass formatting, such as IATA 792, which defines the required characteristics of the elements and format of the barcode on an airline boarding pass.
Optionally, the token generating unit may be further configured to digitally sign the nontransferrable access token comprising the access token data and the one-way hash. This improves the security of the access token as the data and the one-way hash can be verified to determine if the data has been tampered with.
Optionally, the token generating unit may be further configured to digitally sign the nontransferrable access token based on the access token data and wherein the one-way hash is only recorded on the non-transferrable access token in the digital signature. In this manner, the one-way hash may not be included in the access token data recorded onto the non-transferrable access token; however it may be required to be added to the access token data in order to generate the correct digital signature for verification that the nontransferrable access token is valid and has not been tampered with.
The first aspect may also relate to a system for authenticating a non-transferrable access token, the system comprising: a reader device configured to read a non-transferrable access token comprising access token data and a one-way hash of user identity information; a second receiver device configured to receive further identity information; an encryption unit configured to perform a one-way hash function on the further identity information to generate a further one-way hash; and a comparator unit configured to compare the one-way hash and the further one-way hash. The comparator unit of the system is configured to authenticate the non-transferrable access token if the one-way hash and the further one-way hash are determined to match.
Advantageously, this enables the system to authenticate a non-transferrable access token using a further source of user identity information, without the need to record the user identity information on the access token in a human or machine readable format or in a plaintext format. This advantageously overcomes many data protection requirements whilst still being able to authenticate a link between the non-transferrable access token and the individual that it was issued to.
Optionally, the encryption unit may be configured to perform the one-way hash function on further identity information that uniquely identifies a given individual that has been issued the non-transferrable access token. By using uniquely identifying information, the accuracy of the authentication process is improved. Optionally, the encryption unit may be configured to perform the one-way hash function on further identity information comprising one or more of: passport information, a personal identification number, biometric data, a credit card number, address data, a drivers licence number, a private cryptography key, or date of birth and gender.
Optionally, the encryption unit may be configured to perform the one-way hash function on further identity information in combination with access token data, from the nontransferrable access token, to generate the one-way hash. In this manner, the system advantageously performs the authentication using a one-way hash that is unique to both the individual and the specific service or event that the access token relates to. This means that multiple access tokens associated with the individual cannot be linked using the one-way hash and thus the security and privacy of the individual’s data is further improved.
Optionally, the system further comprises a user output; wherein the reader device is further configured to read an identification, encoded in the non-transferrable access token, of the type of user identity information used to generate the one-way hash; and wherein the user output is configured to output the type of user identity information to the user. This advantageously enables the system to be aware of (and the individual to be prompted regarding) the type of user identity information, for example a passport number or driver’s licence number, that is expected for authentication.
Optionally, the second receiver device may be further configured to receive the further identity information from one of a presented identity document or a user input. For example, a personal identification number may be entered by user input, whereas a passport number may be entered by machine reading of the passport document.
Optionally, the second receiver device may be further configured to receive a secondary identification from a user and to retrieve the further identity information from a database, wherein the further identity information is associated with the secondary identification. In this manner, further user identity information that is stored in a database may be utilised in the authentication process. Optionally, the secondary identification may be received from the user in the form of a result of a biometric scan of the user.
Optionally, the encryption unit may be further configured to determine a digital signature based on a data content of the non-transferrable access token; wherein the reader device is further configured to read a digital signature from the non-transferrable access token; and the comparator unit is further configured to compare the determined digital signature and the read digital signature in order to further authenticate the integrity of the nontransferrable access token. This improves the quality of the authentication process as the system will be able to detect if the non-transferrable access token has been tampered with.
Optionally, the one-way hash of the user identity information may be recorded on the nontransferrable access token as a part of the digital signature configured to be read by the reader device; and wherein the encryption unit is configured to determine the digital signature based on a combination of the data content of the non-transferrable access token and the further one-way hash. This avoids the need to explicitly record the one-way hash on the non-transferrable access token, however the validity of a further one-way hash will be confirmed if the encryption unit confirms that the digital signature is valid.
Optionally, the system may further comprise a one-way hash storage unit; wherein the comparator unit is further configured to compare the one-way hash with each one-way hash stored in the one-way hash storage unit and to only authenticate the non-transferrable access token if the one-way hash is determined not to match any of the one-way hashes stored in the one-way hash storage unit; and wherein the one-way hash storage unit is configured to store the one-way hash once the non-transferrable access token has been authenticated. This advantageously enables the system to reject a non-transferrable access token that has been duplicated, for example if the access token has been re-issued then the system will only authenticate one of the access tokens.
In a second aspect, the invention relates to a method for generating a non-transferrable access token, the method comprising: receiving, at a first receiver device, access token data and user identity information; performing, at an encryption unit, a one-way hash function on the user identity information to generate a one-way hash; and generating, at a token generating unit, a non-transferrable token comprising the access token data and the one-way hash. The non-transferrable access token is authenticated by receiving further identity information, performing the one-way hash function on the further user identity information to generate a further one-way hash, comparing the one-way hash and the further one-way hash, and authenticating the non-transferrable access token if the one-way hash and the further one-way hash are determined to match.
Advantageously, this enables the method to generate a non-transferrable access token that contains user identity information that may be used to authenticate the identity of the individual that presents the non-transferrable access token. Moreover, since this user identity information is stored on the non-transferrable access token in the form of a oneway hash of the user identity information, this data is neither human readable nor machine readable, but may be authenticated by the individual providing the user identity information in its original format for hashing and comparison. This advantageously overcomes many data protection requirements whilst still tying, binding or linking the non-transferrable access token to the individual that it was issued to.
Optionally, the one-way hash function is performed on user identity information that uniquely identifies a given individual that has been issued the non-transferrable access token. By using uniquely identifying information, the accuracy of the authentication process is improved. Optionally, the one-way hash function is performed on user identity information comprising one or more of: passport information, a personal identification number, biometric data, a credit card number, address data, a drivers licence number, a private cryptography key, or date of birth and gender.
Optionally, the one-way hash function is performed on the user identity information in combination with access token data to generate the one-way hash. In this manner, the method advantageously generates a one-way hash that is unique to both the individual and the specific service or event that the access token relates to. This means that multiple access tokens associated with the individual cannot be linked using the one-way hash and thus the security and privacy of the individual’s data is further improved.
Optionally, the generated non-transferrable access token further comprises an encoded identification of the type of user identity information used to generate the one-way hash. This can be used in an advantageous manner during the authentication of the nontransferrable access token as will be discussed below. Optionally, the one-way hash function is a cryptographic hash function.
Optionally, the generated non-transferrable access token forms a boarding pass for access to a flight on an aircraft. In this embodiment, the non-transferrable access token is for access to and boarding of an aircraft flight and the access token may be known as a boarding pass. Optionally, the one-way hash is recorded, by the token generating unit, in an airline custom field of the boarding pass. This enables the one-way hash to be added to the boarding pass whilst still allowing the boarding pass to meet the IATA requirements for boarding pass formatting.
Optionally, the non-transferrable access token comprises the access token data and the one-way hash is signed at the token generating unit. This improves the security of the access token as the data and the one-way hash can be verified to determine if the data has been tampered with. Optionally, the non-transferrable access token is digitally signed, by the token generating unit, based on the access token data and wherein the one-way hash is only recorded on the non-transferrable access token in the digital signature. In this manner, the one-way hash may not be included in the access token data recorded onto the non-transferrable access token; however it may be required to be added to the access token data in order to generate the correct digital signature for verification that the nontransferrable access token is valid and has not been tampered with.
The second aspect may also relate to a method for authenticating a non-transferrable access token, the method comprising: reading, at a reader device, a non-transferrable access token comprising access token data and a one-way hash of user identity information; receiving, at a second receiver device, further identity information; performing, at an encryption unit, a one-way hash function on the further identity information to generate a further one-way hash; and comparing, at a comparator unit, the one-way hash and the further one-way hash. The non-transferrable access token is authenticated, by the comparator unit, if the one-way hash and the further one-way hash are determined to match.
Advantageously, this enables the method to authenticate a non-transferrable access token using a further source of user identity information, without the need to record the user identity information on the access token in a human or machine readable format or in a plaintext format. This advantageously overcomes many data protection requirements whilst still being able to authenticate a link between the non-transferrable access token and the individual that it was issued to.
Optionally, the one-way hash function is performed, by the encryption unit, on further identity information that uniquely identifies a given individual that has been issued the nontransferrable access token. By using uniquely identifying information, the accuracy of the authentication process is improved. Optionally, the one-way hash function is performed, by the encryption unit, on further identity information comprising one or more of: passport information, a personal identification number, biometric data, a credit card number, address data, a drivers licence number, a private cryptography key, or date of birth and gender.
Optionally, the one-way hash function is performed, by the encryption unit, on further identity information in combination with access token data, from the non-transferrable access token, to generate the one-way hash. In this manner, the method advantageously performs the authentication using a one-way hash that is unique to both the individual and the specific service or event that the access token relates to. This means that multiple access tokens associated with the individual cannot be linked using the one-way hash and thus the security and privacy of the individual’s data is further improved.
Optionally, the method further comprises reading, at the reader device, an identification, encoded in the non-transferrable access token, of the type of user identity information used to generate the one-way hash; and wherein the type of user identity information is output, by a user output, to the user. This advantageously enables the method to be aware of (and the individual to be prompted regarding) the type of user identity information, for example a passport number or driver’s licence number, that is expected for authentication.
Optionally, the method comprises receiving, at the second receiver, the further identity information from one of a presented identity document or a user input. For example, a personal identification number may be entered by user input, whereas a passport number may be entered by machine reading of the passport document.
Optionally, the method comprises receiving, at the second receiver, a secondary identification from a user and retrieving the further identity information from a database, wherein the further identity information is associated with the secondary identification. In this manner, further user identity information that is stored in a database may be utilised in the authentication process. Optionally, the secondary identification may be received from the user in the form of a result of a biometric scan of the user.
Optionally, the method further comprises determining, at the encryption unit, a digital signature based on a data content of the non-transferrable access token; reading, at the reading device, a digital signature from the non-transferrable access token; and comparing, at the comparator unit, the determined digital signature and the read digital signature in order to further authenticate the integrity of the non-transferrable access token. This improves the quality of the authentication process as the system will be able to detect if the non-transferrable access token has been tampered with.
Optionally, the one-way hash of the user identity information is recorded on the nontransferrable access token as a part of the digital signature configured to be read by the reader device; and wherein the digital signature is determined based on a combination of the data content of the non-transferrable access token and the further one-way hash. This avoids the need to explicitly record the one-way hash on the non-transferrable access token, however the validity of a further one-way hash will be confirmed if the encryption unit confirms that the digital signature is valid.
Optionally, the method may further comprise comparing, at the comparator unit, the oneway hash with each one-way hash stored in a one-way hash storage unit; and only authenticating the non-transferrable access token if the one-way hash is determined not to match any of the one-way hashes stored in the one-way hash storage unit; and further comprising storing, in the one-way hash storage unit, the one-way hash once the nontransferrable access token has been authenticated. This advantageously enables the system to reject a non-transferrable access token that has been duplicated, for example if the access token has been re-issued then the system will only authenticate one of the access tokens.
In a third aspect, the invention relates to a system for generating a non-transferrable access token, the system comprising: a first receiver device configured to receive access token data and user identity information; an encryption unit configured to generate a symmetric encryption key based on a public key and at least a subset of the access token data and to encrypt the user identity information using the symmetric encryption key; and a token generating unit configured to generate a non-transferrable token comprising the access token data and the encrypted user identity information. The non-transferrable access token is authenticated by decrypting the user identity information, receiving further identity information, comparing the user identity information and further identity information, and authenticating the non-transferrable access token if the user identity information and the further identity information are determined to match.
Advantageously, this enables the system to generate a non-transferrable access token that contains encrypted user identity information that may be used to authenticate the identity of the individual that presents the non-transferrable access token. Moreover, since the user identity information is stored on the non-transferrable access token in an encrypted form, the data cannot be read without knowledge of the public key and/or the symmetric encryption key. This advantageously overcomes many data protection requirements whilst still tying, binding or linking the non-transferrable access token to the individual that it was issued to
Optionally, the first receiver device may be configured to receive the user identity information comprising a user identity information type. This can be used in an advantageous manner during the authentication of the non-transferrable access token as will be discussed below.
Optionally, the token generating unit may be further configured to digitally sign the nontransferrable access token comprising the access token data and the encrypted user identity information. This improves the security of the access token as the data and the encrypted user identity information can be verified to determine if the data has been tampered with.
The third aspect may also relate to a system for authenticating a non-transferrable access token, the system comprising: a reader device configured to read a non-transferrable access token comprising access token data and encrypted user identity information; a second receiver device configured to receive further identity information; an encryption unit configured to generate a symmetric encryption key based on a public key and at least a subset of the access token data and to decrypt the encrypted user identity information using the symmetric encryption key; and a comparator unit configured to compare the decrypted user identity information and the further identity information. The comparator unit is configured to authenticate the non-transferrable access token if the decrypted user identity information and the further identity information are determined to match.
Advantageously, this enables the system to authenticate a non-transferrable access token by decrypting the user identity information and comparing it to a source of further user identity information without the need to store the user identity information on the nontransferrable access token in a plaintext format. This advantageously overcomes many data protection requirements whilst still being able to authenticate a link between the nontransferrable access token and the individual that it was issued to.
Optionally, the decrypted user identity information comprises a user identity information type and the system is further configured to output a user prompt identifying the expected user identity information type for the further identity information to be received at the second receiver device. This advantageously enables the system to be aware of (and the individual to be prompted regarding) the type of user identity information, for example a passport number or driver’s licence number, that is expected for authentication. Optionally, the user prompt further comprises a partial indication of the user identity information. This further aids the individual in identifying the correct source of further identity information that should be presented or input.
In a fourth aspect, the invention relates to a method for generating a non-transferrable access token, the method comprising: receiving, a first receiver device, access token data and user identity information; generating, at an encryption unit, a symmetric encryption key based on a public key and at least a subset of the access token data and encrypting the user identity information using the symmetric encryption key; and generating, at a token generating unit, a non-transferrable token comprising the access token data and the encrypted user identity information. The non-transferrable access token is authenticated by decrypting the user identity information, receiving further identity information, comparing the user identity information and further identity information, and authenticating the nontransferrable access token if the user identity information and the further identity information are determined to match.
Advantageously, this enables the method to generate a non-transferrable access token that contains encrypted user identity information that may be used to authenticate the identity of the individual that presents the non-transferrable access token. Moreover, since the user identity information is stored on the non-transferrable access token in an encrypted form, the data cannot be read without knowledge of the public key and/or the symmetric encryption key. This advantageously overcomes many data protection requirements whilst still tying, binding or linking the non-transferrable access token to the individual that it was issued to
Optionally, the method may further comprise receiving, at the first receiver device, the user identity information comprising a user identity information type. This can be used in an advantageous manner during the authentication of the non-transferrable access token as will be discussed below.
Optionally, the method may further comprise digitally signing, at the token generating unit, the non-transferrable access token comprising the access token data and the encrypted user identity information. This improves the security of the access token as the data and the encrypted user identity information can be verified to determine if the data has been tampered with.
The fourth aspect may also relate to a method for authenticating a non-transferrable access token, the method comprising: reading, at a reader device, a non-transferrable access token comprising access token data and encrypted user identity information; receiving, at a second receiver, further identity information; generating, at an encryption unit, a symmetric encryption key based on a public key and at least a subset of the access token data and decrypting the encrypted user identity information using the symmetric encryption key; and a comparator unit configured to compare the decrypted user identity information and the further identity information. The comparator unit is configured to authenticate the non-transferrable access token if the decrypted user identity information and the further identity information are determined to match.
Advantageously, this enables the method to authenticate a non-transferrable access token by decrypting the user identity information and comparing it to a source of further user identity information without the need to store the user identity information on the nontransferrable access token in a plaintext format. This advantageously overcomes many data protection requirements whilst still being able to authenticate a link between the nontransferrable access token and the individual that it was issued to.
Optionally, the decrypted user identity information may comprise a user identity information type and wherein the method further comprises outputting a user prompt identifying the expected user identity information type for the further identity information to be received at the second receiver device. This advantageously enables the system to be aware of (and the individual to be prompted regarding) the type of user identity information, for example a passport number or driver’s licence number, that is expected for authentication. Optionally, the user prompt may further comprise a partial indication of the user identity information. This further aids the individual in identifying the correct source of further identity information that should be presented or input.
BRIEF DESCRIPTION OF THE DRAWINGS
Embodiments of the invention will now be described, by way of example only, and with reference to the accompanying drawings, in which:
Figure 1 is a schematic representation of a system for generating a non-transferrable access token according to an embodiment of the first aspect of the disclosure;
Figure 2 is a schematic representation of a system for authenticating a nontransferrable access token according to an embodiment of the first aspect of the disclosure;
Figure 3 is a schematic representation of a system for authenticating a nontransferrable access token according to a further embodiment of the first aspect of the disclosure; and
Figure 4 is a schematic representation of a system according to a third aspect of the disclosure.
DETAILED DESCRIPTION
The present invention relates to systems and methods for the generation and authentication of non-transferrable access tokens, for example for gaining access to an area, a particular event, or obtaining certain goods or services. This may include concerts, festivals and transport such as by road, rail or by air. Whilst the invention applies equally to access tokens intended for other means, the invention will be described in the context of the aviation industry and the generation and authentication of a boarding pass for the access to and boarding of an airplane for a given flight.
Figure 1 shows a schematic representation of a system 10 for generating a nontransferrable access token according to an embodiment of the first aspect of the disclosure. The system 10 comprises a first receiver device 12, a processor 14, an encryption unit 16 and a token generating unit 18. In this embodiment of the first aspect, the first receiver device 12 of the system 10 is configured to receive access token data and user identity information.
The access token data may comprise the standard data that would be included in the standard access token for gaining access to the area, event, goods or services. In the context of the aviation industry, the access token may be a boarding pass for a given flight and the access token data may include information about the flight number, the date and time of the flight departure, the airport terminal that the flight is due to depart from, a departing airport reference, an arrival airport reference, a booking reference number (e.g. the Passenger Name Record number, or PNR), the name ofthe passenger, and/or a frequent flyer number.
The user identity information is the additional information that personally identifies the passenger or individual that the access token or boarding pass is to be issued to. For example, this may comprise all or a subset of the passenger’s passport information, a personal identification number associated with the passenger, passenger biometric data, a credit card or debit card number and expiry date of a card belonging to the passenger (especially the card number used to pay for the booking), passenger address information, a private cryptography key and/or date of birth and gender.
The user identity identification number may take many forms, for example a conventional PIN number sequence or a one-time access code, a driver’s licence number or a national identity card number. The address information may be full or partial, for example the address information may be just a postcode and house number or name. Moreover, the biometric data may include gender information, facial data, retina data, iris data, fingerprint data and/or palm data. As can be seen from the above, the user identity information may be any information that personally identifies the passenger, preferably in a unique manner, and can presented or accessed both at the time of issuing the boarding pass and at the time when the boarding pass is authenticated.
In the case of user identity information that is recorded in a document, for example a passport, card number, driver’s licence or national identity card, the user identity information may be received at the first receiver device from a reader, such as an optical scanner, a magnetic strip reader, a near field communication (NFC) reader or another conventional reading device. Alternatively, the user identity information may be received from a keypad that the passenger to inputs the information into or from a biometric scanner that performs a biometric scan of the passenger.
The access token data and the user identity information that has been received by the first receiver device are then passed to the processor 14 for further handling. The user identity information is passed to the encryption unit 16, which performs a one-way hash on the user identity information and then returns this one-way hash to the processor 14. The processor may then pass the one-way hash generated by the encryption unit 16 and the access token data to the token generating unit 18 for generating a non-transferrable access token (boarding pass) comprising the access token data and the one-way hash of the user identity information.
The system 10 generates a non-transferrable access token or ticket. This does not mean that the access rights associated with the access token cannot be redistributed to another individual, but rather that the access token itself cannot be simply transferred with the possession of the access token being transferred. In this way, it is necessary for the issuer of the access token to be involved in the process of revoking the previous access token and issuing a new access token in order for the access rights associated with the previous access token to be transferred to a new individual.
In this embodiment of the first aspect of the disclosure, the bearer of the non-transferrable access token (boarding pass) presents the previously generated boarding pass at an authentication point. The use of this one-way hash will now be explained with reference to the system 20 for authenticating a non-transferrable access token according to an embodiment of the first aspect as shown in the schematic representation of Figure 2. The system 20 comprises a reader device 22, a processor 24, a second receiver device 26, an encryption unit 28 and a comparator 30.
The boarding pass data, including the access token data and the one-way hash of the user identity information, is read by the reader device 22 and passed to the processor 24. The second receiver device 26 of the system 20 is also configured to receive further identity information from the bearer of the boarding pass. As described above for the user identity information, the further identity information may be received from a reader, such as an optical scanner, a magnetic strip reader, a near field communication (NFC) reader, another conventional reading device, a keypad that the passenger to inputs the information into or from a biometric scanner that performs a biometric scan of the passenger. The second receiver device 26 then passes this further identity information to the processor 24.
The processor then passes the further identity information to the encryption unit 28, which is configured to perform the same one-way hashing process on the further identity information as the hashing process used by the encryption unit 16 of system 10. The oneway hash of the further user information generated by the encryption unit 28, which may be referred to as the further one-way hash, is then returned to the processor 24 and passed to the comparator 30 along with the one-way hash of the user identity information that was contained in the boarding pass data received at the reader device 22. The comparator 30 then compares the one-way hash and the further one-way hash and returns the result of the comparison, e.g. positive or negative I match or no match, to the processor 24.
In this manner, the standard boarding pass data has been enhanced by the presence of the one-way hash of the user identity information, which personally identifies the passenger that the boarding pass has been issued to. Because the original user identity information is encoded in a one-way hash and not recorded on the boarding pass in plain text, the original information will not be readable from the boarding pass by machine or by human. However, if the hashes of the user identity information and the further identity information are determined to match, then it can be determined that the user identity information and the further identity information also match and accordingly it may be authenticated that the boarding pass was issued to the passenger that presented the further identity information at the authentication point.
This means that the boarding pass can be linked to the passenger using personally identifying information without actually recording the personally identifying information on the boarding pass itself and thus there is no change in the level of data protection required for the boarding pass data. This is because the one-way hash may not be considered to be personal information about the passenger that falls under the data protection requirements.
Moreover, by storing the algorithm for the hashing process locally, there will be no need to rely on a connection to a backend system for querying the status of the boarding pass details and passport or other identity document information. This would require high security protocols in order to meet data protection legislation and requirements.
Thus the present invention improves the processing speed of the check since the calculation may be performed locally using the presented boarding pass and passport.
This also enables the check to be performed at locations that are offline or do not have access to the backend server. For example, a staff member may perform this check on individuals that are waiting in a queue using a mobile device. This may contribute to a significant improvement in the processing speeds of individuals through such access security points. Accordingly, the present invention provides an improved method for authenticating a link between a boarding pass and an identity document and furthermore the need to present personally identifying information in a human or machine readable manner is overcome.
In one example, the user identity information may be passport information, driver’s licence information or national identity card information. In such an example, the further identity information would be the corresponding information contained in the passport, driver’s licence or national identity card that is presented by the passenger along with the boarding pass.
Through such a system, the security ofthe event, in this case travel on an aircraft, is improved because the identity of the individual may be known and prior to the event or delivery of the service and the authentication steps may prevent the access token being transferred to another individual for authentic use without the knowledge of the issuer of the access token. Furthermore, the personally identifying user identity information cannot be read directly from the access token, for example in the event that it is sent over email and parsed by an email applet or digital assistant, or in the event that an image of the access token is uploaded to a social network or other publicly accessible location.
The security or other personnel at the authentication point may use the system to automatically verify that the boarding pass is linked to the identity of the passenger presenting the boarding pass, for example by linking the boarding pass to the passenger’s passport and ensuring that the same passport is presented at the authentication point as was disclosed to the airline in the advanced passenger information or at the point of checkin. This frees the security personnel to focus on checking that the passport or other identity document containing the further identity information matches the passenger that has presented it.
In such a situation, it may not be necessary for the security personnel to check the name on the boarding pass against the name on the passport as this check may have been carried out prior to generating the boarding pass. Accordingly, the system may also improve the throughput of passengers through security access checkpoints. This is particularly beneficial since it is relatively common for the name on the boarding pass and the name on the passport to not match exactly, for example due to the limited number of characters available on the boarding pass or due to the boarding pass typically not being able to include non-Latin characters, hyphens or apostrophes. Thus, additional time spent considering such discrepancies may be avoided.
This is also advantageous in situations where the right to travel and the boarding pass may have been granted on the basis of a passenger’s citizenship and where the passenger has a dual citizenship. In such a situation, the passenger may submit the details of one of their passports in the advanced passenger information and be granted the right to travel, but then accidentally or on purpose travel using their other passport. Alternatively, the passenger may attempt to use one passport when departing and another passport when arriving at the destination countries border control.
This can be problematic for both boarder control and for airlines, and may cause the passenger to be refused entry. For example, the advanced passenger information may have been used to carry out background checks on the identified passenger to determine if the individual is a security threat, if there are any outstanding law enforcement issues or similar that require the passenger to be intercepted on arrival, or if the identified passport has been listed as stolen. Through the system described herein, it can be ensured that the passenger uses the same passport that was identified at the time of, or prior to, issuance of the boarding pass.
Authorized agents for the airport or airline who are required to inspect boarding passes but not required to inspect passports would not be able to access the user identity information in the boarding pass since it is stored in a hashed form. Where agents need to verify a boarding pass and passport combination, it will be at the discretion of the passenger whether to present the agent with the passport which contains the user identity information in plain text form and thus this sharing of personal user identity information will also meet data protection requirements.
By including uniquely identifying information on the boarding pass, it may be possible for those that have access to the boarding pass to create a log of boarding passes that have contained the uniquely identifying information and thus build a record of journeys that have been taken by a passenger, for example for using in marketing or other purposes. This may be undesirable for the passenger and thus it may be desirable for the uniquely identifying information to be different for each journey that the passenger makes.
Whilst the passport information or other identity document data may remain the same between consecutive journeys, this aim may be achieved by combining the passport information with another item of information prior to generating the one-way hash. This other item of information must be available at the time of authentication in order for the one-way hash to be repeated and thus the inventor has appreciated that it would be preferable to use an item of information that is already contained on the boarding pass.
For example, the PNR of the journey could be used, or other information such as the date of travel may alternatively be used.
Even if the other item of information that is used is known to a third-party, it will not be practicable for them to reverse engineer the one-way hash in order to obtain the passport information or indeed a hash of just the passport information, particularly if the other item of information may take a sufficiently wide variety of values. Thus, it will not be possible for the hash to be used to link multiple journeys that may be made by the same passenger.
This also improves the security of the system, since the same user identity information will not be used consecutively or for an extended period of time, thus reducing the possibility for identity theft. Moreover, the one-way hash function is preferably a secure cryptographic hash function.
It may be desirable for the one-way hash to remain the same for flights on the same PNR, for all outbound flights in a given booking, or to be unique per flight and the skilled person, in view of the above teaching of the specification, would understand that many different items of information could be combined with the user identity information in order to achieve such aims and would select one accordingly.
The formatting and allowable data fields of the machine readable part of a boarding pass are currently governed by IATA 792 and accordingly there may be restrictions regarding where the hash can be stored in the boarding pass data stream. Optionally, the hash may be stored in a custom field that is reserved for use by the airline. This ensures that the boarding pass may still be readable by legacy systems that comply with the current boarding pass specifications where only the information previously stored on the boarding pass is required. Alternatively, the hash may be stored in another field as allowed by any modifications to IATA 792 or subsequent resolutions.
The boarding pass is preferably digitally signed so that the machine readable element of the access token cannot be modified without detection by verification of the digital signature. This is because the mathematical scheme for generating and verifying the digital signature preferably means that there is no efficient way to modify a message and its signature to produce a new message with a valid signature. This digital signature can be verified by the encryption unit 28 in order to confirm the integrity of the machine readable data stored in the boarding pass.
Optionally, the hash may be stored as a part of the digital signature. In this situation, the hash is not explicitly stored on in the boarding pass data stream. Instead, the digital signature stored on the boarding pass is modified to be generated on the basis of the boarding pass data stream in combination with the hash. In this situation, the integrity of the boarding pass data stream can be verified when the appropriate further identity information is provided.
This is achieved by performing the one-way hash on the further identity information, combining the data of the one-way hash with the data stream from the boarding pass and then using this combination to verify the digital signature. If both the machine readable zone of the boarding pass has not been tampered with and the further identity information provided matches the user identity information that was provided when the boarding pass and the digital signature were originally generated then the digital signature will be verified. This may confirm that the boarding pass is valid and matches the presented further identity information and any corresponding identity document, such as the passenger’s passport.
Optionally, the information presented by the passenger may be a form of uniquely identifying information other than the user identity information that was used to generate the boarding pass. In such a situation, the system 20 may receive the further identity information at the second receiver device 26 by polling an intermediate database that stores a list of further identity information associated with other forms of uniquely identifying information, such as the passenger’s frequent flyer number, another enrolment number or using biometric data obtained from a biometric scan of the passenger. This other form of uniquely identifying information may be referred to as a secondary identification of the passenger.
Once the system 20 has polled the intermediate database, the further identification information associated with the passenger may be obtained and the process may proceed as set out above. In the case of the frequent flyer number or other enrolment number, this secondary identification may be stored in the boarding pass, for example in the airline custom field.
Figure 3 illustrates a schematic representation of a system for authenticating a nontransferrable access token according to a further embodiment of the first aspect of the disclosure. Like reference numerals have been used for like components with respect to Figure 2 and accordingly the discussion of these components will not be repeated. The new components shown in Figure 3 are a user output 34 and a storage unit 36. As will be appreciated from the below discussion, each of these two additional components may be incorporated into the system 20 of Figure 2 in isolation, i.e. without the addition of the other of the two components.
In Figure 3, the user output 34 receives the type of user identity information that was used in the generation of the boarding pass from the processor 24. In this example, the processor 24 preferably extracts this indication of the type of user from the boarding pass itself. This may be achieved by including this indication in the boarding pass in plain text, since this information alone would not typically be considered to be personal data. Preferably, this indication is included in the boarding pass by the token generating unit 18 of the system 10.
This indication received at the user output 34 may then be output from the system 32 in order to aid the passenger, the official at the authentication point and/or the system 32 in selecting the correct type of document or data fields in the document that contain the further identity information needed for the validation process to begin. This is particularly advantageous where the system supports the use of further identity information from a plurality of sources, such as a passport or a driver’s licence.
The storage unit 36 of Figure 3 may be configured to receive a further one-way hash from the processor 24 when it has been determined that the further one-way hash matches the one-way hash contained in the boarding pass. In this manner, the storage unit 36 may contain a list representing the boarding passes that have been accepted by the system. It will be appreciated by the skilled person that the processor 24 may alternatively store the one-way hash in the storage unit 36, , instead of the further one-way hash, since it will have been determined by this point that the two hashes match.
The processor 24 may then perform an additional check when authenticating the boarding passes. In such an example, the system 32 may determine that the one-way hash and the further one-way hash match and then proceed to determine if either of the hashes match one of the hashes that have already been stored in the storage unit 36. If it is determined that the hash matches a hash that has already been stored in the storage unit 36 then this may indicate that a duplicate boarding pass has been generated and that the current boarding pass should not be authenticated. Conversely, if no match is found in the storage unit 36, then the boarding pass may be authenticated and the corresponding hash may then be stored in the storage unit 36.
This duplication situation may occur for example where a boarding pass have been issued with one seat reservation and then revoked and re-issued with a different seat reservation. In this situation, the hash would typically not change (unless the seat number was used in the generation of the one-way hash) and so it would advantageously be able to be detected if an individual attempted to use the revoked boarding pass in addition to the re-issued boarding pass.
A typical machine readable zone of a boarding pass may read as follows:
M1KELLY/GARRY MR EPNR123 JFKORDAB 1234 008Y012A0010 147>3180 M7008BAB 29000 0 XX A160MEUCIG26838w7RhtMNFuOR/glPRP0oXFm0flj5lhn6dl9dwPAiEAtxDtStagHpP1njjzR 1 j J KLvDvcxPlg5vezcX+/Rt2go=
The “XX” on the second line represents the code of the issuing airline and indicates who has signed the boarding pass. The second and third lines represent the signature, with the “A” signifying the start of the security data, the immediately following “1” representing the version number and the length of the first part of the signature, which is signed using the airline’s private key, being 60. The remaining data in the signature is an Elliptic Curve Digital Signature Algorithm (ECDSA) signature of the Secure Hash Algorithm (SHA) 256 of the bytes from the first two lines, i.e. from M1 up to but not including the A character.
Some example algorithms for generating the hash to be added to the boarding pass will now be discussed, using example pseudocode where appropriate.
In this example, the user identity data is encrypted prior to hashing; however, as will be appreciated from the above description this encryption step is not necessary. First, an Advanced Encryption Key (AES) 256 encryption key is created, preferably a symmetric encryption key. This is achieved by starting with a shared secret between the airline issuing the boarding pass and the providers of the readers for authenticating the boarding passes. This shared secret is preferably unique to the issuing airline in order to obfuscate the information from that from other issuing airlines. For example, the issuing entity may use a private key and the validating system may use a corresponding private key.
In this example, we have used the SHA512(SHA512(airlinepublicKey)), where airlinepublicKey is the public key of the airline that corresponds to the shared secret. This increases the difficulty for any third party to reverse engineer the information as the public key must also be known in order to extract the identifying information of the individual. Some flight information that is unique to the flight is then added in order to ensure that the encryption key is different for every passenger flight and a SHA256 is generated of the resultant data, e.g.:
public static byte[] getAESEncryptionKey(PublicKey publicKey, String issuingAirlineCode, String deptAirportCode,
String arrAirportCode, String carrier, String flightNumber, String pnr, LocalDate dayOfTravel) {
StringBuffer sb = new StringBuffer();
sb.append(StringUtil.cleanUppercase(issuingAirlineCode));
sb.append(StringUtil.cleanUppercase(deptAirportCode));
sb.append(StringUtil.cleanUppercase(arrAirportCode));
sb.append(StringUtil.cleanUppercase(carrier));
sb.append(StringUtil.cleanUppercase(flightNumber));
sb.append(StringUtil.cleanUppercase(pnr));
sb.append(dayOfTravel.toStringO);
sb.append(DigestUtils.sha512(DigestUtils.sha512(StringUtil.fromUTF8Bytes(public
Key.getEncoded ()))));
return DigestUtils.sha256(sb.toStringO);
}
This is the AES256 encryption key which will be used to encrypt the passenger’s user identity information. The encryption key changes for different flights I days of travel, relies on the secret exchanged between the airline issuer and the verifier of the boarding pass and remains the same for a given passenger on the same flight, for example the encryption key will remain the same if it is necessary to reprint the boarding pass. This may advantageously enable the system to check for duplicates.
The data to be encrypted may then be generated using a structured message as follows:
public static String calculateEncryptedldentitylnformation(String issuingAirlineCode, String deptAirportCode, String arrAirportCode, String carrier, String flightNumber, String pnr, IDDocumentType docType, LocalDate birthDate, LocalDate expiryDate, String docNumber, String docIssueCountryCode, char reserved) {
StringBuffer sb = new StringBuffer();
sb.append(docType.getCode());
sb.append(reserved);
sb.append(StringUtil.convertl_ocalDateTo4DigitBase36Number(birthDate));
sb.append(StringUtil.convertl_ocalDateTo4DigitBase36Number(expiryDate));
sb.append(StringUtil.rpad(StringUtil.firstXCharacters(doclssueCountryCode,
3), 3,''));
sb.append(StringUtil.cleanUppercase(docNumber.toString())); return sb.toString();
}
Accordingly, the functions of the characters in the structured message may be as follows:
Character 1: Document Type, e.g. P=Passport L=Driver’s Licence
Character 2: Reserved
Characters 3,4,5,6: Passenger Birth Date, preferably expressed as number of days since 01 Jan 1900 in Base36
Characters 7,8,9,10: Document Expiry Date, preferably expressed as number of days since 01 Jan 1900 Base36
Characters 11,12,13: Document Issue Country code using the three letter ISO code for the issuing country
Characters 14-42: Used for the identity document number
By expressing the dates in the number range 0000 to ZZZZ, the number of bytes required may be reduced. Reserved character 2 may be used to indicate the version being used or for encoding a trust status of the passenger. Such extra data may be included here without it being publicly available.
The data to be encrypted is then encrypted using the above encryption key, preferably the encrypted data is again converted to Base36 in order to make most efficient use of the data size.
byte[] encBytes = encrypt(demonstrationPublicKey, StringUtil.getUTF8Bytes(sb.toString()), issuingAirlineCode, deptAirportCode, arrAirportCode, carrier, flightNumber, pnr, dayOfT ravel);
Biglnteger biglnt = new Biglnteger(1, encBytes);
return 1 + StringUtil.lpad(biglnt.toString(36).toUpperCase(), 50, O');
Next the encrypted data is hashed before being included in the boarding pass data stream:
byte[] hashedBytes = DigestUtils.sha256(encBytes);
Biglnteger biglnt = new Biglnteger(1, hashedBytes);
return 0 + StringUtil.lpad(biglnt.toString(36).toUpperCase(), 50, O');
The resulting boarding pass data stream, or machine readable zone, may be as follows, where the first 50 characters of the third line is the hashed user identity data:
M1KELLY/GARRY MR EPNR123 JFKORDAB 1234 008Y012A0010 17A>3180 M7008BAB 5C000 0 XX
0449E88JTTYL1CTD3P46X7BYRYISKAJ84PX8BPULK6BATPKKKYYA160MEUCIQDwzL
WvC12KvfzND+Fqf8YzCgQrAbgXtYghlu7UqwKI4wlgODBqOF+B7V/FTcrb6ezQjjH3TYg1E
ENTeWaYjs/R+WM=
In this example, the signature has been computed on the entire boarding pass data stream, including the hashed user identity data.
In a second example, the boarding pass data stream may be as follows:
M1KELLY/GARRY MR EPNR123 JFKORDB6 1011 008Y012A0010 147>3180 M7008BAB 29000 0 XX A260MEUCIAN+9nVtd6uSe+0f9GPsQRU7TTntpPi+bS1V6IEmm10MAiEA09H07H/3nZK3
QnAQwS7EUNSssFEtt/oKLIgmr5F45os=
In this example, there is no user identity information in the boarding pass data stream itself (hashed or otherwise) and instead the signature has been calculated on the basis of the hashed user identity information appended to the boarding pass data stream. This is signified by the signature starting with Λ2 instead of Λ1 in this example so that the readers attempting to authenticate the boarding pass will know that the signature is computed on the data in the boarding pass data stream as well as some additional data.
Taking the previous example, the signature will be valid for the following, where the first 50 characters are the hash of the user identity information:
3WG25L5M0FXI3WPFC7XYA6X3FBBJ3T4CUP4KK9C81CJQ84EB3U M1KELLY/GARRY MR EPNR123 JFKORDB6 1011 008Y012A0010 147>3180 M7008BAB 29000
0ΧΧ
Advantageously, this does not have any impact on systems that do not check the signature. However, this example will mean that further identity information, or a passport or other document containing such information, will need to be presented in order for a system that does check the signature, to perform a verification of the signature regarding whether or not the boarding pass data stream has been tampered with.
A third aspect of the present disclosure will now be described with reference to Figure 4, which is a schematic representation of a system 38 for generating a non-transferrable access token. The system 38 comprises a first receiver device 40, a processor 42, an encryption unit 44 and a token generating unit 46. The system 38 is very similar to the system 10, except that encryption is used instead of hashing the user identity information.
In the third aspect of the disclosure, the first receiver device 40 of the system 38 is configured to receive access token data and user identity information and to pass this data to the processor 42. As discussed with respect to the first aspect, the access token data may comprise the standard data that would be included in the standard access token for gaining access to the area, event, goods or services and the user identity information is the additional information that personally identifies the passenger or individual that the access token or boarding pass is to be issued to.
The encryption unit 44 is then configured to receive at least a subset of the access token data and to generate a symmetric encryption key based on the at least a subset of the access token data and a public key that may be stored at the encryption unit 44. The encryption unit 44 may also receive user identity information and may then encrypt this user identity information using the symmetric encryption key and pass the encrypted user identity information to the processor 42. The processor 42 may then pass the encrypted user identity information and the access token data to the token generating unit for generating a non-transferrable access token comprising these data items.
The token generating unit 46 may also be configured to record an indication of the type of user identity information that has been encrypted in the non-transferrable access token. Moreover, the token generating unit 46 of the system 38 preferably digitally signs the nontransferrable access token in order to improve the security of the non-transferrable access token as has been described with reference to the first aspect of the disclosure above.
The use of this encrypted user identity information will now be explained with reference to the system 48 for authenticating a non-transferrable access token according to the third aspect as shown in the schematic representation of Figure 5. The system 48 comprises a reader device 50, a processor 52, a second receiver device 54, an encryption unit 56, a comparator 58 and a user output 60.
The reader device 50 is configured to read a non-transferrable access token comprising access token data and encrypted user identity information and to pass this data to the processor 52. The second receiver device is configured to receive further identity information and to pass this data to the processor 52. The processor 52 then passes the encrypted user identity information from the access token data as well as at least a subset of the other data from the access token to the encryption unit 56. The encryption unit 56 is configured to generate a symmetric encryption key based on the at least a subset of the access token data and a public key that may be stored at the encryption unit 56.
Since the encryption employed at the encryption unit 56 is a symmetric encryption, the symmetric encryption key may be used by the encryption unit 56 to decrypt the encrypted user identity information and reproduce the plain text user identity information, which may then be passed back to the processor 52. The processor 52 may then pass the decrypted user identity information and the further identity information to the comparator 58 for comparison. The result of the comparison, e.g. positive or negative I match or no match, is then returned to the processor 52. If the decrypted user identity information and the further identity information are determined to match then the system 48 is configured to authenticate the non-transferrable access token. If the decrypted user identity information and the further identity information are determined not to match then the system 48 does not authenticate the non-transferrable access token.
Optionally, the processor 52 may extract the indication of the type of user identity information that has been encrypted from the non-transferrable access token data and pass this indication to the user output 60. The user output 60 may then output this indication from the system 48 in order to aid the passenger, the official at the authentication point and/or the system 48 in selecting the correct type of document or data fields in the document that contain the further identity information needed for the validation process to begin. This is particularly advantageous where the system supports the use of further identity information from a plurality of sources, such as a passport or a driver’s licence.
Moreover, the system 48 may decrypt the user identity information prior to the further identity information being received at the second receiver device 54. In such a scenario, the system 48 may be configured to output a user prompt from the user output 60 comprising a partial indication of the user identity information that is expected to be received in order for the non-transferrable access token to be authenticated. For example, the prompt may state “Scan Passport No IRL*****7652 Exp:05/2022”. In this manner, the system may aid the user in presenting the correct further identity information and thus improve the processing speed of individuals at the authentication point.
An example algorithm will now be discussed, using example pseudocode where appropriate, in the context of a boarding pass that has been issued for a flight on an aircraft.
First, the Advanced Encryption Key (AES) 256 symmetric encryption key is created. This is achieved by starting with a shared secret between the airline issuing the boarding pass and the providers of the readers for authenticating the boarding passes. This shared secret is preferably unique to the issuing airline in order to obfuscate the information from that from other issuing airlines. This data may act as cryptographic salt, i.e. unconnected data that is added to the input of the one-way hash function in order to increase the difficulty of a rainbow table attack or other type of brute force attack.
In this example, we have used the SHA512(SHA512(airlinepublicKey)), where airlinepublicKey is the public key of the airline that corresponds to the shared secret. This increases the difficulty for any third party to reverse engineer the information as the public key must also be known in order to extract the identifying information of the individual. Some flight information that is unique to the flight is then added in order to ensure that the encryption key is different for every passenger flight and a SHA256 is generated of the resultant data, e.g.:
public static byte[] getAESEncryptionKey(PublicKey publicKey, String issuingAirlineCode, String deptAirportCode,
String arrAirportCode, String carrier, String flightNumber, String pnr, LocalDate dayOfTravel) {
StringBuffer sb = new StringBuffer();
sb.append(StringUtil.cleanUppercase(issuingAirlineCode));
sb.append(StringUtil.cleanUppercase(deptAirportCode));
sb.append(StringUtil.cleanUppercase(arrAirportCode));
sb.append(StringUtil.cleanUppercase(carrier));
sb.append(StringUtil.cleanUppercase(flightNumber));
sb.append(StringUtil.cleanUppercase(pnr));
sb.append(dayOfTravel.toString());
sb.append(DigestUtils.sha512(DigestUtils.sha512(StringUtil.fromUTF8Bytes(public Key.getEncoded ()))));
return DigestUtils.sha256(sb.toString());
}
This is the AES256 encryption key which will be used to encrypt the passenger’s user identity information. The encryption key changes for different flights I days of travel, relies on the secret exchanged between the airline issuer and the verifier of the boarding pass and remains the same for a given passenger on the same flight, for example the encryption key will remain the same if it is necessary to reprint the boarding pass. This may advantageously enable the system to check for duplicates.
The data to be encrypted may then be generated using a structured message as follows:
public static String calculateEncryptedldentitylnformation(String issuingAirlineCode, String deptAirportCode, String arrAirportCode, String carrier, String flightNumber, String pnr, IDDocumentType docType, LocalDate birthDate, LocalDate expiryDate, String docNumber, String docissueCountryCode, char reserved) {
StringBuffer sb = new StringBuffer();
sb.append(docType.getCode());
sb.append(reserved);
sb.append(StringUtil.convertLocalDateTo4DigitBase36Number(birthDate));
sb.append(StringUtil.convertLocalDateTo4DigitBase36Number(expiryDate));
sb.append(StringUtil.rpad(StringUtil.firstXCharacters(doclssueCountryCode,
3), 3,''));
sb.append(StringUtil.cleanUppercase(docNumber.toString())); return sb.toString();
}
Accordingly, the functions of the characters in the structured message may be as follows:
Character 1: Document Type, e.g. P=Passport L=Driver’s Licence
Character 2: Reserved
Characters 3,4,5,6: Passenger Birth Date, preferably expressed as number of days since 01 Jan 1900 in Base36
Characters 7,8,9,10: Document Expiry Date, preferably expressed as number of days since 01 Jan 1900 Base36
Characters 11,12,13: Document Issue Country code using the three letter ISO code for the issuing country
Characters 14-42: Used for the identity document number
By expressing the dates in the number range 0000 to ZZZZ, the number of bytes required may be reduced. Reserved character 2 may be used to indicate the version being used or for encoding a trust status of the passenger. Such extra data may be included here without it being publicly available.
The data to be encrypted is then encrypted using the above encryption key, preferably the encrypted data is again converted to Base36 in order to make most efficient use of the data size.
byte[] encBytes = encrypt(demonstrationPublicKey, StringUtil.getUTF8Bytes(sb.toString()), issuingAirlineCode, deptAirportCode, arrAirportCode, carrier, flightNumber, pnr, dayOfT ravel);
Biglnteger biglnt = new Biglnteger(1, encBytes);
return 1 + StringUtil.lpad(biglnt.toString(36).toUpperCase(), 50, O');
The encrypted data is then added to the boarding pass data stream and the boarding pass data stream is digitally signed. The encrypted data may be added to an area in the boarding pass data stream that is reserved for airline use such that the boarding pass will still be readable by existing systems. The signature is preferably computed on the entire boarding pass data stream, including the encrypted user identity data. In this example, a 1 has been prepended to the data to signify it is encrypted.
Accordingly, the third aspect of the disclosure provides a system similar to the first aspect of the disclosure, but which also has the further advantage whereby the system 48 can prompt the user with some details about the identity document data to be presented in order for authentication of the boarding pass.

Claims (54)

1. A system for generating a non-transferrable access token, the system comprising: a first receiver device configured to receive access token data and user identity information;
an encryption unit configured to perform a one-way hash function on the user identity information to generate a one-way hash; and a token generating unit configured to generate a non-transferrable token comprising the access token data and the one-way hash;
wherein the system is configured to generate a non-transferrable access token that is authenticated by receiving further identity information, performing the one-way hash function on the further user identity information to generate a further one-way hash, comparing the one-way hash and the further one-way hash, and authenticating the nontransferrable access token if the one-way hash and the further one-way hash are determined to match.
2. The system of claim 1, wherein the encryption unit is configured to perform the oneway hash function on user identity information that uniquely identifies a given individual that has been issued the non-transferrable access token.
3. The system of claim 1 or 2, wherein the encryption unit is configured to perform the one-way hash function on user identity information comprising one or more of: passport information, a personal identification number, biometric data, a credit card number, address data, a drivers licence number, a private cryptography key or date of birth and gender.
4. The system of any preceding claim, wherein the encryption unit is configured to perform the one-way hash function on user identity information in combination with access token data to generate the one-way hash.
5. The system of any preceding claim, wherein the token generating unit is configured to generate the non-transferrable access token further comprising an encoded identification of the type of user identity information used to generate the one-way hash.
6. The system of any preceding claim, wherein the one-way hash function is a cryptographic hash function.
7. The system of any preceding claim, wherein the token generating unit is configured to generate the non-transferrable access token forming a boarding pass for access to a flight on an aircraft.
8. The system of claim 7, wherein the token generating unit is configured to record the one-way hash in an airline custom field of the boarding pass.
9. The system of any preceding claim, wherein the token generating unit is further configured to digitally sign the non-transferrable access token comprising the access token data and the one-way hash.
10. The system of any of claims 1 to 8, wherein the token generating unit is further configured to digitally sign the non-transferrable access token based on the access token data and wherein the one-way hash is only recorded on the non-transferrable access token in the digital signature.
11. A system for authenticating a non-transferrable access token, the system comprising:
a reader device configured to read a non-transferrable access token comprising access token data and a one-way hash of user identity information;
a second receiver device configured to receive further identity information; an encryption unit configured to perform a one-way hash function on the further identity information to generate a further one-way hash; and a comparator unit configured to compare the one-way hash and the further one-way hash;
wherein the comparator unit is configured to authenticate the non-transferrable access token if the one-way hash and the further one-way hash are determined to match.
12. The system of claim 11, wherein the encryption unit is configured to perform the one-way hash function on further identity information that uniquely identifies a given individual that has been issued the non-transferrable access token.
13. The system of claim 11 or 12, wherein the encryption unit is configured to perform the one-way hash function on further identity information comprising one or more of: passport information, a personal identification number, biometric data, a credit card number, address data, a drivers licence number, a private cryptography key, or date of birth and gender.
14. The system of any of claims 11 to 13, wherein the encryption unit is configured to perform the one-way hash function on further identity information in combination with access token data, from the non-transferrable access token, to generate the one-way hash.
15. The system of any of claims 11 to 14, further comprising a user output; wherein the reader device is further configured to read an identification, encoded in the nontransferrable access token, of the type of user identity information used to generate the one-way hash; and wherein the user output is configured to output the type of user identity information to the user.
16. The system according to any of claims 11 to 15, wherein the second receiver device is further configured to receive the further identity information from one of a presented identity document or a user input.
17. The system according to any of claims 11 to 15, wherein the second receiver device is further configured to receive a secondary identification from a user and to retrieve the further identity information from a database, wherein the further identity information is associated with the secondary identification.
18. The system according to claim 17, wherein the secondary identification is received from the user in the form of a result of a biometric scan of the user.
19. The system of any of claims 11 to 18, wherein the encryption unit is further configured to determine a digital signature based on a data content of the non-transferrable access token; wherein the reader device is further configured to read a digital signature from the non-transferrable access token; and the comparator unit is further configured to compare the determined digital signature and the read digital signature in order to further authenticate the integrity of the non-transferrable access token.
20. The system of claim 19, wherein the one-way hash of the user identity information is recorded on the non-transferrable access token as a part of the digital signature configured to be read by the reader device; and wherein the encryption unit is configured to determine the digital signature based on a combination of the data content of the non-transferrable access token and the further one-way hash.
21. The system of any of claims 11 to 20, further comprising a one-way hash storage unit; wherein the comparator unit is further configured to compare the one-way hash with each one-way hash stored in the one-way hash storage unit and to only authenticate the non-transferrable access token if the one-way hash is determined not to match any of the one-way hashes stored in the one-way hash storage unit; and wherein the one-way hash storage unit is configured to store the one-way hash once the non-transferrable access token has been authenticated.
22. A method for generating a non-transferrable access token, the method comprising: receiving, at a first receiver device, access token data and user identity information; performing, at an encryption unit, a one-way hash function on the user identity information to generate a one-way hash; and generating, at a token generating unit, a non-transferrable token comprising the access token data and the one-way hash;
wherein the method generates a non-transferrable access token that is authenticated by receiving further identity information, performing the one-way hash function on the further user identity information to generate a further one-way hash, comparing the one-way hash and the further one-way hash, and authenticating the nontransferrable access token if the one-way hash and the further one-way hash are determined to match.
23. The method of claim 22, wherein the one-way hash function is performed on user identity information that uniquely identifies a given individual that has been issued the nontransferrable access token.
24. The method of claim 22 or 23, wherein the one-way hash function is performed on user identity information comprising one or more of: passport information, a personal identification number, biometric data, a credit card number, address data, a drivers licence number, a private cryptography key, or date of birth and gender.
25. The method of any of claims 22 to 24, wherein the one-way hash function is performed on the user identity information in combination with access token data to generate the one-way hash.
26. The method of any of claims 22 to 25, wherein the generated non-transferrable access token further comprises an encoded identification of the type of user identity information used to generate the one-way hash.
27. The method of any of claims 22 to 26, wherein the one-way hash function is a cryptographic hash function.
28. The method of any of claims 22 to 27, wherein the generated non-transferrable access token forms a boarding pass for access to a flight on an aircraft.
29. The method of claim 28, wherein the one-way hash is recorded, by the token generating unit, in an airline custom field ofthe boarding pass.
30. The method of any of claims 23 to 29, wherein the non-transferrable access token comprising the access token data and the one-way hash is signed at the token generating unit.
31. The method of any of claims 22 to 29, wherein the non-transferrable access token is digitally signed, by the token generating unit, based on the access token data and wherein the one-way hash is only recorded on the non-transferrable access token in the digital signature.
32. A method for authenticating a non-transferrable access token, the method comprising:
reading, at a reader device, a non-transferrable access token comprising access token data and a one-way hash of user identity information;
receiving, at a second receiver device, further identity information; performing, at an encryption unit, a one-way hash function on the further identity information to generate a further one-way hash; and comparing, at a comparator unit, the one-way hash and the further one-way hash; wherein the non-transferrable access token is authenticated, by the comparator unit, if the one-way hash and the further one-way hash are determined to match.
33. The method of claim 32, wherein the one-way hash function is performed, by the encryption unit, on further identity information that uniquely identifies a given individual that has been issued the non-transferrable access token.
34. The method of claim 32 or 33, wherein the one-way hash function is performed, by the encryption unit, on further identity information comprising one or more of: passport information, a personal identification number, biometric data, a credit card number, address data, a drivers licence number, a private cryptography key, or date of birth and gender.
35. The method of any of claims 32 to 34, wherein the one-way hash function is performed, by the encryption unit, on further identity information in combination with access token data, from the non-transferrable access token, to generate the one-way hash.
36. The method of any of claims 32 to 35, further comprising reading, at the reader device, an identification, encoded in the non-transferrable access token, ofthe type of user identity information used to generate the one-way hash; and wherein the type of user identity information is output, by a user output, to the user.
37. The method according to any of claims 32 to 36, further comprising receiving, at the second receiver, the further identity information from one of a presented identity document or a user input.
38. The method according to any of claims 32 to 36, further comprising receiving, at the second receiver, a secondary identification from a user and retrieving the further identity information from a database, wherein the further identity information is associated with the secondary identification.
39. The method according to claim 38, wherein the secondary identification is received from the user in the form of a result of a biometric scan of the user.
40. The method of any of claims 32 to 39, further comprising determining, at the encryption unit, a digital signature based on a data content of the non-transferrable access token; reading, at the reading device, a digital signature from the non-transferrable access token; and comparing, at the comparator unit, the determined digital signature and the read digital signature in order to further authenticate the integrity of the non-transferrable access token.
41. The method of claim 40, wherein the one-way hash of the user identity information is recorded on the non-transferrable access token as a part of the digital signature configured to be read by the reader device; and wherein the digital signature is determined based on a combination of the data content of the non-transferrable access token and the further one-way hash.
42. The method of any of claims 32 to 41, further comprising comparing, at the comparator unit, the one-way hash with each one-way hash stored in a one-way hash storage unit; further comprising only authenticating the non-transferrable access token if the one-way hash is determined not to match any of the one-way hashes stored in the oneway hash storage unit; and further comprising storing, in the one-way hash storage unit, the one-way hash once the non-transferrable access token has been authenticated.
43. A system for generating a non-transferrable access token, the system comprising: a first receiver device configured to receive access token data and user identity information;
an encryption unit configured to generate a symmetric encryption key based on a public key and at least a subset of the access token data and to encrypt the user identity information using the symmetric encryption key; and a token generating unit configured to generate a non-transferrable token comprising the access token data and the encrypted user identity information;
wherein the system is configured to generate a non-transferrable access token that is authenticated by decrypting the user identity information, receiving further identity information, comparing the user identity information and further identity information, and authenticating the non-transferrable access token if the user identity information and the further identity information are determined to match.
44. The system of claim 43, wherein the first receiver device is configured to receive the user identity information comprising a user identity information type.
45. The system of claim 43 or 44, wherein the token generating unit is further configured to digitally sign the non-transferrable access token comprising the access token data and the encrypted user identity information.
46. A system for authenticating a non-transferrable access token, the system comprising:
a reader device configured to read a non-transferrable access token comprising access token data and encrypted user identity information;
a second receiver device configured to receive further identity information; an encryption unit configured to generate a symmetric encryption key based on a public key and at least a subset of the access token data and to decrypt the encrypted user identity information using the symmetric encryption key; and a comparator unit configured to compare the decrypted user identity information and the further identity information;
wherein the comparator unit is configured to authenticate the non-transferrable access token if the decrypted user identity information and the further identity information are determined to match.
47. The system according to claim 46, wherein the decrypted user identity information comprises a user identity information type and wherein the system is further configured to output a user prompt identifying the expected user identity information type for the further identity information to be received at the second receiver device.
48. The system of claim 47, wherein the user prompt further comprises a partial indication of the user identity information.
49. A method for generating a non-transferrable access token, the method comprising: receiving, a first receiver device, access token data and user identity information; generating, at an encryption unit, a symmetric encryption key based on a public key and at least a subset of the access token data and encrypting the user identity information using the symmetric encryption key; and generating, at a token generating unit, a non-transferrable token comprising the access token data and the encrypted user identity information;
wherein the method generates a non-transferrable access token that is authenticated by decrypting the user identity information, receiving further identity information, comparing the user identity information and further identity information, and authenticating the non-transferrable access token if the user identity information and the further identity information are determined to match.
50. The method of claim 49, further comprising receiving, at the first receiver device, the user identity information comprising a user identity information type.
51. The method of claim 49 or 50, further comprising digitally signing, at the token generating unit, the non-transferrable access token comprising the access token data and the encrypted user identity information.
52. A method for authenticating a non-transferrable access token, the method comprising:
reading, at a reader device, a non-transferrable access token comprising access token data and encrypted user identity information;
receiving, at a second receiver, further identity information;
generating, at an encryption unit, a symmetric encryption key based on a public key and at least a subset of the access token data and decrypting the encrypted user identity information using the symmetric encryption key; and a comparator unit configured to compare the decrypted user identity information and the further identity information;
wherein the comparator unit is configured to authenticate the non-transferrable access token if the decrypted user identity information and the further identity information are determined to match.
53. The method according to claim 52, wherein the decrypted user identity information comprises a user identity information type and wherein the method further comprises outputting a user prompt identifying the expected user identity information type for the further identity information to be received at the second receiver device.
54. The method of claim 53, wherein the user prompt further comprises a partial indication of the user identity information.
Intellectual
Property
Office
Application No: GB1706650.7 Examiner: Dr Laurence Drummond Claims searched: 1-42 Date of search: 25 October 2017
GB1706650.7A 2017-04-26 2017-04-26 System and method for authenticating a non-transferrable access token Withdrawn GB2561875A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
GB1706650.7A GB2561875A (en) 2017-04-26 2017-04-26 System and method for authenticating a non-transferrable access token

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
GB1706650.7A GB2561875A (en) 2017-04-26 2017-04-26 System and method for authenticating a non-transferrable access token

Publications (2)

Publication Number Publication Date
GB201706650D0 GB201706650D0 (en) 2017-06-07
GB2561875A true GB2561875A (en) 2018-10-31

Family

ID=58795565

Family Applications (1)

Application Number Title Priority Date Filing Date
GB1706650.7A Withdrawn GB2561875A (en) 2017-04-26 2017-04-26 System and method for authenticating a non-transferrable access token

Country Status (1)

Country Link
GB (1) GB2561875A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2567932A (en) * 2017-10-25 2019-05-01 Google Llc Privacy-preserving identity verification

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112000951B (en) * 2020-08-31 2024-05-17 上海商汤智能科技有限公司 Access method, device, system, electronic equipment and storage medium

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040162787A1 (en) * 2001-06-06 2004-08-19 Justin Madison System and method for controlling access to digital content, including streaming media
US20050021474A1 (en) * 2003-07-24 2005-01-27 Geist Bruce K. System for authenticating self-authenticating documents
US7093130B1 (en) * 2000-01-24 2006-08-15 The Regents Of The University Of California System and method for delivering and examining digital tickets
US20080133924A1 (en) * 2004-08-23 2008-06-05 Siemens Aktiengesellschaft Method for Checking Electronic Authorizaiton Inspection Information, Tester and Computer Program
US20110246369A1 (en) * 2010-03-30 2011-10-06 De Oliveira Marcelo Gomes Event access with data field encryption for validation and access control
WO2017136879A1 (en) * 2016-02-08 2017-08-17 Moloney Lindsay A system and method for document information authenticity verification

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7093130B1 (en) * 2000-01-24 2006-08-15 The Regents Of The University Of California System and method for delivering and examining digital tickets
US20040162787A1 (en) * 2001-06-06 2004-08-19 Justin Madison System and method for controlling access to digital content, including streaming media
US20050021474A1 (en) * 2003-07-24 2005-01-27 Geist Bruce K. System for authenticating self-authenticating documents
US20080133924A1 (en) * 2004-08-23 2008-06-05 Siemens Aktiengesellschaft Method for Checking Electronic Authorizaiton Inspection Information, Tester and Computer Program
US20110246369A1 (en) * 2010-03-30 2011-10-06 De Oliveira Marcelo Gomes Event access with data field encryption for validation and access control
WO2017136879A1 (en) * 2016-02-08 2017-08-17 Moloney Lindsay A system and method for document information authenticity verification

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2567932A (en) * 2017-10-25 2019-05-01 Google Llc Privacy-preserving identity verification
US10764051B2 (en) 2017-10-25 2020-09-01 Google Llc Privacy-preserving identity verification

Also Published As

Publication number Publication date
GB201706650D0 (en) 2017-06-07

Similar Documents

Publication Publication Date Title
US9369287B1 (en) System and method for applying a digital signature and authenticating physical documents
US11151260B2 (en) Providing and checking the validity of a virtual document
JP6768960B2 (en) 2D barcode processing methods, devices, and systems
US8086867B2 (en) Secure identity and privilege system
US8775814B2 (en) Personalized biometric identification and non-repudiation system
JP2019219780A (en) Personal information management system, and service providing system, method and program
US20110289318A1 (en) System and Method for Online Digital Signature and Verification
KR20120050957A (en) Method for producing a soft token
MX2015002929A (en) Method and system for verifying an access request.
JP6504639B1 (en) Service providing system and service providing method
WO2011005869A2 (en) Method and system for generating and using biometrically secured embedded tokens in documents
US20240048395A1 (en) Method and system for authentication credential
GB2561875A (en) System and method for authenticating a non-transferrable access token
CN112823350A (en) Method and system for a monocular public key for a public ledger
US20120198238A1 (en) Method for establishing an electronic authorization for a user bearing an electronic identity document, and method for supervising said authorization
US8804158B2 (en) Token generation from a printer
CN110111461A (en) A kind of pass identified off-line method and apparatus based on two dimensional code
JPH11339045A (en) Method for confirming and issuing electronic data, executing device therefor, medium recorded with processing program therefor and electronic data recording medium
Gangurde et al. Ticketing system using AES encryption based QR code
CN110192194B (en) System and method for authenticating security certificates
KR100698517B1 (en) Electronic Passport based on PKI Digital Signature Certificate
WO2014182157A1 (en) Electronic ticket booking with improved privacy
US20230385391A1 (en) Method and device for remotely signing and certifying a person&#39;s identification data
US12099776B2 (en) Visual verification of virtual credentials and licenses
CN116349198B (en) Method and system for authenticating credentials

Legal Events

Date Code Title Description
WAP Application withdrawn, taken to be withdrawn or refused ** after publication under section 16(1)