USING A HARDWARE TOKEN

BACKGROUND OF THE INVENTION

[0001] This invention relates to the authentication of a user who wishes to make use of a password protected application such as a website, generally through the medium of the internet.

[0002] A typical website makes use of a user name and a password to keep track of each user. Normally an internet user is confronted with a registration process in order to interact with a target website. A practical reality is that an average website user is not particularly adept at choosing a strong password or at remembering a machine-generated password which, if strong, would likely consist of a lengthy string of unrelated characters.

[0003] A password manager is used to address, at least to some extent, the aforementioned situation. A browser application can establish a password database which is automatically updated as users register passwords on websites and which is stored in the browser. Alternatively the password database can be maintained by a separate application that integrates with the browser.

[0004] A password manager stores passwords, possibly encrypted, at a suitable location but. if an attacker obtains access to the password database, the attacker could use the passwords or, if the passwords have been encrypted, have an unlimited time within which to crack an encryption key to the password database. [0005] An industry-generated standard referred to as FIDO U2F defines a protocol that requires a user to present a token, such as a USB key, in addition to a chosen password, to access a website (say). When the token is presented to a reading device the user is required to perform a user action (e.g. touch a button) in order to authorise a transaction. In other words, user presence is required for the authentication process to be completed. Negatives are that the implementation of the protocol is reliant on the owner of the website, and on support from a browser, for the application programming interface of the FIDO standard. Consequently in respect of all websites where the FIDO protocol has not been implemented the aforementioned problems of password recall and protection remain. [0006] US2015/0199684 describes a secure, non-volatile, solid state memory data key which includes a USB port, a microprocessor and a secure memory for holding secure transaction information. A biometric sensor is used to identify the person who is in physical possession of the data key before permitting access to the secure memory. The microprocessor is configured to provide a chip-and-pin type security for online transactions, particularly at locations at which appropriate readers are not available. Decryption of information in the memory is effected by means of logic resident in the microprocessor. A large part of web browser functionality, relating to online transactions inside the data key, is embedded in the data key. Security is provided by means of a password manager which allows a registered holder of the data key to create and change a password required to utilize the data key for a secure transaction. The password manager may also include a password generator. The data key may include the capability of registering the data key for operation with a specific user and with a specific mobile device that is also registered to the user. In one example of a transaction system implemented through the use of the data key a mobile device is required in addition to a host computer and a website.

[0007] The present invention is concerned with an approach to user authentication which employs a mobile token which requires very little computing resources and which is usable, in conjunction with an external password manager, to provide access to each of a plurality of individually addressable records each of which may contain a respective password. Another object is to allow the token of the invention to be used with different host computers where a respective database is held on each computer.

SUMMARY OF THE INVENTION

[0008] The invention provides a token for user credential authentication which includes:

a port which provides a communication interface with an external device;

a secure cryptographic calculation unit which provides a code, uniquely associated with the token, to the external device;

a non-volatile memory storage unit configured to store data selected from a plurality of individually addressable, optionally encrypted, records;

a processor, responsive to a signal from the external device, to retrieve data from the memory storage unit and to transfer the retrieved data via the port to the external device; and an approval mechanism, responsive to an authenticated user action, to allow user access to at least a part of the transferred data.

[0009] The memory unit may be configured to store data relating to a plurality of passwords. Preferably each password in the memory unit is stored in encrypted form. [0010] The token may be physically engageable with the external device which, typically, is a computer. Such physical engagement, however, is not essential for communication between the external device and a communication module, which usually forms part of the processor in the token, may be achieved in any suitable way, for example through the use of a USB connection, through the use of Near Field Communication (NFC) techniques, using Bluetooth processes, or the like. The invention is not restricted in that regard.

[00 1] The approval mechanism may require a physical user action and, by way of example, may be a mechanical or touch switch. As the mechanism is responsive to a user action the function of the mechanism cannot be initiated by a machine-generated action i.e. user presence is required.

[0012] Use of the token, at least in part, may be dependent on the successful input, by the user, or from some other source, of a master password to the external device.

[00 3] Due to the nature of the token it is usable as a security key in that it is compliant with the FIDO U2F protocol.

[0014] The token is therefore usable effectively in two modes in that it can be used in accordance with the FIDO U2F protocol and, secondly, in respect of those sites or applications which are not FIDO enabled but with a much improved level of security.

[0015] Each individually addressable record, in the memory storage unit, may include a separate password protected area which can be protected by touch (for example) not only for reading but also for any updates or erasure. Thus an individual or a targeted password can be released to a user by means of a touch or an equivalent action. [0016] The data in the token is not encrypted by means of the processor in the token. If encryption is required this is done on the external device which, typically, is a host computer. This approach reduces the cost of the token.

