GB2555401A - Improvements in or relating to authentication - Google Patents
Improvements in or relating to authentication Download PDFInfo
- Publication number
- GB2555401A GB2555401A GB1617928.5A GB201617928A GB2555401A GB 2555401 A GB2555401 A GB 2555401A GB 201617928 A GB201617928 A GB 201617928A GB 2555401 A GB2555401 A GB 2555401A
- Authority
- GB
- United Kingdom
- Prior art keywords
- authentication
- smartcard
- user
- virtual
- virtual smartcard
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
- 230000007246 mechanism Effects 0.000 claims abstract description 134
- 238000000034 method Methods 0.000 claims abstract description 41
- 238000010200 validation analysis Methods 0.000 claims abstract description 33
- 238000012795 verification Methods 0.000 claims description 10
- 230000008569 process Effects 0.000 claims description 6
- 230000000977 initiatory effect Effects 0.000 claims description 2
- 230000001934 delay Effects 0.000 description 3
- 230000001815 facial effect Effects 0.000 description 3
- 230000004044 response Effects 0.000 description 3
- 230000009286 beneficial effect Effects 0.000 description 2
- 238000004891 communication Methods 0.000 description 2
- 230000036541 health Effects 0.000 description 2
- 238000012790 confirmation Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/32—User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/351—Virtual cards
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Business, Economics & Management (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Accounting & Taxation (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- General Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Computer Networks & Wireless Communication (AREA)
- Software Systems (AREA)
- Finance (AREA)
- Computing Systems (AREA)
- Signal Processing (AREA)
- Microelectronics & Electronic Packaging (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
An authentication method and system involves receiving a request for authentication from a users authentication mechanism 8, which is based upon a device, article, biometric data for example, and an authentication bridge 9 identifying a virtual smartcard associated with the authentication mechanism 14. The authentication bridge 9 comprises a virtual smartcard store capable of storing multiple virtual smartcards 10. The authentication bridge also requests validation of the authentication mechanism 14, and makes the virtual smartcard available to authenticate the user associated with the authentication mechanism 14 upon successful validation. An authentication client 3 is also provided which has a classification engine for determining whether a received authentication mechanism is a physical smartcard, and transmitting information received from the authentication mechanism to the authentication bridge 9 if the authentication mechanism is not a physical smartcard.
Description
(71) Applicant(s):
Isosec Limited
Blackfriars House, The Parsonage, MANCHESTER, M3 2JA, United Kingdom (56) Documents Cited:
WO 2001/018635 A1 US 20150142669 A1
WO 2001/008113 A1 US 20090132813 A1 (58) Field of Search:
INT CL G06F, G06Q, H04L
Other: Online: WPI, EPODOC, TXTA (72) Inventor(s):
Matej Suster Marc Poulard (74) Agent and/or Address for Service:
Wilson Gunn
5th Floor, Blackfriars House, The Parsonage, MANCHESTER, M3 2JA, United Kingdom (54) Title of the Invention: Improvements in or relating to authentication Abstract Title: Enabling authentication using virtual smartcard (57) An authentication method and system involves receiving a request for authentication from a user’s authentication mechanism 8, which is based upon a device, article, biometric data for example, and an authentication bridge 9 identifying a virtual smartcard associated with the authentication mechanism 14. The authentication bridge 9 comprises a virtual smartcard store capable of storing multiple virtual smartcards 10. The authentication bridge also requests validation of the authentication mechanism 14, and makes the virtual smartcard available to authenticate the user associated with the authentication mechanism 14 upon successful validation. An authentication client 3 is also provided which has a classification engine for determining whether a received authentication mechanism is a physical smartcard, and transmitting information received from the authentication mechanism to the authentication bridge 9 if the authentication mechanism is not a physical smartcard.
Fig 2
At least one drawing originally filed was informal and the print reproduced here is taken from a later filed formal copy.
1/1
10 17
IMPROVEMENTS IN OR RELATING TO AUTHENTICATION
Technical Field of the Invention
The present invention relates to improvements in or in relation to authentication.
In particular, the present invention relates to methods and systems enabling 5 authentication by use of a virtual smartcard.
Background to the Invention
Data security is taken very seriously in many organisations and, as a result, such organisations require authentication of users for access to devices or systems.
One example of authentication utilises a physical cryptographic smartcard. In use, in order to access systems or devices, the user places their smartcard in, on or against a reader associated with a computing device. An authentication client running on the device recognises the presence of the smartcard. This prompts the client to ask the user to input a secret credential such as a password, pin or similar into the computing device, and request a challenge from an authentication server to which the computing device is connected, for example via a computer network. The client passes the credential inputted by the user and the challenge received from the authentication server to the smartcard. If the user inputted credential is correct the smartcard digitally signs the challenge with a cryptographic key and the signed challenge is transmitted to the client, and from the client to the server. The authentication server then verifies if the digital signature is valid by cryptographic means. If so, it issues an access token to the client which enables the user to access particular services or information using the computing device, to the limits of the access token. If the digital signature is not valid no access token is issued.
Whilst cryptographic smartcard authentication provides excellent security, it can be costly and/or difficult to administer. Issuing physical smartcards is costly. Not only must cards be provided, but staff and equipment are needed to create and issue cards to users, and re-issue cards if they are lost. Lost cards may pose a threat to system security. Personnel awaiting the issuance or reissuance of a smartcard before undertaking work can cost organisations significant sums. This is particularly true of organisations that utilise many temporary or agency staff such as the UK National
Health Service.
Also, it may be difficult or impractical to provide smartcard readers for some devices, such as tablet computers. An additional issue is that the authentication process takes some time. Accordingly, there can be a delay between a user logging on and being able to access a particular system or device. This is inconvenient.
It is therefore an object of embodiments the present invention to address the problems associated with the prior art.
Summary of the Invention
According to a first aspect of the present invention, there is provided a method of authenticating a user utilising a virtual smartcard to access a device, application or system secured by a smartcard based authentication system, the method comprising:
receiving a request for authentication from a user’s authentication mechanism;
identifying a virtual smartcard associated with the authentication mechanism;
requesting validation of the authentication mechanism; and on successful validation making the virtual smartcard available to authenticate the user associated with the authentication mechanism.
The present method therefore enables access to a device, application or system 5 secured by a smartcard based authentication system without requiring the issuance of a physical smartcard, or a physical smartcard which may be used directly to access the device, application or system. This can result in savings in the cost and complexity of managing access to such systems for temporary users without requiring a full system redesign or the abandonment of smartcard use for existing users. It additionally provides for secure access to devices that do not support use of a physical smartcard reader. Furthermore, it reduces the need to keep track of and cancel lost or missing smartcards. Additionally, storing virtual credentials in the cloud ensures that they are not left on smartcards that could if lost or stolen be utilised by others.
The virtual smartcard may comprise the same cryptographic functionality as a 15 physical cryptographic smartcard it replaces.
Any or all of the steps of receiving a request for authentication from a user’s authentication mechanism; identifying a virtual smartcard associated with the authentication mechanism; requesting validation of the authentication mechanism; and on successful validation making the virtual smartcard available to authenticate the user 20 associated with the authentication mechanism may be carried out by an authentication bridge forming part of or linked to an existing smartcard based authentication client and/or authentication server. This facilitates implementing the present method alongside an existing smartcard based authentication client.
The step of making the virtual smartcard available to authenticate the user associated with the registered authentication mechanism may comprise requesting an authentication challenge from an authentication server, digitally signing the challenge using the virtual smartcard and returning the signed challenge to the authentication server.
The method may include the additional step of determining whether the request utilises a virtual smartcard. If it is determined that the request utilises a conventional smartcard which can be used directly against the system, the authentication request may be processed conventionally, such as by using an existing smartcard based authentication client. This facilitates implementing the present method alongside an existing smartcard based authentication client.
The step of requesting validation may include requesting information from the user. The authentication mechanism may be validated by requesting information via the verification mechanism, or via the device the user is seeking access to.
The authentication mechanism may be based upon a user device. In particular, the device may be a user’s smartphone or the like. In such instances, the user may be required to input validation data to the device. The device may then transmit the validation data to an authentication bridge or server. Alternatively, the device may perform an initial verification of the validation data and then transmit details of the outcome of the validation verification to the authentication bridge or server. The authentication data may comprise a password code or similar or may comprise biometric data such as an iris scan, a fingerprint scan or facial scan. Using user devices such as a smartphone as the authentication mechanism is convenient for a user and may incline the user to take greater care of the authentication mechanism and/or become aware of loss or damage to the authentication mechanism much earlier than might otherwise be the case.
The authentication mechanism may be based upon a user article. Such an article may comprise another suitable card in the user’s possession such as a credit card or debit card. Preferably such cards are enabled for use in chip based or NFC (near field communications) based smartcard readers. This can enable a user to utilise an existing card intended for other purposes alongside their virtual smartcard to complete authentication. Using such existing cards as the authentication mechanism is convenient for a user and may incline the user to take greater care of the authentication mechanism and/or become aware of loss or damage to the authentication mechanism much earlier than might otherwise be the case. Use of the card may be particularly convenient in instances where the use of devices such as smartphones is restricted. It will be appreciated that the authentication mechanism could actually be a smartcard provided for a different purpose than to access the device, application or system in question.
The authentication mechanism may be based upon a biometric data. Suitable biometric data may include an iris scan, a fingerprint scan or facial scan. Using such biometric data as the authentication mechanism is convenient for a user and very difficult to spoof. Such data does have the drawback or requiring suitable biometric data scanners to be provided. Use of biometric data may be particularly convenient in instances where the use of devices such as smartphones is restricted.
The method may include the steps of registering a virtual smartcard for use in connection with a smartcard based authentication system. The registration process may include the step of obtaining user details and generating a virtual smartcard associated with said user details. The generated virtual smartcard may be stored in a virtual smartcard store. Typically, the virtual smartcard store may be cloud based. The registration process may include the step of registering an associated authentication mechanism for the virtual smartcard. The associated authentication mechanism may require validation before being stored. In the case of a device, validation may involve responding appropriately to a validation request sent to the device. For instance, the validation request may involve the sending of a validation code to the device, which must subsequently be reported or replied to by the user.
In some embodiments, there may be a primary authentication mechanism associated with a virtual smartcard and one or more additional authentication mechanisms. This can enable a user to utilise a device such as a phone as a primary authentication mechanism. Subsequently, one or more articles, such as credit or debit cards, may be registered as additional authentication mechanisms; or one or more items of biometric data may be registered as additional authentication mechanisms. This can allow the user to utilise the primary authentication mechanism where possible but additionally or alternatively to use alternative authentication mechanisms. This is beneficial to enable access in the case of loss of the primary mechanism and/or where access utilising the primary mechanism is impractical or impossible. The latter may occur where the primary mechanism is a smartphone and authentication is required in an area where use of a personal smartphone is not permitted.
The registration of a virtual smartcard may include the steps of setting permitted access for the virtual smartcard. The permitted access may be general for a device, application or system or may be limited by device, application, subsystem, user account or time. In this manner, user authentication to access a device, application or system may be restricted automatically. Similarly, user authentication to access a device, application or system outside a permitted time period may be restricted automatically. This can enable temporary workers to be barred from accessing devices, applications or systems once their period of temporary employment has ceased and/or to prevent workers accessing devices or systems outside of their permitted working hours. This provides greater security particularly in relation to restricting access of lost or stolen cards (which may not be noticed until the next shift) or in respect of temporary workers who fail to return issued smartcards.
Where permitted access is time limited, the method may include the step of partial pre-authentication in advance of a permitted authentication period. The partial pre-authentication may be initiated at a threshold interval prior to the start of a permitted access period. The threshold interval may be pre-set or may be variable. Typically, the threshold interval may be of the order of minutes. Initiation of partial pre15 authentication may include the steps of identifying the virtual smartcard and an associated registered authentication mechanism; and generating an access token corresponding to the virtual smartcard. Upon receiving an authentication request, the authentication may be verified; and if verification is successful, the generated access token may be issued. Accordingly, the authentication process can take place more quickly. This can help reduce delays in authenticating users for access at the start of their shifts.
In a preferred embodiment, the authentication method is an authentication method for use in the healthcare sector.
According to a second aspect of the present invention there is provided an authentication system for authenticating a user utilising a virtual smartcard to access a device, application or system, the system comprising: a user interface for receiving a request for authentication using an authentication mechanism; and an authentication bridge arranged to: identify a virtual smartcard associated with the authentication mechanism; request validation of the registered authentication mechanism; and, if validation is successful, make the virtual smartcard available to authenticate a user associated with the registered authentication mechanism.
The system of the second aspect of the present invention may incorporate any 10 or all features of the first aspect of the present invention, as desired or as required.
The system may be operable to determine whether the request utilises a virtual smartcard. If the system determines that the request utilises a conventional smartcard that can be used directly against the system, the authentication request may be processed conventionally by an existing smartcard based authentication server. This facilitates implementing the present method alongside an existing smartcard based authentication client. In particular the authentication system may comprise a classification engine for determining if the authentication mechanism is a physical smartcard and, if so, arranged to request an authentication challenge from an authentication server.
The authentication bridge may be arranged, on successful validation of the authentication mechanism, to request an authentication challenge from an authentication server.
The authentication mechanism may be based upon a user device, user article or user biometric data. Where the authentication mechanism is based upon a user device, the user may be required to input authentication data to the user device. The device may then transmit the authentication data to the authentication bridge or server. The data may be transmitted via an authentication client. Alternatively, the user device may perform an initial verification on the authentication data and then transmit details of the outcome of the initial verification to the authentication bridge or server. The authentication data may comprise a password code or similar or may comprise biometric data such as an iris scan, a fingerprint scan or facial scan. Using user devices such as a smartphone as the authentication mechanism is convenient for a user and may incline the user to take greater care of the authentication mechanism and/or become aware of loss or damage to the authentication mechanism much earlier than might otherwise be the case.
The authentication bridge may be provided with a registration module. The 15 registration module may be operable to enable the registration of a virtual smartcard for use in connection with a smartcard based authentication system. The registration module may be operable to receive user details and generate a virtual smartcard associated with said user details. The generated virtual smartcard may be stored in a virtual smartcard store. Typically, the virtual smartcard store may be cloud based. The registration module may be operable to register an associated authentication mechanism for the virtual smartcard.
In some embodiments, the registration module may be operable to associate a primary authentication mechanism with a virtual smartcard and to associate one or more additional authentication mechanisms with a virtual smartcard. This can enable a user to utilise a device such as a phone as a primary authentication mechanism. Subsequently, one or more articles, such as credit or debit cards, may be registered as additional authentication mechanisms; or one or more items of biometric data may be registered as additional authentication mechanisms. This can allow the user to utilise the primary authentication mechanism where possible but additionally or alternatively to use alternative authentication mechanisms. This is beneficial to enable access in the case of loss of the primary mechanism and/or where access utilising the primary mechanism is impractical or impossible. The latter may occur where the primary mechanism is a smartphone and authentication is required in an area where use of a personal smartphone is not permitted.
The registration module may be operable to set permitted access for a virtual smartcard. The permitted access may be general for a device, application or system or may be limited by device, application, subsystem, user account or time. In this manner, user authentication to access a device, application or system may be restricted automatically. Similarly, user authentication to access a device, application or system outside a permitted time period may be restricted automatically. This can enable temporary workers to be barred from accessing devices, applications or systems once their period of temporary employment has ceased and/or to prevent workers accessing devices or systems outside of their permitted working hours. This provides greater security particularly in relation to restricting access of lost or stolen cards (which may not be noticed until the next shift) or in respect of temporary workers who fail to return issued smartcards.
The authentication system may be provided with or linked to a partial preauthentication module operable to initiate partial pre-authentication in advance of a permitted authentication period. The partial pre-authentication may be initiated at a threshold interval prior to the start of a permitted access period. The threshold interval may be pre-set or may be variable. Typically, the threshold interval may be of the order of minutes. The partial pre-authentication module may be operable at a threshold interval prior to the start of a permitted access period to cause the authentication bridge to identify the virtual smartcard and an associated registered authentication mechanism; and cause the authentication bridge to obtain an access token corresponding to the virtual smartcard from an authentication server. Upon receiving an authentication request, the authentication bridge may be operable to validate the authentication utilising the registered authentication mechanism; and if validation is successful, issue the previously obtained access token. This can help reduce delays in authenticating users for access at the start of their shifts.
In a preferred embodiment, the authentication system is for use in the healthcare sector.
According to a third aspect of the present invention there is provided a device, application or system comprising an authentication system according to the second aspect of the present invention or implementing an authentication method according to the first aspect of the present invention.
The device, application or system of the third aspect of the present invention may comprise any or all features of the first or second aspects of the present invention, as desired or as required.
According to a fourth aspect of the invention there is provided an authentication client for authenticating a user utilising a virtual smartcard to access a device, application or system, the client comprising: a user interface for receiving a request for authentication from the user’s authentication mechanism; and a classification engine for determining if the authentication mechanism is a physical smartcard and arranged, where the authentication mechanism is not a physical smartcard, to transmit information received from the authentication mechanism to an authentication bridge.
If the classification engine determines that the authentication mechanism is a physical smartcard it may be arranged to request an authentication challenge from an authentication server.
In a preferred embodiment, the device, application or system is a device, 10 application or system for use in the healthcare sector.
Detailed Description of the Invention
In order that the invention may be more clearly understood embodiments thereof will now be described, by way of example only, with reference to the accompanying drawings, of which:
Figure 1 is a schematic illustration of a cryptographic smartcard based authentication system according to the prior art; and
Figure 2 is a schematic illustration of an authentication system for authenticating a user utilising a virtual smartcard according to the present invention.
Turning now to figure 1, a user 1, such as a UK National Health Service (NHS) 20 employee, wishes to gain access to a software application 2 running on a personal computer 3.
In order to do so, their access must be authorised using their physical NHS smartcard 4. This is achieved by reading the smartcard with a reader 5 connected to the personal computer 3.
Authentication client software 6 is running on the personal computer 3. The 5 authentication client causes the computer to prompt a user to enter a credential, such as a password or pin, and to request an authentication challenge from an authentication server 7 to which the personal computer is connected via a computer network. The authentication client causes both the credential input by the user and the authentication challenge received from the authentication server 7 to be transmitted to the smartcard
4 via the reader 5. The smartcard 4 is arranged, on receipt of the correct user inputted credential, to apply a digital signature to the authentication challenge using a private cryptographic key stored on the smartcard 4. The client then causes the computer to read the digital signature from the smartcard and transmit it back to the authentication server 7 for verification. If the signature is verified by the authentication server 7 it generates an access token and transmits this to the authentication client which stores it on the personal computer. Presence of this token on the personal computer the enables the user to access the desired software application, to the extent that they are authorised to do so.
Use of such cryptographic smartcards for user authentication is well known and so is not described in further detail.
Whilst this system is relatively robust and well understood, it has some drawbacks including the cost or difficultly of rapid administration particularly in issuing smartcards to new users or dealing with reissuance of smartcards due to loss or theft. It can also be impractical to connect smartcard readers to some devices and the authentication process can take some time causing a delay between a user logging on and being able to access a particular system or device.
Accordingly, in the present invention an improved authentication system is 5 proposed, but one which is compatible with existing authentication servers.
Referring to figure 2 (in which corresponding reference numerals are used to identify corresponding features to those shown in figure 1) a personal computer 3 or other device 3 is provided with a card reader 5 and authentication client software 6 runs on the personal computer.
To access a software application 2 on the personal computer 3, for which authentication is required, a user may still use a physical cryptographic smartcard 4 to make an authentication request. When a physical cryptographic smartcard is recognised as one which may be used against the authentication server 7 the authentication client 6 causes the computer to operate in the same way as the system illustrated in figure 1.
The authentication client may recognise whether or not a presented cryptographic smartcard as one which may be used against the authentication server by sending an ATR command to the card, causing the smartcard to return information identifying the type of card to the server, and/or by a certificate retrieved from the card.
The authentication client 6 is, however, additionally operable to enable authentication to take place using a virtual smartcard, which is identified using an authentication mechanism 8.
In this case the authentication mechanism 8 is used to make an authentication request, by providing an identity to the authentication client 6. The authentication client determines that the authentication mechanism is not a cryptographic smartcard (or not a cryptographic smartcard which may be used against the authentication server 7) and, having done so, transmits information from the authentication mechanism to an authentication bridge 9 via a computer network. The authentication bridge may be provided on a server separate to the authentication server, or it could be provided on the authentication server.
The authentication bridge 9 comprises a virtual smartcard store capable of storing multiple virtual smartcards 10, each smartcard associated with information 11 identifying a registered user authentication mechanism 8 and associated validation data
12.
On receipt of information from an authentication mechanism the virtual bridge is arranged to search the stored information identifying registered user authentication mechanisms to find a match. If a match is found, a request for validation data is sent to the user via the personal computer and/or the authentication mechanism (as discussed further below). If a response is received, the authentication bridge 9 compares that with the stored validation data 12 associated with the authentication mechanism in question in order to verify the request. If verification is successful, that is the information requested from the user corresponds to that stored in the authentication bridge, the authentication bridge requests an authentication challenge from the authentication server. On receipt of the challenge the authentication bridge causes the virtual smartcard associated with the identification device to digitally sign the authentication challenge and returns it to the authentication server 7 which authenticates the signature as if it had been applied by a conventional physical smartcard. If the signature is authenticated the server returns an access token to the authentication bridge which in turn sends this to the personal computer enabling the user 1 to use the application software 2. Thus authentication of a user by smartcard has been achieved, but with the user providing alternative identification to a physical cryptographic smartcard.
The authentication mechanism 14 might be, for example, a user’s smartphone 5 which might be identified by card reader 5 or some other device connected to the personal computer, or by a user entering a telephone number of their phone into the personal computer. In such cases, the user 1 may be requested to input validation data into the smartphone in order to validate an authentication request. The data might be a password or PIN. This data is sent the by the phone to the authentication bridge, possibly by the authentication client. If the smartphone is suitably equipped the validation data might be a fingerprint scan or other biometric data.
In other embodiments, the authentication mechanism might be a personal article such as a credit or debit card. If such a card is NFC compatible it might be read by the smartcard reader 5 and/or by smart phones tablets or other NFC equipped devices in communication with the personal computer 2. Information from the card can thus be used to identify the user.
In yet other embodiments the authentication mechanism could be a smartcard (including a cryptographic smartcard) issued for some other purpose, and so which cannot be used against the authentication server from which the user seeks authentication.
In cases where the device, application or system is provided with a biometric reader 13, the authentication mechanism may be biometric data input to the biometric reader.
Use of a user’s personal device, a personal article or biometric data means that no dedicated smartcard needs to be produced. This eliminates the cost of issuing a smartcard to the user and eliminates costs associated with the potential, theft, loss or damage of the smartcard. It further avoids the prospect of unauthorised persons being able to access cryptographic keys on a lost/stolen smartcard. Where the authentication mechanism is a user’s personal device or a personal article there is also an increased likelihood of loss of the article being noticed outside working hours and therefore reported in a timely fashion. This may also enhance overall security.
In order to generate a virtual smartcard and to register an associated 10 authentication mechanism 8, an optional registration module 15 can be provided. The registration module 15 may be operable in response to an operator (not shown) using an existing registration authority system (not shown). The operator may obtain suitable details of the user and their identity from the user (or otherwise) to generate a virtual smartcard and store said smartcard in the virtual smartcard store on the authentication bridge 9. In response to a user 1 indicating their preferred authentication mechanism 8, the operator can use the registration module to verify the authentication mechanism
14. In the case of a phone, this may be by way of sending a code to the phone and by requesting confirmation of the code by the user. In the case of a bank card, this may be by way of inserting the card into a local card reader. In the case of biometric data, this may be by way of capturing biometric data from the user directly.
In some embodiments, the registration module 15 may be operable to enable the association of one or more additional authentication mechanisms for a user 1. Such additional authentication mechanisms 8 may be used as a backup in the event of loss or damage to the primary authentication mechanism 8. Additionally, such additional authentication mechanisms 8 may be used in instances where the primary authentication mechanism 8 is not possible or not practical.
In some embodiments, the registration module 15 may be operable to set permitted access for a virtual smartcard. The permitted access may be general access or access limited by device, application or system. Additionally, or alternatively, the access may be restricted or prohibited outside a permitted time period. This can enable temporary workers to be barred from accessing devices, applications or systems once their period of temporary employment has ceased and/or to prevent workers accessing devices, applications or systems outside of their permitted working hours.
In such embodiments, an optional partial pre-authentication module 14 may be provided. The partial pre-authentication module 14 is operable to initiate partial preauthentication for a virtual smartcard in advance of a permitted authentication period. The partial pre-authentication may be initiated at a threshold interval, say 5-15 minutes, prior to the start of a permitted access period. For instance, for a user 1 permitted access to a device, application or system from 0900, the threshold interval may be set 10 mins early (0850).
At the start of the threshold interval the partial pre-authentication module 14 causes the authentication bridge 9 to identify the virtual smartcard and an associated registered authentication mechanism 8 for a particular user. Subsequently, the authentication bridge 9 requests an authentication challenge from the authentication server, causes this to be signed by the virtual smartcard for the user and returns the signed authentication challenge to the authentication server thereby causing the authentication server to issue an access token in advance of the user 1 requesting access.
This access token is stored by the authentication bridge. Upon receiving an authentication request from the user 1 using a registered authentication mechanism the authentication bridge causes this to be validated in the usual way. On successful validation the authentication bridge 9 issues the previously generated and stored access token. This can help reduce delays in authenticating users for access at the start of their shifts.
The above embodiments are described by way of example only. Many variations are possible without departing from the scope of the invention as defined in the appended claims.
Claims (22)
1. A method of authenticating a user utilising a virtual smartcard to access a device, application or system secured by a smartcard based authentication system, the method comprising:
5 a. receiving a request for authentication from a user’s authentication mechanism;
b. identifying a virtual smartcard associated with the authentication mechanism;
c. requesting validation of the authentication mechanism; and
10 d. on successful validation making the virtual smartcard available to authenticate the user associated with the authentication mechanism.
2. A method as claimed in claim 1 wherein step d. comprises requesting an authentication challenge from an authentication server, digitally signing the challenge using the virtual smartcard and returning the signed challenge to the
15 authentication server.
3. A method as claimed in either claim 1 or 2 wherein the authentication mechanism is validated by requesting information via the verification mechanism.
4. A method as claimed in any preceding claim wherein the authentication
20 mechanism is based upon a user device.
5. A method as claimed in any preceding claim wherein the authentication mechanism is based upon a user article
14. A method as claimed in claim 13 wherein the partial pre-authentication is initiated at a threshold interval prior to the start of a permitted access period.
15. A method as claimed in claim 13 or claim 14 wherein initiation of partial preauthentication includes the steps of identifying the virtual smartcard and an
5 associated registered authentication mechanism; and obtaining an access token using the virtual smartcard.
16. A method as claimed in claim 15 wherein upon receiving and successfully validating an authentication request the previously generated access token is issued.
10 17. An authentication system for authenticating a user utilising a virtual smartcard to access a device, application or system, the system comprising: a user interface for receiving a request for authentication using an authentication mechanism; and an authentication bridge arranged to: identify a virtual smartcard associated with the authentication mechanism; request validation of the registered
15 authentication mechanism; and if validation is successful, make the virtual smartcard available to authenticate a user associated with the registered authentication mechanism.
18. An authentication system as claimed in claim 17 wherein the authentication bridge is arranged, on successful validation of the authentication mechanism, to
20 request an authentication challenge from an authentication server.
19. An authentication system as claimed in either claim 17 or 18 comprising a classification engine for determining if the authentication mechanism is a physical smartcard and, if so, arranged to request an authentication challenge from an authentication server.
20. An authentication system as claimed in any one of claims 17 to 19 wherein the authentication mechanism is based upon a user device.
5
21. An authentication system as claimed in any one of claims 17 to 20 wherein the authentication mechanism is based upon a user article.
22. An authentication system as claimed in any one of claims 17 to 21 wherein the authentication mechanism is based upon user biometric data.
23. An authentication system as claimed in any one of claims 17 to 22 wherein the
10 authentication system is provided with a registration module operable to enable the registration of a virtual smartcard.
24. An authentication system as claimed in claim 23 wherein the registration module is operable to register an associated authentication mechanism for the virtual smartcard.
15
25. An authentication system as claimed in claim 24 wherein the registration module is operable to associate a primary authentication mechanism with a virtual smartcard and to associate one or more secondary authentication mechanisms with a virtual smartcard.
26. An authentication system as claimed in any one of claims 23 to 25 wherein the
20 registration module is operable to set permitted access for a virtual smartcard.
27. An authentication system as claimed in claim 26 wherein the authentication system is provided with a partial pre-authentication module operable to initiate partial pre-authentication in advance of a permitted authentication period.
28. An authentication system as claimed in claim 27 wherein the partial pre5 authentication module is operable to cause the authentication bridge to identify the virtual smartcard and an associated registered authentication mechanism; and cause the authentication bridge to obtain an access token corresponding to the virtual smartcard.
29. An authentication system as claimed in claim 28 wherein upon receiving an
10 authentication request, the authentication bridge is operable to verify the authentication utilising the registered authentication mechanism; and if verification is successful, issue the previously obtained access token.
30. A device, application or system comprising an authentication system according to any one of claims 17 to 29 or implementing an authentication method
15 according to any one of claims 1 to 16.
31. An authentication client for authenticating a user utilising a virtual smartcard to access a device, application or system, the client comprising: a user interface for receiving a request for authentication from the user’s authentication mechanism; and a classification engine for determining if the authentication 20 mechanism is a physical smartcard and arranged, where the authentication mechanism is not a physical smartcard, to transmit information received from the authentication mechanism to an authentication bridge.
32. An authentication client as claimed in claim 31 wherein if the classification engine determines that the authentication mechanism is a physical smartcard it is arranged to request an authentication challenge from an authentication server.
Intellectual
Property
Office
Application No: Claims searched:
GB1617928.5
1-30
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB1617928.5A GB2555401A (en) | 2016-10-24 | 2016-10-24 | Improvements in or relating to authentication |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB1617928.5A GB2555401A (en) | 2016-10-24 | 2016-10-24 | Improvements in or relating to authentication |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| GB201617928D0 GB201617928D0 (en) | 2016-12-07 |
| GB2555401A true GB2555401A (en) | 2018-05-02 |
Family
ID=57738140
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| GB1617928.5A Withdrawn GB2555401A (en) | 2016-10-24 | 2016-10-24 | Improvements in or relating to authentication |
Country Status (1)
| Country | Link |
|---|---|
| GB (1) | GB2555401A (en) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2001008113A1 (en) * | 1999-07-22 | 2001-02-01 | Visa International Service Association | Internet payment, authentication and loading system using virtual smart card |
| WO2001018635A2 (en) * | 1999-09-03 | 2001-03-15 | Secure Computing Corporation | Virtual smart card system and method |
| US20090132813A1 (en) * | 2007-11-08 | 2009-05-21 | Suridx, Inc. | Apparatus and Methods for Providing Scalable, Dynamic, Individualized Credential Services Using Mobile Telephones |
| US20150142669A1 (en) * | 2013-11-16 | 2015-05-21 | Mads Landrok | Virtual payment chipcard service |
-
2016
- 2016-10-24 GB GB1617928.5A patent/GB2555401A/en not_active Withdrawn
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2001008113A1 (en) * | 1999-07-22 | 2001-02-01 | Visa International Service Association | Internet payment, authentication and loading system using virtual smart card |
| WO2001018635A2 (en) * | 1999-09-03 | 2001-03-15 | Secure Computing Corporation | Virtual smart card system and method |
| US20090132813A1 (en) * | 2007-11-08 | 2009-05-21 | Suridx, Inc. | Apparatus and Methods for Providing Scalable, Dynamic, Individualized Credential Services Using Mobile Telephones |
| US20150142669A1 (en) * | 2013-11-16 | 2015-05-21 | Mads Landrok | Virtual payment chipcard service |
Also Published As
| Publication number | Publication date |
|---|---|
| GB201617928D0 (en) | 2016-12-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20220052852A1 (en) | Secure biometric authentication using electronic identity | |
| CA2975843C (en) | Apparatus, system, and methods for a blockchain identity translator | |
| US8775814B2 (en) | Personalized biometric identification and non-repudiation system | |
| US6970853B2 (en) | Method and system for strong, convenient authentication of a web user | |
| US11057372B1 (en) | System and method for authenticating a user to provide a web service | |
| US20070118758A1 (en) | Processing device, helper data generating device, terminal device, authentication device and biometrics authentication system | |
| US20120032782A1 (en) | System for restricted biometric access for a secure global online and electronic environment | |
| US11843599B2 (en) | Systems, methods, and non-transitory computer-readable media for secure biometrically-enhanced data exchanges and data storage | |
| JP2015525409A (en) | System and method for high security biometric access control | |
| WO2021030388A1 (en) | Systems and methods for use in provisioning tokens associated with digital identities | |
| US10523654B1 (en) | System and method to integrate secure and privacy-preserving biometrics with identification, authentication, and online credential systems | |
| JP6760631B1 (en) | Authentication request system and authentication request method | |
| JP4802670B2 (en) | Cardless authentication system, cardless authentication method used in the system, and cardless authentication program | |
| US20160342996A1 (en) | Two-factor authentication method | |
| US20230327876A1 (en) | Authentication apparatus and authentication method | |
| RU2573235C2 (en) | System and method for checking authenticity of identity of person accessing data over computer network | |
| GB2555401A (en) | Improvements in or relating to authentication | |
| CN112560116A (en) | Function control method, device and storage medium | |
| KR101568374B1 (en) | Mobile loan method and system using mobile digital signature | |
| KR101536122B1 (en) | Secure User Authentication Scheme using SmartCard in Printer Security Device Method | |
| KR102140462B1 (en) | Authentication processing method of block-chain service, and computer program | |
| US20230388310A1 (en) | System and method for biometrically binding verifiable credentials to identity | |
| KR20110115256A (en) | Electronic signature management method using signer identification | |
| KR102034971B1 (en) | Method for Providing Compatibility Authentication Service by Using Financial App | |
| KR101171003B1 (en) | A system for financial deals |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| WAP | Application withdrawn, taken to be withdrawn or refused ** after publication under section 16(1) | ||
| 732E | Amendments to the register in respect of changes of name or changes affecting rights (sect. 32/1977) |
Free format text: REGISTERED BETWEEN 20240711 AND 20240717 |