Patent Application
20240135012
The present application describes a method for recovering a user's device. Such a device may be a mobile device e.g. a mobile phone or tablet but is not limited thereto.
Mobile devices are usually assigned to a specific user. On such mobile devices, specific information, such as online banking keys and/or other signature keys and/or authentication credentials may be stored. However, if a device is lost, it is often time consuming to re-setup the device so that it works with the respective originally stored credentials.
In the prior art techniques known so far, often, there is the prior need to call the bank where the user has his account, or it is required to send additional physical letters to provide the user with new initiation codes.
Generally, such Apps stored on the devices are from organizations with heterogeneous end users and there is no centralized device management. Examples for such a situation are Consumer Authentication, Banks, Brokerages, Exchanges, or the like.
As further variant where the respective devices or Apps can be implemented, there are also organizations with homogenous end users and a centralized device management. Such organizations in jurisdictions have privacy regulations deterring adoption of biometric authentication. Examples are Workforce Authentication, Enterprises, Firms, or the like.
However, in either one of these organizations, it's always a problem to easily recover a respective device or set up a new device for a specific user. All solutions which are known until now have certain drawbacks. Some or all of these drawbacks are solved by the methods and systems provided in the present invention.
On the one hand, the invention provides a method (an example is described in the following as method 1) and system for an environment wherein there is no centralized device management (e.g. for Consumer Authentication, Banks, Brokerages, Exchanges). On the other hand, the invention provides a method (an example is described in the following as method 2) for an environment wherein there is a centralized device management (e.g. such as Workforce Authentication, Enterprises, Firms).
Method 1:
Covering a first aspect (which is defined in claim 1), a device recovery method is provided herewith. The method comprises the following steps.
A recovery code is acquired with the device to be recovered (step a) in claim 1). Such a recovery code might be sent to the Device to be recovered via SMS, MMS, may be downloaded from a remote server, or may also be received via a physical letter. However, said examples are not limiting the invention. The recovery code may also be scanned directly from a display of a PC.
After the recovery code is acquired, there is a matching verification (step b) in claim 1) between an inherence factor of the user recovering the device, and an inherence factor of the user, which is assigned, to the device.
The terminology “inherence factor” is commonly used in the technical field of authentication methods. Generally, the three most common categories for authentication are described as “something you know” or the knowledge factor, “something you have” or the possession factor and “something you are” or the inherence factor. That means an inherence factor is a factor about an information concerning something you are.
The recovery of the device is allowed (step c) in claim 1) if the inherence factor of the user recovering the device and the inherence factor of the user who is assigned to the device sufficiently match.
Generally, the matching is checked by connecting the device to be recovered, for example via mobile network (GPRS, 5G, LTE or the like) or WLAN to an authentication server, which may be implemented in a higher level system. If the inherence factor of the user, which recovers the device, matches with an inherence factor of the user to which the device is assigned, the recovering is allowed.
As an alternative to connect the device to an authentication server, the authentication information may also be stored on the device to be recovered. For example, when setting up the device the first time and assigning it to a user, there may be an instruction from the App stored on the device to acquire an inherence factor of the user, which shall be assigned to the device. The inherence factor may be stored on the device. This factor may be used in the matching when the device is recovered.
With such a configuration, easy recovery of a system, wherein there is no centralized device management, can be provided.
To develop this solution even further, a preferred option is to include in the above method a step to declare the lost device, where the loss of the device to be recovered is reported to a higher level system. This means that, if a device is lost, this may be reported by a user of the device (or another person such as a helpdesk administrator) to a higher level system. Such a report may also be automatically sent from the device; if e.g. a software on the device assumes that the device is lost, (e.g. several times the wrong pin code is used to unlock the device). The higher level system may then generate a recovery code, which is later used in the step of acquiring the recovery code with the device to be recovered. The higher level system may be a system operated by an organization with which the user has a relation as a customer, e.g. may be an Organization, which requires Consumer Authentication, e.g. a Bank, a Broker, an Exchange.
Thus, it is beneficial to have a configuration provided where the respective user of the device may notify, for example, the provider of the App, or the respective manager of the device, that the device is lost.
The recovery code generated by the higher level system may be a scannable code such as a bar code, a QR code or the like and can be later scanned with the device when, for example, it is found and should be recovered. The recovery code is not necessarily a scannable code; it can also be an identification number or any other code. However, a scannable code, in particular a QR code or barcode, is preferable.
After the respective code is scanned with the device to be recovered, there can be, for example, a connection established between the device to be recovered and an authentication server, on which inherence factor of the user of the device is stored. Now, a matching verification is executed between the inherence factor of the user recovering the device and the inherence factor of the user who is assigned to the device. If this inherence factor matches or sufficiently matches (that means is above a preset threshold), the recovery of the device is allowed.
The inherence factor may comprise a factor for face recognition. That means, the user who wishes to recover the devices makes a photo of himself or switches on the camera of the device, and the respective photo or a video sequence will be transferred to the authentication server and the matching is executed.
This one inherence factor (e.g. face recognition) may be the only inherence factor, but it may also be required for recovery to use a combination of further inherence factors or a different multi-factor authentication. For instance, it is beneficial that additionally to the face recognition, a further inherence factor, such as live detection, is used. For example, when additionally to the face recognition, the live detection is executed as second inherence factor, the verification process may be executed two times, once for each factor. In case live detection is not available, alternative methods such as eyes gazing can be used.
Optionally the user may also use additional ‘something you know’ variable such as a physical signature to further enhance the security process.
Different inherence factors can be used either additionally or alternatively. For example, additionally to the first inherence factor, a second, or a third inherence factor (for example a knowledge factor, or a possession factor), can be used to execute additional matchings to allow the recovery of the device. Therefore, there may be provided at least a multi-factor authorization and that means, there is additionally to matching the inherence factor or factors, a further factor matched to allow the recovery of the system.
The inventive method may be executed via an App stored on the device. The App may be opened on the device and with the App, the respective recovery code may be scanned. Thereafter, there are provided on the App e.g. instructions to acquire an inherence factor (e.g. to take a photo) and then, the inherence factor is matched. This provision of the App provides an increased facilitation of the recovery handling. This functionality in the App may be only a part of the App. The App itself may also provide different functionalities, as banking functionality or provide a secure connection to a remote server or the like.
For enrollment of the App, it may be the case that the App is downloaded first, and then both, the device on which the App is running and the user are registered on an authentication server, this can be done along with the acquisition of an inherence factor of the user who is assigned to the device.
The acquired inherence factor of the user who is assigned to the device in the registration process of the device may be stored in the authentication server and then later used in the step of matching the inherence factor of the user recovering the device with the inherence factor who is assigned to the device.
In particular, it may be the case that after the App is downloaded and one opens the App, there is requested to input an inherence factor, for example, it may be taken a photo of the user, for example also 3D photo and this is then sent to the authentication server.
Further to the aforementioned method, it is also provided in accordance with the present invention an App that can be stored on the device. The App may constrain the instructions for carrying out the aforementioned inventive method.
As well, it is also provided a system comprising the device and an authentication server, with which the device can communicate and the App stored on the device. In the App stored on the device, the respective method, which was described in the preceding statements is to be executed.
Method 2:
Covering a second aspect of the invention, another device recovery method is provided herewith. The method comprises the steps of connecting the device to be recovered to a Cloud storage in which a backup of the device is stored, and requesting a knowledge factor from a user recovering the device. The recovery of the device is allowed when the knowledge factor is correctly input to the device to be recovered.
This variant has a strong benefit if there is a centralized device management provided. Such organizations in jurisdictions have privacy regulations deterring adoption of biometric authentication. Examples are Workforce Authentication, Enterprises, Firms, or the like.
Namely, the steps of this method may be one or more of the following:
The user's respective device is commonly backed up on a Cloud server, for example of the company.
If the respective device is lost or a new device is registered, there is established a connection to the Cloud server (step i) in claim 12).
If the knowledge factor provided by the user during that connection (step ii) in claim 12) matches the knowledge factor which was given beforehand by the user to which the device is assigned, then a recovery is made (step iii) in claim 12) (meaning that integration in the system is allowed).
Generally, the three most common categories for authentication are described as “something you know” or the knowledge factor, “something you have” (ie: Pin code) or the possession factor, and “something you are” or the inherence factor. The possession factor represents something specific in their possession in order to log in such as a batch or a token or a key or SIM card.
It is for example controlled whether the correct knowledge factor is used by comparing the knowledge factor, which is input in the device with a knowledge factor stored in the backup of the device on the Cloud storage.
The knowledge factor may be a Pin code.
According to a further development, when the device is for the first time registered to be backed up in the Cloud storage, the user sets the specific knowledge factor, which identifies him to be assigned to the device. In particular, the data of the device that is backed up in the Cloud may include all the data of the Apps excluding the private signature keys which for security reasons never leave the App, (i.e., if there are banking Apps or other Apps which use a sensitive (private) credential data or (private) signature keys of the user of the device, the backup may consist in backing up of an intermediate key (called session or backup key)). However, when later registering the device to the Cloud, or when a recovery of the device is to be executed, then it is necessary to input the knowledge factor which will allow to retrieve the intermediate key required and then access a centralized resource (ie: the server) for the recovery of private keys.
Further to the aforementioned method (method 2), an application is also provided, which contains instructions carrying out one or more or all of the aforementioned method steps.
Furthermore, there is a system provided comprising a device in the Cloud storage, wherein the device has an App with which the inventive method can be carried out.
In the following, the aspects of the invention are described with respect to the Figure, in which shows
Although in the following, there are given two specific examples (examples for the above described method 1 and 2 respectively), the respective two specific examples are not delimiting the present invention. The present invention then should be understood in the broadest sense and is defined by the claims.
Although as a specific function for an inherence factor, the face recognition is used in the first embodiment and although for a specific example of the knowledge factor, a Pin code is used in the second embodiment, these features are not delimiting the invention.
On the same device, there can also be provided for respective recovery the both methods which are described in the foregoing. There may be used one single App for carrying out said methods, or two different Apps.
In
In the specific embodiment shown in
Namely in
In step 1 (the number 1 in
That means, after the App is started, when the user starts to enroll his device (e.g. by scanning a QR code or other methods provided by the App) (step 1), the App ask the user to take a photo or a video sequence with the camera of the device (step 2). This facial capture is an example for acquiring the inherence factor of the user, which shall be assigned to the device. Said inherence factor is communicated to the authentication server and saved thereon (also in step 2).
The facial recognition is one example of a so-called inherence factor. The inherence factor of the user assigned to the device can also be stored on the device itself, e.g. in the App as the authentication server allows the App to do so (also in step 2 which covers the storage of the factor).
Although a face recognition is shown in
After assigning the device to the user (e.g. the device which is given the number 370215, currently corresponding to device “A”) it is ready for use for the specific user (step 3) (the number 3 in
In
Thereafter, after the device loss is reported, for example to a higher level system, a so-called recovery code is generated. In this specific case, the recovery code is a QR code, however, any other code may be used, also a number digit code may be provided. This code can be for example sent via email to an email address of the user. This code may also just visible on a Display of a PC.
Now, in order to recover the device data (on the same device A if it is found again, or on a new device, e.g. device B as it is shown in
The recovery of the device A on device B (or also on the device A if it is found again) is allowed, if the inherence factor of the user recovering the device and the inherence factor of the user who is assigned to the device sufficiently matches (e.g. The user's face matches the user's facial data stored on the server) (step 5) (the number 5 in
Generally, the matching is checked by connecting the device to be recovered, for example via mobile network (GPRS, 5G, LTE or the like) or WLAN to an authentication server, which may be implemented in a higher level system. If the inherence factor of the user, which recovers the device, matches with an inherence factor of the user to which the device is assigned, the recovering is allowed.
As an alternative to connecting the device to an authentication server, the authentication information as it is shown in
With such a configuration, easy recovering of a system, wherein there is no centralized device management can be provided.
In the present case, additional to the facial recognition, there is an extra inherence factor necessary. Said inherence factor is a so called live detection (LD). For example, when additionally to the face recognition the live detection is executed as second inherence factor, matching process is executed twice. The data for the matching may be stored on the device e.g. in the App or in the authentication server. In case live detection is not available, alternative methods such as eyes gazing can be used.
Optionally the user may also use additional ‘something you know’ variable such as a physical signature to further enhance the security process.
Additionally (or alternatively), these different inherence factors can be used in combination with the initial inherence factor. For example, to allow full device recovery, a knowledge factor or a possession factor verification can be used subsequently to the initial inherence factor matching operation. Therefore, the solution provides multi-factor authorizations, as in addition to matching the inherence factor or factors, a further factor can be matched to allow the recovery of the system.
It has been shown in the first example that via an App, respective mobile device can be recovered and again used after it is for example lost and blocked by the information that the system is lost. The user setting and/or credentials in the App can also be recovered on a different device (e.g. device B) if the original device A is not found. In order to do so, the App may be installed on the device B and the matching of the inherence factors and subsequent recovery, now of device B is executed.
Thus, the device to be recovered may be a different one from the device, which is lost. In this case the recovered device has in view of the lost device after the recovering the same functions, which namely are recovered. This may include only one specific function of the App or all functions of the device.
The system shown in
In
In
Namely, in the present Example, the App does not back up the user's private credential data or private signature keys themselves as they are sensitive data, it is backup an intermediate key form the device which is the aforementioned ‘session’ or ‘backup key’, that key, once it is recovered, will allow the private keys to be restored on the device.
When the user wants to recover his/her device the backup key is used to authenticate to the Authentication Server and is used to initiate the renewal of his transaction signing keys on the recovered device. The benefit of that approach is that the non repudiation property is preserved as the signing keys never left the device in the first place.
In the case of HID approve this is very problematic because the keychain contains signature keys. If the signature keys are leaked or stolen after being backed up in the cloud the non-repudiation property of transaction signing is lost. Indeed the user can claim he may not have sign a given transactions as the keys were leaked or stolen.
If the device A is lost as e.g. shown in
If this is done for the first time, as for example the device A is lost, or a new device B is assigned, the respective Pin code is asked by the App (step 3). If the Pin code is the correct Pin code, which was set by the user during the enrollment, the respective device (e.g. Device B) is registered and can be connected to the backup to restore the data from Device A (In the present case the intermediary key is restored which allows the recovery of the private credential data or private signature keys) (step 3).
The Pin code is an example of a knowledge factor. However, as already outlined above also different other authentication factors or combinations thereof may be used.
This functionality provides a further variant of registering or recovering a device.
The respective HID App in the specific description is an example of such App. This App may include further to the recovery and initialization features, features concerning secure connection, for example to mobile banking or any transaction. Thus, there may be contained in the App security key or other credentials.
| Number | Date | Country | Kind |
|---|---|---|---|
| 22203176.7 | Oct 2022 | EA | regional |