[0017] The mechanism which is responsive to an authenticated user action is thus used to control access to individual data records. Additionally, the mechanism, in that it is responsive to the detection of human presence, can perform universal second factor authentication (U2F).

[0018] The token of the invention offers minimum functionality. This is in contrast to the approach adopted in US2015/0199684 wherein a browser and other applications are embedded in the data key. The latter approach allows for a number of attack vectors since browsers are usually large applications that possibly contain vulnerabilities.

[0019] The unique code, provided by the secure cryptographic calculation unit, allows for the token to be identified so that the token can be synchronized with a particular external device. This enables the data stored in the memory storage unit to be synchronized with the data held in the external device. Such synchronization can take place without reading all of the data contained in the records and without requiring the processor to perform encryption or decryption of the records.

BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The invention is further described by way of example with reference to the accompanying drawings in which .

Figure 1 illustrates in block diagram form the use of a token according to the invention,

Figure 2 is a schematic representation of a possible record structure within a database in the token, and Figure 3 to Figure 8 are flowcharts which respectively depict different processes arising during the use of the token of the invention.

DESCRIPTION OF PREFERRED EMBODIMENT

[0021] Figure 1 of the accompanying drawings illustrates in block diagram form a token 10, according to the invention, which is placed in communication with a personal computer 12.

[0022] The token 10 includes a processor 14 with a communication interface 16, an approval mechanism 18, a security chip 20 with a unique serial number, a permanent memory storage unit 22 and a user approval device 24.

[0023] The communication interface 16 may be provided in the form of a USB connection which can be directly physically coupled to the computer 12. This however is only exemplary for other communication techniques such as Near Field Communication (NFC) processes, Bluetooth processes, or the like, can be employed.

[0024] The approval mechanism 18 is adapted to verify a human input on the device 24. Typically the device 24 is a switch which is mechanically operated or which is sensitive to touch or the like. The device 24 is such that it is not responsive to anything apart from a human input. The mechanism 18 can confirm an input from the device 24 as originating from a human and notify the processor 14 thereof. If an input from the device 24 is not validated the processor 14 is not enabled.

[0025] The security chip 20 acts as a secure cryptographic calculation unit which is used to identify the token 10 to the computer 12. A serial number of the chip is used as a file name for disk storage, in the computer 12, which is used for storage of a password database in the memory unit 22. This allows multiple tokens to be used on a single computer 12, and for a single token 10 to be used on multiple computers. Each token's metadata records are synchronised to a file (database) that has the same name as the token's unique serial number.

[0026] The memory unit 22 is a permanent memory unit e.g. a flash device. [0027] The computer 12 has an application programming interface 30 which embodies a corresponding API presented by the token 20.

[0028] The token 0 is capable of implementing the FIDO U2F protocol. Additionally, though, the token 10 implements a protective process for a password database in the memory unit 22, as is described hereinafter. [0029] A large number of records can be stored in the memory unit 22. Each record can be individually erased or updated. Figure 2 illustrates one possible structure of a record 32 in the memory unit 22. Each record 32 is associated with a unique password.

[0030] The record 32 includes a header 34 which is used to synchronize the token contents with a database which is stored in the computer 12. The header 34 includes a record index, a content identifier which is a random number that is generated with every update to the record, and control flags which govern the use of the record (e.g. protected or not protected).

[0031] Such synchronization, i.e. between the token and any one of a plurality of possible host computers, or, conversely, between a token selected from a plurality of available tokens and a single host computer 12, does not require all the records in the token to be transferred to the host computer, nor is the processor 14 required to perform an encryption or decryption function. [0032] The record 32 also includes a password field 36 whcih is encrypted on the computer 12 and which contains the following sub-fields: a randomly generated number, a randomly generated initialization vector and a password string.

[0033] Metadata 38, encrypted on the computer 12, forms a part of the record 32 and contains the following sub-fields: a user name or identifier, a website URL, user defined notes, entry title, unique record identifier and a password record index made up of references to the database entries that contain the respective passwords.

[0034] The interface 30 makes it possible to perform a number of operations on the password database from an application program. Some of these operations are described hereinafter with reference, where applicable, to Figures 3 to 8.

DATABASE CREATION

[0035] To create a password database the application program executes the following steps:

(1 ) A serial number request is sent to the token 0.

(2) The serial number of the chip 20, in the token, is used in the application program as the name of the database file.

(3) If the database exists already then the database is synchronized with the token 10, as is described hereinafter. However if the database does not yet exist the user chooses a master password that is used to encrypt the data in the file. This master password is used to encrypt the metadata entries, and the password entries, into the database. DATABASE SYNCHRONIZATION

