WO2018142291A1

WO2018142291A1 - Identity verification

Info

Publication number: WO2018142291A1
Application number: PCT/IB2018/050587
Authority: WO
Inventors: Guus ZIJLSTRA
Original assignee: Zinias B.V.
Priority date: 2017-02-01
Filing date: 2018-01-31
Publication date: 2018-08-09
Also published as: EP3577849A1; GB201701645D0

Abstract

A need exists for a user 1 to control their digital identity without reliance on third party service providers 40, 50. A user 1 will use cryptographic keys to verify their identity in the digital world, e.g. over the Internet 25. A method is herein described to permit the user 1 to securely access such cryptographic keys. The method comprises generating, using a physical or virtual authentication tool 10, an intermediate key based on a PIN or similar code provided by the user 1 and a unique code contained in the authentication tool 10. An offset value is applied to the intermediate key to generate a decryption key, thus allowing for multiple authentication tools 10 having different unique codes to be used. The decryption key is used to decrypt an encrypted cryptographic key. The encrypted cryptographic key and the offset(s) are meaningless without the authentication tool 10 and the user code, and so may be freely stored in any location, even on (semi-)public servers 30, without compromising the security of the cryptographic keys of the user 1. Also provided is a method for generating new encrypted cryptographic keys and for generating offsets to permit new authentication tools 10 to access such encrypted cryptographic keys.

Description

IDENTITY VERIFICATION

In the modern world, it is possible to carry out a large variety of interactions and transactions remotely, often using computer networks, and often including the Internet. Typical transactions may be to look at or share data, to place orders for goods, or to communicate in either open or closed groups. Further transactions may be to carry out financial transactions, including payment of bills, or moving funds from one place or account to another. It is therefore important to verify the identity of a user, before permitting that user to carry out the above.

To be 'trusted' in a remote interaction or transaction, it is necessary to prove one's identity, so that either the human at the other end of the network, or processes available on the network, can 'know' that the person is who he claims to be.

There have been many proposed methods of authentication using biometrics. These biometric systems have often used human fingerprints or retinal patterns to authenticate an individual. These are expensive, as they require either fingerprint reading technology or retinal scanners, and are also unreliable.

Furthermore, injuries to a fingertip, such as a cut, can render fingerprint methods of authentication unusable. In the extreme, a ruthless hacker could always dismember an individual's finger and use it to obtain access to the individual's accounts. Retinal scans are known to have difficulty with users who use 'eyewear' (spectacles, contact lenses, etc.), and since the Vision Council of America reports that 75% of adults use some sort of vision correction, this problem occurs in well over half of the US population. The UK College of Optometrists reports similar figures for the UK (72% of women, 66% of men). Lack of standardisation of biometric parameters also results in many different system that are not all interoperable, which is a further disadvantage.

For many years, most authentication systems have relied on a 'username and password' authentication system. Typically users enter their username and their password. The system then compares the password that it has on file for that user, with that entered by the user, and if the two agree, the user is then

'authenticated' and given access to whatever this authentication allows - for example to access their bank account or their stored files or information. As an alternative, servers may keep hashed versions of the passwords, and compare these with the hash of the cleartext password entered by the user. There are several problems with systems like this. Extremely sensitive information belonging to many different people is handled by relatively few servers, creating centralized weak spots. Employees who have access to this server or network can sometimes access password databases, and find out the passwords of their account holders. The weakness of hashing can be exploited by 'brute force' trial and error methods, by computers capable of billions of instructions per second. Illicitly gained data such as this finds its way into the hands of criminals, who use it fraudulently, often to steal money from people's bank accounts. Even if there is not a problem with employees, the known fact that there exists a database of identities and passwords somewhere on the server encourages external people to 'hack' into the server in search of this.

Secondly, problems can occur with lost, stolen, or broken hardware. Under the current model of authentication, a user's local hardware typically contains a lot of sensitive information. This includes, but is not limited to, 'burnt in' or saved passwords, cookies, browsing history and profiles. If hardware is lost or stolen, this sensitive information can fall into the hands of unscrupulous strangers. If the hardware is broken, it cannot be handed in for repairs without exposing private information to the service centre or repairer.

Thirdly, and possibly most importantly, there is a problem with the user. It has been shown that the most secure passwords are formed from random combinations of digits, letters, and symbols, and of the maximum length permitted by a particular system implementation (if the system has a length maximum).

Ideally passwords with more than 32 random characters should be used on public and local systems. However these are not easily remembered by humans, who want to relate it to another association or fact to be able to recall it. Common passwords are user's dates of birth, names of children, dates of birth of children, names of pets, and so on. These are easily 'guessable' by parties who should not have access, including the criminal fraternity. It has also been shown that if users are made to use long or complicated passwords they often write them down, and of course by having or leaving copies of this password around it negates the point of passwords.

Because of the proliferation of services available to users, many users have too many accounts and too many sign ons to handle easily. This has led to a trend towards 'Single Sign on' (SSO). When a user logs onto one service, they get access automatically to all other services that are part of this SSO federation. SSO uses even more centralised authentication than logging onto each service individually. Common examples of SSO include Facebook® and Google®.

There is also currently no practical way for people to create and control an identity without introducing some central third party (government, bank, services vendor and so on).

