Patent Application
20210081923
This invention relates to a method of and apparatus for authentication and authorisation, and in particular to the use of authentication and authorisation word strings, such as may be spoken for example during a telephone call or other verbal communication. The invention also relates to a system providing reasonable to strong authentication for use in the transmission of sensitive information, as may be used in financial systems, especially for the processing of payments, or when dealing with or authorising the use of personally identifiable information for processing or authentication.
In many situations it is necessary to provide some form of authentication and/or authorisation. For example, a service provider may require a prospective user of the service to confirm their identity to ensure that the user requesting the service is not attempting to use the service fraudulently by assuming the identity another user.
Authentication generally requires a user to provide some identifying evidence based on at least one of three factors or identifiers: something known (such as a password, passcode or passphrase—the terms are often used interchangeably), something owned (such as a smartcard or smartphone) or something inherent (such a biometric property, for example a fingerprint).
Traditionally, for many applications use of a single authentication factor has been considered sufficient (eg. a password to access a computer system); however, with increasing security concerns has become increasingly common to use two factor authentication (2FA), where a user requires two types of factor or identifier (for example, possession of a specific user smartphone and knowledge of a passcode) in order to be authenticated. Generally, the term multi-factor authentication (MFA) is used when more than one factor is required for authentication.
Secure authentication is especially important for financial transactions, where it is required to confirm that the means of payment being used belong to the person making the payment. Secure authentication may also be required when dealing with sensitive or personally identifiable information. This has led to a number of developments, including:
Financial regulations such as such as PSD2 may require the use of MFA and/or OOBA. Specifically, PSD2 requires payments to use Strong Customer Authentication (SCA) with authentication based on the use of two or more identifying elements which are independent. This ensures that a breach in the security of one element does not compromise the other(s). Furthermore, the SCA architecture as a whole is designed in such a way as to protect the confidentiality of the authentication data.
Another area in which authentication is required is during voice communication, for example during a telephone call such as when a caller is in communication with an agent at a contact centre. The process of authentication is complicated by the limitations inherent with using a voice channel for communication, coupled with the use of a potentially untrustworthy human intermediary.
Schemes such as that previously developed by the applicant (described in international PCT patent application WO2009136163) allow the caller to input sensitive payment card details during the call via the telephone keypad, the resulting DTMF tones being transmitted in the voice channel, the sensitive information being extracted from the tones by a call processor which relays the payment information to an authorisation or other external entity while blocking at least some DTMF tones from the agent and thereby preventing the sensitive information being disclosed to the agent.
Common to all the above schemes is the requirement for the user to input a passcode or other sensitive information via a keypad. This is not always practical.
There is therefore a need for an authentication/authorisation scheme which may be used in the voice channel and which does not require use of a keypad, preferably one which can use voice alone.
This is to be distinguished from purely biometric or ‘voice-print’ authentication schemes which are based on identifying characteristics of the user's voice. Such systems are especially sensitive to the quality of the voice channel, being prone to false-positive or false-negative authentication errors. They are also vulnerable to the nefarious use of voice imitating equipment.
Such an authentication scheme would ideally be sufficiently secure. Password strength in often described terms of information entropy, measured in bits. For a random password of length L bits, chosen from N possible symbols, the password entropy H is given by the base 2 logarithm of the number of possible combinations NL, ie.
At present, password strengths are rated approximately as follows:
Hence a typical 6-digit numeric PIN (entropy: 19.9 bits) is considered very weak. A ten digit numeric string, comprising a 4-digit user PIN in combination with a 6-digit numeric PIN (entropy: 33.2 bits) is still considered weak, despite being a relatively long string and therefore difficult to communicate correctly.
It is known that using words as the symbols increases the symbol space notably and therefore allows for strong passwords—or rather pass phrases—which are also memorable. For example, the Diceware methodology, based on a list of 65 =7776 words, generates pass phrases with an entropy of 12.9 bits per word.
According to an aspect of the invention there is provided a method (preferably, performed by an authentication server) of authenticating a request made by a first party of a second party, comprising: receiving from the first party a request and a first symbol string obtained by the first party from the second party, the first symbol string being determined from the request; generating a second symbol string in dependence on the request; authenticating the request of the first party in dependence on the first and second symbol strings.
Preferably, authenticating the request of the first party comprises: comparing and determining the degree of similarity between the first and second symbol strings.
Preferably, the method further comprises authenticating the request when the degree of similarity is determined to be at least 90%, 95%, 99% or more, preferably within a confidence level of at least 90%, 95%, 99% or more, more preferably wherein the first and second symbol strings are determined to be identical.
Preferably, the first symbol string is obtained by the first party from the second party via a voice channel, preferably as spoken words.
Preferably, the method further comprises transmitting information regarding the request to the second party.
Preferably, the information regarding the request is transmitted to the second party by the first party; more preferably, the information further comprises an identifier for the first party; yet more preferably, the identifier for the first party is a temporary identifier for use only for the specific request.
Preferably, the information regarding the request is used by the second party for generating the first symbol string.
Preferably, transmitting information regarding the request to the second party is via a communications channel other than that used for obtaining the first symbol string from the second party by the first party.
Preferably, the method further comprises generating the first symbol string and transmitting said first symbol string to the second party.
Preferably, the method further comprises issuing an authentication token in dependence on authentication of the request; and forwarding the authentication token to an external entity.
Preferably, the authentication token is useable by the external entity in lieu of further authentication of the request.
Preferably, the authentication token is useable only a limited number of times by the external entity, for example only five, four, three, two times or only once, and/or only for a limited time.
Preferably, the first symbol string is useable for authenticating the request only a limited number of times, for example only five, four, three, two times or only once.
Preferably, the first symbol string is useable for authenticating the request only for a limited time.
According to another aspect of the invention thee is provided a method (preferably, performed by a second party, for example a user device such as a smartphone) of authorising a request, comprising: receiving a request from a first party; and transmitting to the first party a symbol string to authorise the request; wherein the symbol string is determined in dependence on the request.
Preferably, the method further comprises generating the symbol string.
Preferably, the method further comprises receiving the symbol string from a third party. Preferably, the symbol strings comprise sequences of words, preferably at least three words.
The words may be selected from a dictionary, wherein the dictionary comprises words which do not have one or more of the following characteristics: a) more than N letters (preferably, where N is 10, 9, 8, 7, 6 or 5); b) fewer than M letters (preferably, where N is 3, 2 or 1); c) are difficult to pronounce or spell; d) sound similar when pronounced to other words in the dictionary; and e) do not relate to a common theme.
Preferably, the first party comprises a merchant or voice assistant, the second party comprises a user or user device such as a smartphone or voice assistant, the third party comprises an authentication server, and the request made by the first party of the second party comprises a request for a service or a payment.
Preferably, the external entity comprises a service provider, payment or account service provider.
According to another aspect of the invention there is provided apparatus for carrying out the method as herein described.
According to another aspect of the invention there is a provided a dictionary assembled according to the method herein described.
Also disclosed is a method of authentication comprising the use of one-time authentication symbol strings, preferably wherein successful authentication results in the issue of a time-based access token.
Preferably the authentication symbols are selected from a dictionary of symbols, preferably an optimised dictionary wherein the component symbols have been selected in dependence on their ease of transmission and/or understanding.
Preferably the authentication symbols comprise words.
Also disclosed is a method of authentication, comprising the generation and comparison of ephemeral candidate word strings to authenticate payments in both online and offline scenarios, using pre-identified time segments, the transaction value and other cryptographic methods to prevent an adversary from equally attempting to guess and generate stings to authenticate unauthorised payments.
These candidate words strings may be for use as a time-based one-time token, authenticating against a separate web-based federation and authentication service, preferably with a limited number of access attempts and more preferably with sufficiently gated or limited access.
In some embodiments, strings of one or more words, each comprising a predetermined, preferably a maximum, number of letters, form a token with reasonable password entropy.
Each token may be calculated separately using different sources of entropy to safeguard against an outside adversary successfully brute-force attacking or generating a single token, whilst all other previous (which will have expired) and subsequent tokens retain their attribute to be computationally difficult to calculate.
The subset dictionary (from which the word strings may be derived) may comprise small, simple words with a limited length, rather than a subset of all words.
Word strings may be used to replace PIN-based authentication for the voice channel.
The word strings may be authenticated by an authentication server or federation service, preferably over a computer network, separate to and away from the voice channel.
A plug-in for an electronic wallet may be used to allow access to bank details for payments.
Preferably, payment cards are each assigned or have determined a seed key to act as a source of entropy for the authentication word string generation algorithm(s).
The invention may provide for an authenticating-only and/or authorising-only payment method.
The authentication and/or authorising may relate to—or be limited to—a specific payment.
Preferably, the authentication server or federation service does not have access to any payment means. Instead, the user request is authenticated by the authentication server on behalf of a third party (a payment provider) which makes the payment. Separating the authentication and payment functions may allow the payment provider to outsource the requirements for meeting authentication regulations.
Authentication and/or authorisation based on word strings as herein described may provide for a more efficient user authentication process as immediate recall is likely greater for a string of words than for a string of random characters. A passcode provided to a user via a smartphone is therefore more onerous for a user to read and recall than would be a word string.
Additionally, input errors may be more easily detected (and optionally corrected) from a mistyped word then from a mistyped passcode.
As used herein:
Further features of the invention are characterised by the dependent claims.
The invention also provides a computer program and a computer program product for carrying out any of the methods described herein, and/or for embodying any of the apparatus features described herein, and a computer readable medium having stored thereon a program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein.
The invention also provides a signal embodying a computer program for carrying out any of the methods described herein, and/or for embodying any of the apparatus features described herein, a method of transmitting such a signal, and a computer product having an operating system which supports a computer program for carrying out the methods described herein and/or for embodying any of the apparatus features described herein.
The invention extends to methods and/or apparatus substantially as herein described with reference to the accompanying drawings.
Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied apparatus aspects, and vice versa.
Equally, the invention may comprise any feature as described, whether singly or in any appropriate combination.
Furthermore, features implemented in hardware may generally be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly.
The invention will now be described, purely by way of example, with reference to the accompanying drawings, in which:
In use, service provider 18 will only provide a requested service to user 12 if a valid user authentication is provided by the authentication server 16.
In some embodiments, the agent 14 may be replaced by an interactive voice response (IVR) system and/or the authentication server 16 equipped with speech or voice recognition capability in order to determine words spoken by the user.
Generally, the authentication process comprises the generation of an authentication word string (AWS), the component words selected from an authentication dictionary (AD) in dependence on features of the request, and the user 12 transmitting the authentication word string to the authentication server 16 either directly or via the agent 14. Authentication server 16 then attempts to authenticate the user on the basis of the received authentication word string AWS by comparison with an expected word string (EWS) and, if the match is successful, sends an authentication confirmation message or service request message directly to the service provider 18 and/or via the agent 14 to confirm that the request is legitimate and that the service may be provided to the user 12.
Typically, for many practical applications, the authentication word string (AWS) may comprise three relatively short words, hence may be referred to as “three little words” (3LW).
In some embodiments, as described below, successful authentication results in the generation of an access token (T), preferably time-limited, which is then used in lieu of further authentication.
A typical implementation of the authentication system comprises a user with a device such as a smartphone or a voice assistant, in voice communication with an agent at a contact centre, the agent having access to an authorisation interface of the authorisation server, the smartphone having installed a software application for generating the authentication word string. The skilled person will appreciate many other possible embodiments making use of aspects of the authentication process, some of which are discussed in the following.
In some embodiments, the authentication system is used for reverse-authentication, whereby for example the merchant seeks to authenticate with the caller. This is described in detail later in this document.
Variations on the above are described below, as are processes for generating the authentication dictionary and the authentication word string.
This method may be used as part of a multi factor authentication (MFA) process, where the use of this method constitutes one factor, ie. proof of possession of a particular smartphone. Additional factors may be provided as part of the authentication process, for example requiring the user to provide a password or a biometric such as a thumbprint in order to generate an authentication word string.
This method may also be used to provide out-of-band authentication (OOBA), whereby the authentication channel (eg. a spoken voice telephone channel) is separate from the channel used for transmitting the sensitive information (eg. a computer network data channel).
More detailed variants which make use of the authentication process are described below.
As shown, user 12 makes use of an electronic wallet (eWallet) 416 for making payments and storing personally identifiable information. The eWallet may be stored remotely, ie. in the ‘cloud’.
The authentication process is governed by software application which may be provided locally at the user computing devices 404 and/or remotely eg. integrated with the eWallet software, for example as a plugin 418.
The user 12 may have both online and offline options for providing authentication to the merchant contact centre 14, depending on the particulars of the payment and availability or otherwise of a network connection.
Interactions are shown between the merchant 14, a Payment Initiation Service Provider (PISP) 412, an Account Servicing Payment Service Provider (ASPSP) 420, and the authentication server 16.
In this embodiment, the merchant does not communicate directly with the authentication server. Instead, user authentication is provided to the PISP, which in turn authorises an ASPSP to make a payment to a merchant.
b. Authentication Fail
In these online examples, as previously described, the payment request from the merchant 14 is routed via the authentication server 16. The authentication server 16 sends payment details together with a merchant identifier MID to the user 12 who, presumably being agreeable to making the payment, selects a payment method (such as a payment card from an eWallet, providing local authentication if required), generates an authorisation word string (AWS/3LW), and provides it over the voice channel to the merchant 14, who forwards it (preferably over a computer network rather than via voice) to the authentication server 16 for validation/confirmation by comparison with an expected word string EWS.
A potential advantage for PSP transactions is that use of AWS authentication may allow for separation of the data used to authorise payment between different channels (voice and data) as required by some financial regulations.
The user 12 will previously have registered a payment method with the authorisation server.
The user 12, who is presumably agreeable to making the payment, selects a payment method (such as a card from an eWallet, providing local authentication if required), enters the merchant identifier (MID) and payment amount, thereby generating an authorisation word string AWS/3LW, and provides the AWS/3LW over the voice channel to the merchant 14, who forwards it (along with the user phone number, MID and amount, preferably over a computer network rather than via voice) to the authentication server 16 for validation/confirmation by comparison of the AWS/3LW with the expected word string EWS.
A strong customer authentication (SCA) success notification, indicating that multi factor authentication (MFA) over multiple separate channels has been used, may also be transmitted by the authentication server 16 to the PISP 412. Such a success notification would indicate to the PISP a measure of the security of the authentication means used.
Generally, the system comprises the following components:
Alternative embodiments, have the various features distributed differently amongst the components.
The sequence diagrams make use of the following acronyms:
During User Enrolment the service may also support the ability of instead of using pre-generated key tables to use a single pre-shared high entropy seed that will be used to generate unique keys for each transaction. Transaction keys will preferably be:
Pre-shared seed generated would be held on a HSM when on the Federation Server.
The user is assumed to have already enrolled with the authentication server and to have an account with a payment server.
The user is assumed to have already enrolled with the authentication server and to have registered a payments method.
The merchant will preferably have previously registered with the server, in a similar way to a user, such that merchant details are stored by the authentication server in the merchant database.
User selection of the payment method
Merchant payment request
User acceptance of the payment request
Authentication word string—User
An alternative to the 3LW generation is outlined and this approach splits the token generation into three different phases:
Transaction Key Generation
Given the pre-shared seed KT, a transaction key Kt with key index Idx, time code tc, merchant PIN MPIN, and transaction PIN TPIN (an additional, user chosen, 4 to 8 digit code) can be generated as follows:
K
t=KDF(KT, Idx∥tc∥∥MPIN∥TPIN)
In the above:
A key generation technique equivalent to the optionally proposed use of key tables can be recovered by not including tc, MPIN or TPIN in the computation. However, including them serves to mitigate online dictionary attacks by parties who hold the pre-shared seed (the User and Federation Server). Barring collusion, each of these parties controls at most one of the key derivation's auxiliary inputs (tc, MPIN and TPIN), which can therefore be used to make the attacker's task more costly. The additional user-selected auxiliary input TPIN provides this protection to the user.
Note that the Idx is used to prevent an adversary from starting the attack offline (by including transaction-specific information in the key derivation), slowing down the process through which transaction keys are generated (using PBKDF2 or a similarly designed KDF or password-hashing function), and forcing incrementation of the key index Idx on failure.
Authentication word string-Merchant
User and merchant notifications
The process is initially similar to that for an online payment, where a user confirms order details and selects a payment card, except that:
Instead, the merchant relays via the voice channel a one-time merchant identifier MPIN, valid only for the specific transaction, to the user for the user to input via the ewallet UI and to be used in the generation of the authentication word string.
The MPIN is likewise used by the server 3LW module to generate the corresponding expected authentication word string (EWS).
Similarly, without connectivity notifications cannot be immediately sent via the server wallet API to the ewallet payment method module. Instead, the notification remains stored in the server notifications module until the next time the user device connects to the authentication server.
This allows for a merchant to confirm to a user that they are genuine—and more generally for a user to guard against fraudulent parties which is a common issue for outbound banking or insurance telephone calls.
Generally, the process involves the merchant presenting to the user a one-time passphrase or authentication word string based on merchant and user identifiers which can be separately confirmed by the user.
The process proceeds as follows:
In some embodiments, the authentication word string is not transmitted to the user device but rather only call and merchant details are transmitted such that the user device itself determines the expected authentication word string.
An authentication word string AWS for voice transmission preferably comprises distinct words which are easy to pronounce and difficult to confuse with other similar sounding or similarly spelt words.
Creation of an authentication dictionary generally proceeds via the following sequence of steps:
The above process results in an authentication dictionary which is especially suitable for vocal transmission of words, as selection is partly based upon pronunciation 808 and removing similar sounding words 810.
Any other undesirable sets of words may also be removed, for example offensive words, copyrighted words, or words which are difficult to read, write (for example words containing letters which are difficult to reach on a keyboard), hear, or explain. The authentication dictionary may comprise words according to a subject or theme.
The user may be able to add or remove words from a list, this would allow a user to form a personalised dictionary of words that they find easy to remember or pronounce. Such a personalised dictionary may also be used to increase the security of the method, as any malicious third party may need to acquire this dictionary to attempt to replicate authentication words.
Words may also be added into the list before or after any step. Words that have been removed may be reintroduced, for example, words which do not follow a theme 814 may be included if they are nevertheless easy to pronounce.
Any combination of the word removal/addition steps may be performed in any order, or omitted.
Copies of the authentication dictionary are made accessible to both the user and the authentication server, potentially stored in different formats in the same or at different locations, preferably downloaded in whole or in part to local storage
In some embodiments, a master authentication dictionary is created from which each user may create a personal authentication dictionary.
In some embodiments, authentication dictionaries may be regularly updated, for example every day, or every week, or upon an event, for example a dictionary may be updated after being used a maximum number of times.
Whereas an (English) dictionary may contain in excess of 100,000 words, an authentication dictionary AD created by the above process may contain only 20,000 or 22,000 words, potentially 4,000 to 5,000 words, say approximately 4,100 words. Generally, an authentication dictionary may be of any size. For example, a small dictionary may be desirable as it will take up only a small amount of storage space on a user device.
The size of the authentication dictionary may relate to the security of the authentication/authorisation process, ie. for an authentication word string comprising a given a number of words, use of a smaller dictionaries may result in lower password entropy than a larger dictionary.
The security of the authentication/authorisation process may also depend upon other features of the dictionary, such as the commonality of words (where a dictionary containing seldom used words may be considered to be more secure), or the number of different languages used.
The authentication dictionary may in some embodiments be selected by the merchant, for example to ensure a specific level or degree of security in view of the type or size of the transaction.
Authentication dictionaries of different sizes may be generated to provide different single-word entropies. The generation of dictionaries generally involves selection of suitable words and the factors considered for word selection may include suitability for speech recognition/generation technologies, ie. the authentication dictionary may be optimised for one or both of speech recognition/generation.
The remaining words are saved as the authentication dictionary 818.
The sets of removed words may overlap, as words which are difficult to spell may also be difficult to pronounce. Any set of removed words may, or may not, overlap with any other set, save for the sets of words with greater than N letters 864 and fewer than M letters 866, which sets are chosen to be distinct else the authentication dictionary would be an empty set.
In some embodiments, there may be a minimum number of words required in a dictionary. This may improve security as a larger dictionary has a higher number of potential authentication word strings.
In some embodiments a dictionary is generated immediately before the authentication word string is generated. A method of generating such a dictionary may use ‘tags’, wherein each word in an existing dictionary is ‘tagged’ with related information, such as the number of letters in a word, the spelling or pronunciation difficulty or how common the word is in everyday language. Words with certain tags, for example words of a certain length, or spelling difficulty, may be selected from an existing dictionary to create a new dictionary. Generating dictionaries in this way enables dictionaries to be formed for a variety of scenarios. The user may select tags to be used, or the tags used may depend upon the transaction or transmission channel. Using tags, a large dictionary of words and/or sentences may be downloaded, and a smaller dictionary suitable for a particular transaction created immediately before the word string is generated.
In some embodiments, the dictionary may contain sentences instead of words (or a combination of sentences and words). This may be used to create a more memorable word string, as a sentence may be more memorable than a word string comprised of random words.
When using offline authentication the authentication server 16 cannot transmit information to the user 12, this may result in additional information, such as a dictionary of possible authentication words, being required to be stored upon a user device. As this information takes up storage space on the user device, there may be stored only a subset of information which can be used in the generation of the authentication word string, for example a limited dictionary from which authentication word strings are chosen may be stored. Offline authentication may require a greater number of words to be used to achieve the same level of security. Higher value transactions may also require the generation of additional words.
Any features described as related to a dictionary may also be relevant for word generation, and vice versa, ie. the word list from which an authentication string is chosen may be limited by generating a dictionary with desired features, or may be limited by only selecting words with these features at the time of generation.
Generally, an authentication word string is determined according to the algorithm of the form:
AWS=Ek(P)
where
Other factors may be included to improve security further.
Each word in the authentication dictionary is assigned a number and the outcome of the algorithm indicates the constituent words of the authentication word string.
For online authentication, the key k may be transmitted from the user and authentication server alongside the authentication word string. Offline authentication is discussed separately below.
The number of words to be generated may depend upon the transaction, for example if the transaction concerns a small payment 1 or 2 words may be considered sufficiently secure, whereas if a large payment is being made it may be desirable to use a greater number of words for increased security.
For example, for an authentication words derived from a dictionary of 22,000 words, each word of the authentication word string has an entropy H=Log 22,000/Log 2=14.24, hence an authentication word string (AWS) comprising three such words (alternatively referred to as “3LW”) has an entropy of 43.28, or reasonable level of security.
The authentication word string may be made longer, say to five words (alternatively referred to as “5LW”) or more, to provide a greater entropy hence higher level of security.
In some embodiments, the words generated may have some connection, for example the words may form a sentence, or share a common theme. This connection may occur due to the dictionary which the words are selected from, or may be occur due to the method of word generation.
One or more words may also be preselected from the server: this may be used so that, for example, each transaction occurring in a store uses the name of that store as one of the words.
In some embodiments, the number of words may be selected 1008 by a regulatory body, or this body may specify a minimum number of words, where the user or agent may then select a number equal to or greater than this minimum. The number of words used may also be dependent upon the dictionary used, where a smaller dictionary may require more words.
The dictionary selected 1006 to generate words may be selected in in dependence on a feature of the transaction, so that, for example, a sufficiently secure dictionary, such as a dictionary comprising at least a minimum number of words, may be required for large payments.
The dictionary used may depend on a selection made by the user, merchant, or server.
In some embodiments, the dictionary may be selected in dependence on the quality of the transmission channel, for example, an imperfect telephone connection may result in the selection 1006 of a dictionary comprising easily distinguishable words. Such a dictionary may be smaller than that used with a better quality connection, so that more words may be required to obtain a sufficiently secure password.
For offline authentication, the user and the authentication server need to agree on the correct authentication word string despite not being in direct communication.
This is achieved by making the key time-dependent—which may also be used for online authentication.
To allow for imperfect synchronisation, the day is divided into time intervals of length n.
For example, some embodiments divide the day first into 12 hours 1102, and then further divided into 5 minute intervals within each hour 1104, so that there are 288 intervals each day. Word generation is therefore dependent upon the time to within a 5 minute interval. In some embodiments, shorter, say two-minute, intervals may be used. Alternatively, longer intervals may be used.
The time-to-live (TTL) of the authentication word string AWS, and the number of past and future expected word strings EWS against which it is compared may be selected by the user, merchant, or authenticating server—or be determined by a property of the transaction.
Generally, the interval is configurable, typically according to the quality of the communications channels and/or the required level of security. For example, authentication word strings used for high value transactions may have a shorter TTL.
In practice, the authentication server allows for a degree of imperfect synchronicity (as well as user delay) by having authentication word strings with a maximum time to live (TTL) of between n and 2n minutes, ie. for any received authentication word string the authentication server computes the present (t) and at least one of the immediate past (t−1) and immediate future (t+1) expected word strings for use in authenticating the user.
For example, if a user generates an AWS for 01:48, but does not submit it until 01:52, this will not be an issue as the authentication server will calculate the expected EWS and compare received AWS for both 01:45 and 01:50.
A further refinement has each 5 minute time slot assigned a different pre-shared key, such as pseudo-random numbers from a random number generator RND. In practice, arrays or grids of keys are shared at a time, securely using Diffie-Hellman key exchange. Essentially this introduces perfect forward secrecy (also known as ‘one time pad’ encryption) into the generation of the authentication word strings.
Offline usage requires the keys to be downloaded before use, the keys being updated when the user has online functionality. For example the keys for the next 30 days (the next 8,640 keys) are stored on a user device, and are updated whenever the user reconnects online.
Transmission of the keys may also take place using a less secure method over a secure channel, for example keys may be delivered to a user address on a storage media, such as a hard drive. A large number of keys may be contained on such a media, where a subsection of these may be transferred to a user device each 30 days.
When an agent 14 hears 1202 an authentication word string spoken by a user, the agent will attempt to interpret 1204 the sounds as dictionary words even if the sound is unclear. For example if the agent hears the user say “plebble”, this agent is likely to interpret this as “pebble”. This may provide an advantage of using (whole) words in the authentication string rather than individual characters, wherein the agent may be unable to differentiate between a single spoken “m” or “n”, and not have any word context in which to conclude either way.
The effectiveness of the word string authentication may be further improved by using a dictionary selected to avoid similar words. For example, if “treble” is the only word in the dictionary which ends in “ble”, the authentication server 16 will correct 1208 an authentication word string forwarded by an agent 14 with the word “pebble” by replacing it with the correct word “treble”.
The agent 14 may be provided with a list of possible words, or a predictive text feature, which may suggest words, where these words may be in the dictionary (here suggesting ‘treble’ rather than ‘pebble’).
The authentication server 16 may correct for typographic errors.
The authentication server 16 then compares 1212 the received authentication word string AWS to the expected word string EWS. If the words match the server authenticates 1214 the request.
If the AWS and EWS do not match, the authentication server 16 may reinterpret 1208 the word string, so that the server may compare 1212 both the initial version of words input 1206 by the agent 14 and one or more word strings based on this input. The error checker may suggest corrections to either the agent or the user.
A range of words may be acceptable, so that if the words entered are within a set range of the words expected the user is authenticated. This range may be a written range or a vocal range, i.e. there may be an acceptable range or number of typographic errors, or there may be an acceptable range of similar sounding words.
In some embodiments, the agent 14 may be able to input and transmit a word using an indicator, instead of the letters comprising the word, for example a number may be input using digits, where a user may vocally transmit ‘nine’, an agent may be able to enter ‘9’;
similarly a transmission of ‘ampersand’ may be indicated by an agent entering ‘&’.
An AWS word time-based token is used to identify a user (as opposed to validating a user device) by requiring biometric verification to release an AWS authentication/access token.
As the AWS token is delivered supporting Strong Customer Authentication (SCA), that is dual-factor authentication over two separate delivery channels, it may be used as an effective and highly secure corridor for the transmission and receipt of authorisation requests.
This process can work in either “direction”:
In the example shown:
In some embodiments, the authentication server will only accept or authenticate an authentication word string received from a predetermined location or party.
Words for the authentication word string may be selected from a combination of dictionaries.
For example, a number of words may be selected from a master authentication dictionary and a number from a personal user dictionary.
Using a large master dictionary may increase security by ensuring a high password entropy, whereas using a smaller personal user dictionary may increase security by ensuring that a third party requiring access to the personal dictionary in order to impersonate the user.
In embodiments which do not involve an agent as an intermediary, functions described as being performed by the agent may instead be performed by the user and/or the service provider.
Any of the user, agent, or service provider may transmit the authentication word string (and any other required information) to the authentication server. Alternatively, the authentication word string may be transmitted from the user or agent to the service provider, before being transmitted to the authentication server. Any of the user, the agent, the service provider, or a combination thereof may transmit the authentication word string to the authentication server either directly or via any other party or combination of parties.
In some embodiments the authentication word string is transmitted visually rather than via voice. This may be useful noisy environments where the user and the merchant cannot hear each other.
In some embodiments the authentication may use gestures. There are situations in which speaking an authentication phrase is either not possible or not desirable, for example where a camera, or another visual detector, is being used to monitor a secure area. It may also be impossible, or undesirable, in such a situation, to use a written means to authenticate a user. Authorisation via gestures may comprise a ‘gesture string’ comprising one or more gestures selected from a dictionary of gestures, such as a “wink”, “smile”, or “jump”. A camera, or an agent observing the camera feed, may observe these actions in order to authenticate the user.
In some embodiments, transmission of the authentication word string or other information may be sent via various other communication channels, for example via simple messaging service (SMS).
Generally, the type or size of transaction which may be allowed to be authenticated by this method may depend on the inherent security of the channel(s) used. For example, SMS may not be considered sufficiently secure, and therefore unsuitable, for high value transactions.
In some embodiments, access tokens resulting from a successful authentication may be provided by the authentication server to any of the other participating parties.
Details of successful and/or unsuccessful authentications may be recorded. This may allow, for example, the user to report unsolicited payment requests from merchants or other abuses of the service.
Embodiments may also be used with a voice activated home hub (such as Amazon Alexa or Google Home Assistant), which may be used similarly to a mobile wallet software development kit (SDK), to call the federation services for the Payment and Reverse Authentication use cases.
In some embodiments, the TLS channel is mutually authenticated (for example, using a client certificate) between the user and the federation server, therefore no adversary can impersonate the client to the Federation Server or vice-versa. It is worth noting that the client (as the User's Device or a piece of software on the Device) could be compromised to present to the User information that is not accurate. The Federation Server and service operator may wish to inspect client applications and Devices that wish to interoperate with it to ensure their trustworthiness with the capability to disconnect or prevent further account use where devices are suspected of compromise.
While the detailed embodiments set out herein are primarily concerned with authenticating a user in order to authorise a payment, the methods disclosed may be used to authenticate a user for other reason. For example, a user may wish to access a secure area, physical or virtual, where the methods disclosed may be used in lieu of or in combination with a password. The user may wish to access, or release to another entity, sensitive personal information, such as a driving license or a bill or register for a service or website.
It will be understood that the invention has been described above purely by way of example, and modifications of detail can be made within the scope of the invention.
Reference numerals appearing in any claims are by way of illustration only and shall have no limiting effect on the scope of the claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 1721028.7 | Dec 2017 | GB | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/GB2018/053639 | 12/14/2018 | WO | 00 |