[0036] The synchronization process referred to under the heading "Database Creation" proceeds as follows:

(1) A test record is decrypted to verify that the master password is correct.

(2) If the decryption of the test record is unsuccessful then the user is prevented from using the token and no further action is taken.

(3) If the decryption is successful then the index of each record on the token is read and, if the index read matches the database record index, no action is taken and the index on the next record is read. If the index on the token differs from the database record then the corresponding metadata is read and saved to the database on the computer 12.

[0037] To enhance the security of use of the token 10 the reading of any further record 32 from the token is inhibited unless the computer 12 can signal the token 10 that the last record was successfully decrypted.

[0038] To a substantial extent the sequences which are set out in Figures 3 to 8 are self- explanatory and further detailed descriptions are thus unnecessary.

CREATING A NEW DATABASE RECORD - FIGURE 3

[0039] When the user registers on a new website or starts to use the token 10 for the first time a new record 32 must be created. As a first step the user enters information about the application and/or website to be accessed. The resulting metadata is sensitive in its own right and is encrypted by a process implemented on the computer 12 under the master password referred to under the heading "Database Creation". [0040] If the user has not already chosen or generated a password, a password manager application generates a strong password which is made available to the user. If a new record 32 is to be created the password manager prompts the user to perform an action approval e.g. to touch the input device 24 so that human presence can be detected and notified via the approval mechanism 18 to the processor 4.

BULK OPERATIONS AND BULK APPROVALS - FIGURE 4

[0041] A Bulk Approval state is defined within the token 10. This state allows multiple operations to take place without requiring an approval action for each and every operation.

[0042] When the user chooses a bulk operation in the application the token 10 is requested to do a Bulk Approval operation. Typically a bulk operation such as a universal delete or the making of a backup of the data in the memory module 22 is possible after the user executes specified operations on the device 24. For example the user may be required to touch the input device 24 five times within a predetermined period of, say, five seconds. This prevents a Trojan or rogue program from reading the password from the token. An examination of the flow diagram in Figure 4 shows that if the timer has expired and the actions (required for approval) have not been successfully input then the operation times out. If the Bulk Approval operation is successful then a variable factor is set inside the token and remains effective until the token 10 is removed from the computer 12, or power is removed from the computer 12, or the operation is cancelled by a software command from the computer via the application programming interface 30. An alternative approach would be to reset an internal flag if no further activity has occurred within a certain period of time. TYPICAL USAGE - FIGURE 5

[0043] In use of a password manager a user typically goes through the following steps:

(1 ) selecting the relevant record 32 based on the metadata;

(2) activating a log-in action by executing specific physical functions e.g. by double clicking on the password field or on the copy button, or by pressing a particular key sequence;

(3) if the record is protected the application program prompts the user to do an approval action i.e. to use the input device 24 in the manner which has been defined;

(4) once the user has instructed the password manager application to retrieve a password, the password manager application issues a read operation request to the token 10; and (5) if the record in question is protected the token 10 waits for the user to perform an approval action - again in accordance with a particular physical sequence of the kind referred to hereinbefore. If approval is not obtained no password is returned and the user is notified.

RECORD DELETE OPERATION - FIGURE 6

[0044] A protected record can only be deleted from the memory unit 22 if the user performs an approval action. The sequence of steps in this regard is similar to that detailed under the heading "Bulk Approvals" - this is evident from a comparison of Figure 4 with Figure 6. This sequence of operations is therefore not further described.

PASSWORD DATABASE ACCESS ON TOKEN - FIGURE 7

[0045] Figure 7 depicts the general operation of the password database feature of the token. If a Bulk Approval exercise has been performed an operation such as a "read/write" or "delete" can be performed without further approval. If the record 32 in question is marked as a protected record in the flags in the field 34 (Figure 2) the token waits for user approval to be obtained (in the manner already described) using the input device 24. If no user approval is forthcoming within a specific time period the operation fails.

POWER ON RESET - FIGURE 8

[0046] At "power on" a bulk operation flag is reset. [0047] A benefit of the token 10 lies in the fact that stored passwords are readable or writable only when the input device 24 is utilized. Typically a single touch on the device is used to release or update a password. Bulk operations are possible only after a predetermined sequence of operations is carried out e.g., as described the user must touch the device 24 a number times within a prescribed time period. [0048] It is also possible to protect access to the database in the token using an on- microprocessor test of the master password. In this instance the user has only a limited number of attempts to unlock the password database for first use. This is similar to the PIN protection afforded on a smart card device. In this mode the requirement for being able to read the database records is the presentation of a PIN and simultaneously obtaining approval by activating the input device 24.