It is desirable to find a way of using full strength passwords without the user having to remember them. It is also desirable to have a system where the body holding the information to be accessed (e.g. an organisation that owns or runs a server or network, or a bank) does not need to store a copy of the user's (hashed) password to authenticate against. It is further desirable for users to be able to set up their own closed user groups for file sharing and so on without having to involve external parties (e.g. Google®, Dropbox®, etc.). Finally it is desirable to ensure that hardware, if lost, stolen, or in the hands of a repair / service agent cannot be compromised.

At least the preferred embodiments of the present invention seek to provide a system which satisfies some or all of the above requirements.

Viewed from a first aspect, the present invention provides a method comprising: generating, at least partially on a physical or virtual authentication tool controlled by a user, an intermediate key based on a user code provided by the user and a unique code contained in the authentication tool; accessing an encrypted cryptographic key, wherein the encrypted cryptographic key is not stored in the authentication tool; accessing an offset value associated with the encrypted cryptographic key and the authentication tool; applying the offset value to the intermediate key to generate a decryption key; and locally decrypting the encrypted cryptographic key using the offset decryption key to give a decrypted cryptographic key.

This technique allows the user to use a simple logon to access their cryptographic keys, which do not then need to be remembered and so can be very long. This allows the user to securely authenticate themself or securely encrypt data. However, because the data is not stored on the authentication tool itself, loss of the tool itself does not risk the data being accessed. Furthermore, because the data is encrypted using strong encryption based on the unique code of the authentication tool, the encrypted cryptographic can be stored even in semi-public servers without concern that they could be accessed by the service provider operating those servers. The use of the offset allows multiple authentication tools to access the same encrypted data, thus allowing the user to continue to access the data in the event of loss of one tool, without need for a central service provider who would then need to have access to the user's cryptographic keys.

Consequently, the user is fully in control of their digital identity.

The authentication tool may comprise a physical device.

The physical device may be a portable device suitable for being carried by the user, e.g. on their person. For example, the physical device may have a mass of less than 0.5kg, preferably less than 0.1 kg, and/or a volume of less than 500cm³, preferably less than 100cm³.

In another arrangement, the physical device may be stored at a remote location from the user. For example, the physical device may be accessible electronically, e.g. via the Internet or other network. The physical device may, however, still be suitable for being carried by the user, if desired.

The authentication too may comprise a virtual device. For example, the authentication tool may comprise a software application and a virtual container for storing the unique code. The method may comprise loading the unique code into the virtual container responsive to a request from the user. The virtual device may be stored in the cloud. The virtual device may be stored alongside a plurality of other authentication tools, which may be controlled by different users.

The authentication tool is preferably incapable of transmitting the unique code to an external device. Thus, it cannot be accessed by a third party to attack the encrypted cryptographic key.

The authentication tool may be a physical device. The physical

authentication tool may be configured to store the unique code in a secure memory.

In some arrangements, the encrypted cryptographic key may be stored on a local computer, i.e. local to the user when accessing the cryptographic key.

However, preferably, the encrypted cryptographic key is stored in a remote location, and more preferably not normally stored in a local location (i.e. apart from when being accessed). For example, the remote location may be a server accessible via a wide-area network (WAN) or via the Internet. The server may be a cloud location. The server may be over 1 km away from the user.

The step of locally decrypting the encrypted cryptographic key may be performed on a computing device local to the user and separate from the authentication tool. That is to say, the authentication tool may be removable from the computing device without impairing operation of either the authentication tool or the computing device. Where the authentication tool is a physical device, it may communicate with the computing device wirelessly or via a contact connection. Where the authentication tool is a virtual device, it may communicate with the computing device via a secure communication channel, for example over a WAN such as the internet. The computing device may be one of: a personal computer, a desktop computer, a laptop/notebook computer, a tablet computer, a mobile/cellular telephone, a personal digital assistant, or similar personal computing device.

The intermediate key and/or the decryption key may be stored in a memory of the computing device, and preferably in a volatile memory of the computing device. The intermediate key and/or the decryption key may be deleted from the memory of the computing device responsive to interruption of communication between the authentication tool and the computing device.

The decrypted cryptographic key may be stored in a memory of the computing device, and preferably in a volatile memory of the computing device. The decrypted cryptographic key may be deleted from the memory of the computing device responsive to interruption of communication between

authentication tool and the computing device.

Thus, particularly in the case of a physical authentication tool carried by the user, when the physical authentication tool is removed from the vicinity of the computing device, data which might be used to attack or remove the encryption on the encrypted cryptographic key may be automatically deleted, for example even if the user forgets to do so.

The decrypted cryptographic key is preferably never transmitted remotely from the computing device. Thus, cryptographic key is never outside of the control of the user.

The user code may be at least partially derived from a biometric identifier.

The cryptographic key may be used for various purposes. For example, it may be a private key associated with a corresponding public key. Alternatively, it may be a symmetrical key, for example to encrypt data to be shared with another party in possession of the same key or to encrypt or decrypt data to be stored.

Thus, the method may further comprise authenticating the user by locally encrypting or decrypting a challenge phrase using the decrypted cryptographic key.

The authentication may comprise: receiving an encrypted challenge phrase, the challenge phrase having been encrypted with a public key associated with the user; locally decrypting the challenge phrase using the decrypted cryptographic key, which is a private key corresponding to the public key; and sending the decrypted challenge phrase as evidence that the user is in possession of the decrypted private key.

In another arrangement, the authentication may comprise: receiving a challenge phrase; locally encrypting the challenge phrase using the decrypted cryptographic key; and sending the encrypted challenge phrase, wherein the encrypted challenge phrase can be decrypted with a public key associated with the user, as evidence that the user is in possession of the decrypted cryptographic key.

The method may comprise: receiving encrypted data, wherein the encrypted data is encrypted using a public key, and wherein the decrypted cryptographic key is a private key corresponding to the public key; and locally decrypting the encrypted data using the decrypted cryptographic key.

The method may comprise: accessing encrypted data, wherein the encrypted data is encrypted using the cryptographic key; and locally decrypting the encrypted data using the decrypted cryptographic key.

Viewed from a second aspect, the present invention also provide a method comprising: generating or receiving a cryptographic key; generating, at least partially on a physical or virtual authentication tool controlled by the user, an encryption key based on a user code provided by the user and a unique code contained in the authentication tool; and locally encrypting the cryptographic key using the encryption key to give an encrypted cryptographic key, wherein the encrypted cryptographic key is not then stored in the authentication tool.

This technique permits the user to locally generate encrypted cryptographic keys, such as for use with the technique described above. The cryptographic keys are thus encrypted such that they can only be recovered by the user in possession of the authentication tool and the user's code. Thus, the encrypted keys can be freely stored, even in semi-public locations. However, the user is fully in control of access to this data and no third party can access it. Furthermore, the encrypted cryptographic keys are not stored on the authentication tool itself, and so are not compromised if this is lost, even if the system uses a simple password as the code.

Consequently, the user is thus fully in control of their digital identity.

The method of the second aspect may be combined with the method of the first aspect. Thus, it will be appreciated that any one or more or all of the optionally or preferred aspects of the first aspect may apply also to this second aspect. In one embodiment, generating the encryption key may comprise:

generating, at least partially on the physical or virtual authentication tool controlled by the user, an intermediate key based on a user code provided by the user and a unique code contained in the authentication tool; generating an offset value; and applying the offset value to the intermediate key to generate an encryption key.

The authentication tool may be incapable of transmitting the unique code to an external device.

The method may comprise storing the encrypted cryptographic key in a remote location.

The step of locally encrypting the cryptographic key is preferably performed on a computing device local to the user and separate from the authentication tool.

The intermediate key and/or the encryption key may be stored in a memory of the computing device, and preferably in a volatile memory of the computing device. The intermediate key and/or the encryption key may be deleted from the memory of the computing device responsive to interruption of communication between the authentication tool and the computing device.

The cryptographic key may be stored in a memory of the computing device, and preferably in a volatile memory of the computing device. The cryptographic key may be deleted from the memory of the computing device responsive to interruption of communication between the authentication tool and the computing device.

The cryptographic key is preferably never transmitted from the computing device in an un-encrypted form.

The user code may be at least partially derived from a biometric identifier.

The cryptographic key may be a private key having an associated public key.

In one arrangement, the authentication tool may be a first authentication tool, and the method may comprise generating an offset value to permit a second authentication tool to decrypt the encrypted cryptographic key.

The method may further comprise: generating, at least partially on a second physical or virtual authentication tool controlled by the user, a second intermediate key based on a user code provided by the user and a unique code contained in the second authentication tool; and calculating an offset value to transform the second intermediate key into the decryption key.

In accordance with this technique, the offset value generated is meaningless to any third party. However, when applied to an intermediate value generated from the second authentication tool, it allows it to arrive at the same decryption key as would be generated using the first authentication tool. Thus, the user can have multiple authentication tool as back-ups in case of loss, rather than relying on a third party to also have access in case of the need for recovery.

The offset value may be stored together with the encrypted cryptographic key. As noted above, in isolation, this offset value is meaningless.

In some embodiments, the offset value may be applied using an XOR function.

Viewed from a third aspect, the present invention provides a computer program comprising computer readable instructions that, when executed, will cause a computing device to perform a method comprising: receiving an intermediate key from a physical or virtual authentication tool, the intermediate key having been generated based on a user code provided by the user and a unique code contained on the authentication tool; accessing an encrypted cryptographic key, wherein the encrypted cryptographic key is not stored in the authentication tool; accessing an offset value associated with the encrypted cryptographic key and the authentication tool; applying the offset value to the intermediate key to generate a decryption key; locally decrypting the encrypted cryptographic key using the decryption key to give a decrypted cryptographic key; and locally encrypting or decrypting data using the decrypted cryptographic key.

The computer program of the third aspect may further be configured to perform any one or more or all of the optional or preferred features carried out in the first aspect, and particularly those associated with the computing device thereof.

Viewed from a fourth aspect, the present invention provides a computer program comprising computer readable instructions that, when executed, will cause a computing device to perform a method comprising: generating or receiving a cryptographic key; receiving an intermediate key from a physical or virtual authentication tool, the encryption key having been generated based on a user code provided by the user and a unique code contained in the authentication tool; generating or receiving an offset value; applying the offset value to the intermediate key to generate an encryption key; and locally encrypting the cryptographic key using the encryption key to give an encrypted cryptographic key, wherein the encrypted cryptographic key is not then stored in and/or with the authentication tool. The computer program of the fourth aspect may further be configured to perform any one or more or all of the optional or preferred features carried out in the second aspect, and particularly those associated with the computing device thereof. Furthermore, a single computer program may be provided for performing the functions of the computer programs of both the third and fourth computer programs.

Certain preferred embodiments will now be described in greater detail by way of example only and with reference to the accompanying drawings, in which:

Figure 1 shows a user interacting with a cryptographic system;

Figure 2 is a flow chart showing a method of generating a cryptographic profile;

Figure 3 is a flow chart showing a method of accessing a cryptographic profile; and

Figure 4 is a flow chart showing a method of permitting a second device to access a cryptographic profile.

The following embodiment relates to a system by which a user may use a simple username/password combination to securely authorise access to a secret cryptographic key associated with the user. The secret cryptographic key may be one used to encrypt/decrypt data for secure storage, to securely communicate with a third party or to authenticate the identity of the user, such as by digitally signing a message.

The main physical and software elements of the system are illustrated in Figure 1 and comprise:

1. A user 1 with an easily remembered username/password

combination;

2. An physical device 10 storing a secret number that cannot be

copied, referred to herein as an EzKey 10;

3. A cryptographic profile including an encrypted private key and

corresponding offsets associated with one or more EzKeys 10;

4. A Profile Service Provider holding the profile so that it is accessible to the user 1 , such as on a semi-public server 30;

5. A Client Security Program (CSP) for accessing, decrypting and utilising the Encrypted Private Key; and

6. Client User Software (CUS), which may include general software running on the user's local hardware 20 for dealing with everyday activities such as sending/receiving email, sharing files, logging in to services, etc. using the CSP.

The EzKey 10 is a physical token or device that may be carried by a user 1. The EzKey 10 contains within it a secret number. Preferably no two EzKeys 10 have the same secret number in them. Preferably the EzKey 10 is small and portable, and may contain a communications interface, such as a short range wireless data link (such as the industry standard Bluetooth®), for communication with a local computing device 20.

Suitable devices that meet the security requirements for use as the EzKey 10 may include the CryptoMemory EEPROMS from ATMEL®. These contain multiple, non-readable 64 bit authentication keys. The layout and design of the devices offers no way to read out the original key - it can only be accessed after it has passed through the hashing engine. Many secure features are included in these devices, such as incorporating screening to prevent access to the chip's internal layout by using X-Rays, and the use of non-linear memory cells within the device, so that if the chip were cut open and viewed under a microscope the function cannot be derived.

The following scenario illustrates an exemplary operation of the EzKey 10 and ancillary elements to carry out self-authentication of the identity of the user 1.

The user 1 has a login name - for example the name 'George'. Note that the username may be part of his real name, a nickname, or merely a login name. A computer program, such as small script, piece of code, or app runs on a local computing device 20 (for example, the user's desktop computer, laptop, tablet, phone, or other computing device). This software program, which will be referred to as the Client Security Program (CSP), takes in the user's login name, and asks for a password. This can be a short word, series of letters, or personal data. As will be described later, the fact that this password can be a simple human memorable piece of data does not limit the security of the present system.

In one example, the user may be an animal lover, and so may have chosen the simple memorable password to be 'dog'. The CSP takes in this response ("dog"), and in turn communicates it via a communication link 15 - preferably a 'PAN' (Personal Area Network - a wireless network that has a range of a few metres - such as Bluetooth®). The communication link 15 talks to the EzKey 10. Upon receipt of this password ("dog") the EzKey 10 'fortifies' the username / password combination, by hashing it with the device's secret unique number, to result in a 'strong' password. That is to say, the hashing function has, as one of its inputs, the secret unique number that is 'etched' into the EzKey 10. This password is now long - typically 256 bits - and meaningless and non-memorable to humans. There are many known methods of hashing. An exemplary hashing technique includes the SHA-2 (Secure Hash Algorithm 2) cryptographic hash function.

However, it will be appreciated that other non-reversible functions may also be used to combine the username / password combination and the secret number.

The EzKey 10 is made in a way that it cannot be copied, or 'decoded'. The resilience of the EzKey 10 will be described later. The secret, unique number contained within the EzKey 10 cannot be extracted from it. This means that each individual EzKey 10 will give a different answer when asked to perform a hashing operation on the same username and password combination.

The result of the hashing is to produce the User Password Hash (UPH), which is typically a 256 bit string. This UPH may be used as a cryptographic key to encrypt and/or decrypt a private key belonging to the user.

The private key may be used for encryption or decryption of data, and may be any cryptographic key. For example, the cryptographic key may be a secret key known only to the user, a shared secret key for encrypted communication with another party, or a private key from a public-private key pair.

A useful function is to limit the number of answers the EzKey 10 can produce within a given period of time, for example no more than ten UPHs per second. This prevents 'brute force' attempts to produce vast amounts of data from the key, in an attempt to establish the pattern or behaviour of the hashing it carries out on various different password seeds.

Figures 2 and 3 illustrate how the UPH generated by the EzKey 10 may be used to permit the user to securely generate, store and access their private cryptographic keys.

Figure 2 illustrates an exemplary process by which a new cryptographic profile may be generated, which will be described below.

First, at step 202, the user 1 enters their username and password into the

CSP running on their local computing device 20. The username password is then transmitted securely, for example via a Bluetooth® link 15 to the EzKey 10. Next, at step 204, a UPH is generated based on the username/password combination using the EzKey 10, as described above. Next, at step 206, a random Offset' value is generated. This offset value may be generated in any suitable manner, for example using a random number generator in the CSP or elsewhere in the computing device 20 or in the EzKey 10.

At step 208, the offset is applied to the UPH to generate an offset UPH (OUPH). This will be used later as an encryption key. The offset may be applied in any suitable manner that allows permutation of the UPH. For example, in this embodiment, the offset is a random number having the same binary length as the UPH and the offset is applied to the UPH using an XOR function.

At step 210, the CSP generates a cryptographic key to be associated with the cryptographic profile. As discussed above, this cryptographic key may be used for encryption or decryption of data. For example, the cryptographic key may be a secret key known only to the user, a shared secret key for encrypted

communication with another party, or a private key from a public-private key pair. Where the cryptographic key is a private key of a public/private key pair, the CSP will also generate a corresponding public key, which may be presented to the user and/or stored locally and/or stored with the eventual cryptographic profile.

It is important that the cryptographic key remain secret. As such, this preferably never leaves the CSP in an unencrypted form.

At step 212, after generating the cryptographic key and the OUPH, the CSP then encrypts the cryptographic key using the OUPH as the encryption key. This generates a new Encrypted Private Key (EPK). The type of encryption used is preferably a symmetric encryption algorithm, for example AES, such that it can be reversed using the OUPH. The cryptographic key contained in this EPK can now only be obtained by the user whilst in possession of the EzKey 10 and their username/password.

As such, at step 214, the CSP may then transmit the EPK to be stored a server 30 so that it can be retrieved by the user 1 when required. The EPK and offset are stored as a cryptographic profile belonging to the user. The

cryptographic profile may also store an identifier of the EzKey 10 associated with the offset, such as a serial number.

Note that this server 30 can be private, or even semi-public. For example, the Encrypted Private Key may be stored on a (semi-)public server 30, which may be accessed via the user's private intranet or via the public internet 25. Since it is impossible for the hacker to obtain the UPH, the EPK is useless to them. Because no human needs to 'remember' the cryptographic key, it can be 2000 to 3000 bits long or even more.

In one embodiment, the profile server 30 is operated by a profile service provider, which maintains the servers and allows the user to connect to their stored cryptographic profiles. For example, the user may be required to log onto the server when initialling the CSP on a new computing device 20.

Whilst the cryptographic profile is preferably stored on the profile server, it will be appreciated that additionally or alternatively, cryptographic profiles of the user may be stored locally on the computing device 20.

Next, with reference to Figure 3, an exemplary method by which the cryptographic key may be accessed will be described.

First, at step 302, the user 1 selects one of their cryptographic profiles to access. This step may be performed automatically by the CSP, for example it may know to retrieve a specific cryptographic profile responsive to an API call from a particular CUS program. Alternatively, the user may be presented with a list of available profiles (or a subset of profiles, for example that may be used for a particular application) from which to select the profile to be accessed.

Next, at step 304, the CSP prompts the user 1 to enter their username and password. The CSP receives the username and password input by the user and securely transmits them to the EzKey 10.

At step 306 the EzKey 10 generates a UPH, as described above, based on the username/password combination and the secret number etched in the EzKey 10. The UPH is then securely transmitted back to the CSP on the computing device 20, where the CSP applies the offset at step 310 to generate an OUPH. Where the selected cryptographic profile includes multiple offsets corresponding to different EzKeys 10, the CSP will select the corresponding offset for the EzKey currently connected.

At step 312, the CSP retrieves the EPK from the cryptographic profile, and the OUPH is used as a decryption key at step 314 to decrypt the EPK. The CSP is then in possession of the user's unencrypted cryptographic key.

The unencrypted cryptographic key is stored temporarily in memory on the user's device 20 (desktop computer, laptop, tablet, phone or suchlike). At this point the user 1 is in control of his own plaintext (unencrypted) private key and can be thought to have 'self-authenticated'. The user 1 may then use their cryptographic key as desired. It will be appreciated that the above methods are merely examples and that many permutations are possible within the scope of the present disclosure. For example, any one or more processes performed by the CSP on the computing device 20 may be performed instead on the EzKey 10, such as steps 208/310. Furthermore, the order of steps is not limiting and the steps may be performed in any suitable order. For example, steps 206, 210, 304, 308, and 312 may be performed earlier in the process.

Thus in summary, the 'user experience' is as follows:

1. activate/select their EzKey 10;

2. start up their local hardware 20;

3. select their Profile Service (probably just once on every device 20 owned by the user)

4. select profile (if more than one)

5. enter their simple username/password;

6. hit 'enter'

The user is then self-authenticated, and the Client Security Program is now in control of the plaintext private key. Client User Software operating on the computing device 20 can now perform acts including one or more of logon, secure email and file encryption transparently to the user.

The value of this system will be seen in the following example.

George 1 now wants to access his bank account. He goes through the 'self authentication' process above, and gets his plaintext Secret Key temporarily in the memory of his device 20. He then requests to log onto his bank account via the internet 25. The bank 40 offers him a challenge. However, instead of the challenge being 'what's your password' - and comparing his answer with a stored copy that the bank 40 has - it challenges him to show he has the secret key. For example, it may generate a message containing a random number or string. This will obviously be a different number every time, and such messages are referred to in cryptology as a NONCE. There are many ways known to do this. Typically this message will contain a random number that will be 256 bits or longer. The bank 40 will then encode this message using RSA cryptology or similar using a public key, which is widely available and associated with this user, and is of no use to anyone without the plaintext private key. So the bank uses the public key associated with George 1 to encode the message containing the random number or string. This results in a further long string, again typically 256 bits or longer. Using the unencrypted private key, which is still stored temporarily in memory in the user's local hardware, George 1 decrypts the string to revert back to the message containing the original random number.

This message is then sent back to the bank. The bank 40 verifies that this is indeed the original message containing the random number (or NONCE) that they produced, and if it is, assume that George 1 is authenticated. At this point access is given to George's bank account.

It can be seen here that the bank 40, server provider, or other parties never have access to the plaintext private key or any other sensitive information, like username, password, or UPH, resulting in a far more secure system than commonly used in systems today.

It is obvious that although the above example describes a use case for bank authentication, it can apply to any system where users 'log on'. Other uses of the CUS may be to obtain email, carry out internet commerce, log on to 'pay' or 'member' services on the internet, obtain information stored on servers, to share information, for secure message encryption, file sharing systems, for files, music, or video files. Further implementations are possible by programmes that run on the local hardware, and have access to the plaintext private key, and then use it for secure tasks, such as eCommerce. Again here, this key never leaves the user's local hardware 20, and is kept in volatile memory temporarily, and deleted automatically as and when needed.

A further example may be where the user stores encrypted data files remotely, for example on a remote server 50, such as using cloud storage. The user may store the files in an encrypted form using the cryptographic key to encrypt and decrypt the files. Thus, the user can easily access both the key and the data at any location where they have their EzKey 10. However, the encrypted data stored on the remote sever 50 cannot be read, even should a third party obtain access to them.

Similar techniques to those described above may already exist on servers. However the distinction of the present system is the secure handling of the user's private key on the user's local hardware 20 and their EzKey 10, without any sensitive information ever leaving the user's closely controlled physical environment (i.e. the local hardware 20 and EzKey 10). As mentioned above, a single cryptographic profile may contain multiple offsets corresponding to different EzKeys 10. Figure 4 illustrates a technique by which additional offsets may be generated, which is described below.

At step 402, the user selects a cryptographic profile that they wish to add an additional EzKey 10 to.

At step 404, the user enters their username and password for a first EzKey 10, which is already associated with the cryptographic profile, and at step 406, the first EzKey 10 generates a first UPH for the username/password combination, which is returned to CSP.

At step 408, the same username and password are transferred to a second

EzKey (not shown), which then generates a second UPH for the

username/password combination. As will be appreciated, each EzKey has its own unique secret number, and so the two UPHs will be different from one another.

In this embodiment, it is assumed that the same password is used for each EzKey 10. However, this technique could be used also where different passwords are used for each of the EzKeys 10.

At step 410, the CSP retrieves the offset from the cryptographic profile associated with the first EzKey 10. Then, at step 412, compares the first offset, the first UPH and the second UPH to determine a second offset that, when applied to the second UPH, converts it to the decryption key. For example, where an XOR function is used to apply the offset, the second offset may be calculated by applying the XOR function to the first offset and the first UPH (to generate the decryption key), and then by applying the XOR function to the decryption key and to the second UPH.

Finally, the second offset is transmitted by the CSP to the profile server.

Again, it will be appreciated that the offset by itself is meaningless without knowledge of the username/password and the secret number of the respective EzKey.

The use of the offsets provides a number of advantages.

Firstly, this permits two or more EzKeys to be permitted to decrypt a single cryptographic key. Consequently, if one EzKey 10 is lost, then the cryptographic keys can still be retrieved using the backup.

Secondly, if an EzKey 10 is lost, then it can be effectively disabled by deleting the offset from the cryptographic profile. This is a particular advantage of storing the cryptographic profiles only with the Profile Service Provider, and not locally on the EzKey 10 or computing device 20.

As a further security feature, whenever the local hardware 20 loses its connection with the EzKey 10, it is desirable to drop all sensitive information (specifically, erasing the plaintext secret key, the username/password, the UPH, and all other sensitive data from memory), and thereby effectively performing the local equivalent of the centralized log-out action. At this point, the hardware 20 if lost, stolen, or compromised contains no sensitive information.

A further addition to the security of the system can be to use Bluetooth® 4.2, which incorporates a security layer, preventing criminals who can get close enough to the Personal Access Network, to prevent them 'scanning' the contents of the Bluetooth transmission. There are many other encoded PANs, but Bluetooth® 4.2 is the most widely known. Its security incorporates 'channel hopping' during the transmissions, so that not only does a criminal have to try and decode the data on the link from a scanner that needs to be very close to the user, but he also needs to know which frequency channel to monitor and when.

In the described embodiments, the cryptographic profile includes a single EPK and one or more offsets associated with respective EzKeys 10. Thus, the user may have multiple cryptographic profiles, with a separate EPK associated with each. However, in some implementations, a cryptographic profile may comprise multiple EPKs for different applications. If all EPKs in the cryptographic profile are encrypted using the same EzKeys 10 and username/password combination, then only a single offset is required for each EzKey 10 for all of the EPKs in the cryptographic profile.

In some arrangements, 'salt' may be used to increase security. In cryptography, a salt is random data that is used as an additional input to a one-way function that "hashes" a password. For example, a salt may be added when the EzKey 10 generates the UPH such that, even if the same password is used for different EPKs, the UPH will be different and so an individual UPH can only decrypt the corresponding EPK(s). In this case, a salt would be stored alongside the offset for the respective EPK(s).

Finally, whilst the above embodiments describe the use of a

username/password combination to generate the UPH, it will be appreciated that a separate username and password are not inherently required. For example, the system could be implemented using just a password, or some other type of reproducible data, such as data derived from a biometric identifier of the user.

Also, whilst the username and password are entered via the computing device 20 running the CSP in this embodiment, it is possible that they could be entered directly into the EzKey 10 by the user, for example via an onboard keypad or biometric sensor.

It can be seen that the advantages of the described system are many fold.

It does not rely on the user having to remember long or complicated passwords.

· The simple password itself is useless without the EzKey 10.

The EzKey 10 is useless without the password.

The encrypted private key is useless without the means to decode it.

A further advantage is that banks and other institutes or service providers no longer have to keep sensitive information, like password copies or hashed password copies on their servers.

As usual, there are many methods of implementing the above invention. The cryptographic key can be replaced by another cryptographic element. The purpose of a PKI (Public Key Infrastructure) is to facilitate the secure and authenticated electronic transfer of information for a range of network activities such as e-commerce, internet banking and confidential email. It is required for activities where simple passwords are an inadequate authentication method and more rigorous proof is required to confirm the identity of the parties involved in the communication and to validate the information being transferred. PKI certificates are well known, and described in many places.

The Username/password pair is in practice a concatenation combination of two strings; the distinction is only useful to suit the user's mental model: a user could own/control many different identities, each one with a different username and the same password, or each one with a different password. · The password can be 'blank' when the username is locally unique (i.e. unique on the EzKey 10 used)

The username, the password, or the username/password combination can be replaced by a biometric

Instead of the username/password combination, a derivative can be used (e.g. a hash of these values) The Client User Software can be any type of program, including an app for mobile devices.

A user can have/own/control as many identities as they like.

Multiple individuals may control a single identity (making it a kind of authority instead). This may be useful in a purchasing department, where all authorized purchasing clerks may have access to a single identity and the related authority to purchase

The user's local hardware 20 can be a desktop computer, laptop, mobile, wearable, or any other computing device.

A profile may hold additional information, like the user's real name, address, pictures and so on.

More than one combination of password and EzKey 10 can be allowed to unlock the encrypted secret key

Thus in summary, a practical and secure authentication system has been described comprised of three principal elements below, all of which have to be used to achieve authentication.

The first element is the user 1 , his simple memorable password, and his interface device 20 (Desktop computer, Laptop, tablet, phone or similar)

The second is the EzKey 10

The third is a publically, semi publically, or privately available profile containing the user's encrypted private key.

It is important to note that the system does not depend on obscurity for its security: it is a cryptographically strong system. Thus, all elements of the system could be open source without compromising its effectiveness.

In the above described embodiments, the EzKey 10 is described as a 'local' device. However, it will be appreciated that the EzKey 10 need only be 'local' from a security of view. That is to say, the EzKey 10 needs to be completely under the control of the user 1 , e.g. 'owned' by the user 1 and by the user 1 alone, as opposed to being controlled by a separate organisation, such as a bank 40 or similar.

Thus, it will be appreciated that in some embodiments, the EzKey 10 may not necessarily be located in physical proximity to the user 1 at the time of use. In practice, communication with the EzKey 10 via communications link 15 should meet the following three criteria to provide good security: 1. The communication between the EzKey 10 and the CSP running on the user terminal 20 is private.

2. The user 1 or the CSP is able to verify that the EzKey 10 being

communicating with is the correct EzKey 10.

3. The physical integrity of the EzKey 10 has not been compromised.

Communication can be easily secured over any distance using TLS (Transport Layer Security), or other encrypted layer. Whilst it will be appreciated that other forms of secure communication may be used, TLS provides a straightforward solution for communication that ensures that the first two requirements are met.

The definition of the physical integrity of the EzKey 10 depends on the specifics of the EzKey 10 implementation, as well on the circumstances and requirements of the user 10. For example, the user 1 may wish to be alerted as soon as the security of the physical location where the EzKey 10 is located is breached, or perhaps when the EzKey 10 is moved outside of a certain physical range. In some embodiments, the EzKey 10 can send an alert when its own physical integrity is compromised. There are many possibilities.

The response to a breach of integrity is also up to the user 1. In one scenario the user 1 may simply be warned. In another scenario the associated Private Keys, other temporary data stored by the EzKey 10 and CSP are immediately and automatically revoked and all their identities and authorizations dropped, or suspended.

Thus, given a secure communication channel, the EzKey 10 can be physically located in a secure environment, possibly under the control of a trusted third party. In many cases it would be sufficient to store the EzKey 10 in a safe place, i.e. other than the site of the user terminal 20, which may be in the office or home of the user 1. One possible proposition is to have the EzKey 10 physically stored in a data centre, along with many others.

In another embodiment, the EzKey 10 could be a virtual device stored in a cloud, e.g. a generic container would be loaded with a specific virtual EzKey 10 implementation, completely under the control of the user 1. A large number of virtual EzKeys 10 would anonymize each individual virtual device, by making it difficult to associate it with their user or users. Both the container and the container's hypervisor could be a weak spot in such a system, but that may be perfectly acceptable, depending on their construction, and on the circumstances and requirements of the user 1.

The 'physical' integrity mentioned earlier when discussing locality is in this scenario also applicable, with the distinction that it pertains to the environment that contains the virtual device: the room, the hardware and the hypervisor.

Claims

Claims:

1. A method comprising:

generating, at least partially on a physical or virtual authentication tool controlled by a user, an intermediate key based on a user code provided by the user and a unique code contained in the authentication tool;

accessing an encrypted cryptographic key, wherein the encrypted cryptographic key is not stored in the authentication tool;

accessing an offset value associated with the encrypted cryptographic key and the authentication tool;

applying the offset value to the intermediate key to generate a decryption key; and

locally decrypting the encrypted cryptographic key using the offset decryption key to give a decrypted cryptographic key.

2. A method according to claim 1 , wherein the authentication tool is incapable of transmitting the unique code to an external device.

3. A method according to claim 1 or 2, wherein the encrypted cryptographic key is stored in a remote location.

4. A method according to claim 1 , 2 or 3, wherein the step of locally decrypting the encrypted cryptographic key is performed on a computing device local to the user.

5. A method according to claim 4, wherein the intermediate key and/or the decryption key is stored in a memory of the computing device, and wherein the intermediate key and/or the decryption key is deleted from the memory of the computing device responsive to interruption of communication between the authentication tool and the computing device.

6. A method according to claim 4 or 5, wherein the decrypted cryptographic key is stored in a memory of the computing device, and wherein the decrypted cryptographic key is deleted from the memory of the computing device responsive to interruption of communication between the authentication tool and the computing device.

7. A method according to claim 4, 5 or 6, wherein the decrypted cryptographic key is never transmitted from the computing device.

8. A method according to any preceding claim, wherein the user code is at least partially derived from a biometric identifier.

9. A method according to any preceding claim, further comprising:

authenticating the user by locally encrypting or decrypting a challenge phrase using the decrypted cryptographic key.

10. A method according to claim 9, wherein the authentication comprises:

receiving an encrypted challenge phrase, the challenge phrase having been encrypted with a public key associated with the user;

locally decrypting the challenge phrase using the decrypted cryptographic key, which is a private key corresponding to the public key; and

sending the decrypted challenge phrase as evidence that the user is in possession of the decrypted private key.

1 1. A method according to claim 9, wherein the authentication comprises:

receiving a challenge phrase;

locally encrypting the challenge phrase using the decrypted cryptographic key; and

sending the encrypted challenge phrase, wherein the encrypted challenge phrase can be decrypted with a public key associated with the user, as evidence that the user is in possession of the decrypted cryptographic key.

12. A method according to any of claims 1 to 8, further comprising:

receiving encrypted data, wherein the encrypted data is encrypted using a public key, and wherein the decrypted cryptographic key is a private key

corresponding to the public key; and

locally decrypting the encrypted data using the decrypted cryptographic key.

13. A method comprising:

generating or receiving a cryptographic key;

generating, at least partially on a physical or virtual authentication tool controlled by the user, an encryption key based on a user code provided by the user and a unique code contained in the authentication tool; and

locally encrypting the cryptographic key using the encryption key to give an encrypted cryptographic key, wherein the encrypted cryptographic key is not then stored in the authentication tool.

14. A method according to claim 13, wherein generating the encryption key comprises:

generating, at least partially on the physical or virtual authentication tool controlled by the user, an intermediate key based on a user code provided by the user and a unique code contained in the authentication tool;

generating an offset value; and

applying the offset value to the intermediate key to generate an encryption key.

15. A method according to claim 13 or 14, wherein the authentication tool is incapable of transmitting the unique code to an external device.

16. A method according to claim 13, 14 or 15, further comprising storing the encrypted cryptographic key in a remote location.

17. A method according to any of claims 13 to 16, wherein the step of locally encrypting the cryptographic key is performed on a computing device local to the user and separate from the authentication tool.

18. A method according to claim 17, wherein the intermediate key and/or the encryption key is stored in a memory of the computing device, and wherein the intermediate key and/or the encryption key is deleted from the memory of the computing device responsive to interruption of communication between the authentication tool and the computing device.

19. A method according to claim 17 or 18, wherein the cryptographic key is stored in a memory of the computing device, and wherein the cryptographic key is deleted from the memory of the computing device responsive to interruption of communication between the authentication tool and the computing device.

20. A method according to claim 17, 18 or 19, wherein the cryptographic key is never transmitted from the computing device in an un-encrypted form.

21. A method according to any of claims 13 to 20, wherein the user code is at least partially derived from a biometric identifier.

22. A method according to any of claims 13 to 21 , wherein the cryptographic key is a private key having an associated public key.

23. A method according to any of claims 13 to 22, wherein the physical token is a first authentication tool, the method further comprising:

generating, at least partially on a second physical or virtual authentication tool controlled by the user, a second intermediate key based on a user code provided by the user and a unique code contained in the second authentication tool; and

calculating an offset value to transform the second intermediate key into the decryption key.

24. A method according to claim 23, wherein the offset value is stored together with the encrypted cryptographic key.

25. A computer program comprising computer readable instructions that, when executed, will cause a computing device to perform a method comprising:

receiving an intermediate key from a physical or virtual authentication tool, the intermediate key having been generated based on a user code provided by the user and a unique code contained in the authentication tool;

accessing an offset value associated with the encrypted cryptographic key and the authentication tool; applying the offset value to the intermediate key to generate a decryption key;

locally decrypting the encrypted cryptographic key using the decryption key to give a decrypted cryptographic key; and

locally encrypting or decrypting data using the decrypted cryptographic key.

26. A computer program comprising computer readable instructions that, when executed, will cause a computing device to perform a method comprising:

generating or receiving a cryptographic key;

receiving an intermediate key from a physical or virtual authentication tool, the encryption key having been generated based on a user code provided by the user and a unique code contained in the authentication tool;

generating or receiving an offset value;

applying the offset value to the intermediate key to generate an encryption key; and