WO2021225571A1

WO2021225571A1 - Device revocation

Info

Publication number: WO2021225571A1
Application number: PCT/US2020/031288
Authority: WO
Inventors: Thalia May LAING; Joshua Serratelli SCHIFFMAN; Gaetan WATTIAU
Original assignee: Hewlett-Packard Development Company, L.P.
Priority date: 2020-05-04
Filing date: 2020-05-04
Publication date: 2021-11-11

Abstract

In an example there is provided a method for a set of devices that are registered to participate in an authentication session. Each registered device stores share data of an authentication token. The method comprises receiving an instruction to revoke a device from the set of registered devices and generating, for each of the other devices in the set of registered devices, further share data of the authentication token on the basis of randomly generated data and the authentication token.

Description

DEVICE REVOCATION BACKGROUND [0001] Authentication systems are ubiquitous in business and commercial environments. Authentication systems use authentication factors to verify a user’s identity. An authentication factor may be something the user knows, something the user possesses, or an attribute of the user. The authentication factor can depend on possession of devices such as phones or laptops. In some cases, multiple devices may participate in the authentication of a user. BRIEF DESCRIPTION OF THE DRAWINGS [0002] Figure 1 is a schematic diagram showing an apparatus for use in an authentication session, according to an example. [0003] Figure 2 is a block diagram showing a method of revoking a device from a set of registered devices, according to an example. [0004] Figure 3 shows a processor associated with a memory comprising instructions for revoking a device according to an example. DETAILED DESCRIPTION [0005] In the following description, for purposes of explanation, numerous specific details of certain examples are set forth. Reference in the specification to "an example" or similar language means that a particular feature, structure, or characteristic described in connection with the example is included in at least that one example, but not necessarily in other examples. [0006] Authentication is used to establish the identity of an entity. Authentication is used in a wide variety of different contexts. For example, an authentication system may be deployed between a user and a system to prevent unauthorised users from gaining access to services or data. Some authentication systems allow users to authenticate themselves to a local device or a server that is remote from the user over a network. [0007] In many authentication systems a user is asked to present an authentication factor during an authentication session. An authentication factor may be ‘something you are’, ‘something you know’, or ‘something you have’. For example, in some systems a user is authenticated by the system if they can demonstrate possession of an identification card. In another case, a system may authenticate the user if they can enter a password when prompted. [0008] Due to the weaknesses of passwords, many authentication schemes rely on the user having access to a device. This is an improvement over a password as the device, unlike a human, can store a cryptographically secure password and can use public key cryptography. [0009] When the user wants to authenticate, an authenticating party, also referred to as the relying party, sends a challenge to the device. The challenge is signed by the device using the private key corresponding to a previously enrolled public key. A valid signature shows the relying party that someone with access to the device wants to authenticate i.e., the user is in possession of the device. The relying party doesn’t learn the private key and so cannot leak information about the key if compromised at a later date. In particular, possession of the authentication factor can be demonstrated without revealing secure information relating to the authentication factor. [0010] In some authentication procedures, an authentication factor is distributed by a trusted dealer across multiple devices. When the user is asked to authenticate themselves, they demonstrate possession of a subset of devices that are registered to participate in the authentication of the user, across which the authentication factor is distributed. If the combined information from the subset of devices is sufficient to demonstrate possession of the authentication factor, then the user is authenticated. [0011] Distributing an authentication factor across multiple devices increases security and usability of a system. In these systems, an adversary has to obtain a number of different devices to imitate the authorised user. If a device is lost, stolen, or damaged, or is locked out to a user, the user can still authenticate by presenting a different subset of devices in their possession when it is time to authenticate. [0012] In circumstances where a user is locked out of a device or a device is lost, stolen or damaged the user may wish to remove the device from the set of registered devices in a way that ensures that the information relating to the authentication factor on the device cannot be exploited by an adversary. One method to achieve this is to re-provision the entire system to revoke the device. This involves updating information such as public key data on remote services and data held on all the remaining devices. This is problematic as devices which are absent or switched off at the time of re-provisioning may fall out of sync and become unusable in future authentication sessions. Moreover, in some scenarios, the original trusted dealer may not be available for re-provisioning. [0013] The methods and systems described herein allow a device to be removed from a set of registered devices that store shares of an authentication token. The methods do not require the re-provisioning of the authentication token. Furthermore, in some cases, the methods described herein do not require the trusted dealer to be present after the initial distribution of the authentication token. The methods improve the usability of distributed authentication by relaxing the infrastructure requirements for managing a set of registered devices, and give flexibility for removing devices when some of the devices are unavailable. [0014] The methods described herein may be implemented using threshold cryptography. Threshold cryptographic techniques enable an authentication token to be split into shares. Each device in a set of n devices possesses a share of the authentication token. A minimum threshold of t out of a total of n shares is needed to use the authentication token. In such a scheme, a trusted dealer creates an authentication token, splits it in to n shares, and distributes the shares to the devices. The methods described herein allow the system to securely revoke a device that has been allocated a share of an authentication token by the trusted dealer, without the authentication token being updated. [0015] In examples, methods of re-distributing the same authentication token amongst the remaining devices with new randomness are described. This re- distribution may be done in a centralised or distributed manner. Moreover a corresponding public key associated to the authentication token is unchanged Furthermore, access to data held on the device that is being revoked is not required. [0016] Figure 1 is a schematic diagram showing an apparatus 100 according to an example. The apparatus 100 shown in Figure 1 may be used in conjunction with the other methods and systems described herein. The apparatus 100 is used for distributing share data in a setup phase that occurs prior to the execution of an authentication session between a user 110 and an authenticating entity. [0017] The apparatus 100 comprises a trusted dealer 120. The trusted dealer 120 is a logical entity, such as a computing device, and is present during the setup phase. The apparatus 100 further comprises a number of devices 130 that are associated to the user 110. The devices 130 may be devices which are held in the user’s possession. In other examples, the devices 130 are devices which are physically distant from the user 110. In some examples, the trusted dealer 120 also belongs to the set of devices 130. In other cases, the trusted dealer 120 is a distinct logical entity from the devices 130. [0018] The trusted dealer 120 is arranged to communicate with each of the devices 130 over secure communication channels during the setup phase of the authentication session. The trusted dealer 120 generates an authentication token and distributes the authentication token as shares to each of the devices 130. According to examples, the trusted dealer 120 may use a threshold cryptographic protocol such as a secret sharing scheme, to generate an authentication token and generate shares of the authentication token to distribute to the devices 130. [0019] According to examples described herein, once the authentication token is distributed as shares to each of the devices 130, authorised subsets of the devices 130 may participate in an authentication session to authenticate the user 110. Herein an “authorised subset” of devices refers to a subset of the devices 130 that belongs to an access structure. An access structure ^ is a set consisting of all subsets of the devices 130 which the user wishes to be authorised to act on behalf of the full set of devices 130. If the user 110 can present an authorised subset of devices i.e. a set in ^, the user 110 is successfully authenticated. According to examples described herein, the access structure ^ may consist of all subsets of the devices 130 which contain t or more devices, where t is a constant threshold number less than the total number of devices. This threshold may be n/2, for example. [0020] In a multi-device based authentication session between the user 110 and an authenticating entity, an authentication session may proceed in the following manner. Firstly, the authenticating entity communicates a challenge which is distributed to each of the devices 130. Each device in an authorised subset of the devices 130 generates a partial signature on the share of the challenge, using their share of the authentication token. The partial signatures are combined to generate a full signature. The full signature is communicated to the authenticating entity which then verifies the signature. Once the signature is verified the user 110 is authenticated. [0021] In examples described herein, the user 110 is able to revoke a device from the set of registered devices 130. According to a first scenario, the trusted dealer 120 is assumed to be present throughout the execution of an authentication session between the user 110 and an authenticating entity. In this case, the user may wish to revoke a device 140, from the subset of devices 130. According to examples, the user 110 informs the trusted dealer 120 that they would like to revoke the device 140. If the trusted dealer 120 receives a request to revoke a device from the set of device 130 they may first seek to verify the authenticity of the request. According to examples, the authenticity of the request may be verified using an out-of-band communication channel between the user 110 and the trusted dealer 120. [0022] In the first example, the trusted dealer 120 is arranged to generate new shares of the authentication token for each of the devices 130, excluding the device 140, following the same method previously used. For example, using a secret sharing scheme such as the Shamir secret sharing scheme the trusted dealer 120 retain the same authentication token as used in the first run of the protocol. This is achieved by generating a new polynomial uniformly at random while keeping the authentication token the same, by setting the constant coefficient to equal the previous authentication token. The new shares are generated in the usual way by setting evaluating the new polynomial at n-1 points for each of the n-1 remaining devices. The trusted dealer 120 communicates the new shares of the authentication token to the remaining devices which store the new shares in place of the previous shares. Once the remaining devices 130 switch to using the new shares, the share held by the device 140 is invalidated for use in an authentication session as the share held by the device 140 does not combine with the new shares of the authentication token to produce a valid signature on an authentication challenge. [0023] One or more of the remaining devices 130, excluding device 140, may be out of contact with the trusted dealer 120 at the time the new shares are generated. As such, some of the devices 130 that are used for authentication may have updated shares, whereas other devices may not have yet received their updated shares. [0024] To address this additional data may be included with the new shares to indicate an epoch number of the share. When an authentication protocol begins, each device broadcasts the most recent epoch number they have. If there is an authorised subset of the devices 130 that are available that all have a matching epoch number, then the authorised subset of devices collaborate to agree to use the shares having the same epoch number to authenticate. The devices that have not yet received a share corresponding to the agreed upon epoch number may use the determined number to request the newer share, where such a share is available. [0025] Alternatively the devices 130 sign the message with their most current share and the share prior to the current share. Each of the devices sends both partial signatures, along with the epoch number corresponding to each partial signature. A share combining entity then waits for partial signatures from an authorised subset in the same epoch to authenticate the user 110. The share combining entity responds to the devices by indicating which epoch number was used. [0026] In a further example, rather than using an epoch number, the new shares are distributed by the trusted dealer 120 with a time stamp indicating a date at a future point in time. Until that date, each of the devices 130 continues using its current share. As of the date defined in the time stamp, the devices 130 switch to using the newly updated share, and delete the old share. Thus, any device which has not received a new share is excluded from the protocol and any device which has received a new share knows that it should use the new share from that point in time. [0027] According to a second scenario, the trusted dealer 120 is assumed to be unavailable after the initial setup phase. In that case, each of the devices 130 has a share of the authentication token, however the trusted dealer 120 is not available to distribute new shares after setup. In this scenario, it is assumed that there is a centralised entity referred to herein as a share update entity (not shown in Figure 1). The share update entity is trusted by the user 110 and the devices 130 to generate and distribute randomly generated data among the devices 130. The share update entity also has a secure channel with each device 130. The share update entity is also assumed to not have access to authentication token. [0028] According to examples, the user indicates to the share update entity that they wish to revoke the device 140 from participating in the set of registered devices 130. The share update entity generates fresh randomness and distributes this randomness to all of the other devices 130, excluding the device 140. Every one of the devices 130 that receive randomness from the share update entity uses the randomness to update their share. According to an example, in one implementation based on a secret sharing scheme, the share update entity may be arranged to generate a sharing of zero and distribute the shares to the devices 130, which add on the shares of zero to the share of the authentication token in their possession. This has no effect on the value of the secret i.e. the authentication token. [0029] As described previously in relation to the first scenario, there are a number of methods for specifying how a device switches from using old shares to new shares. These methods may also be used in the second scenario, where the trusted dealer 120 is assumed to no longer be present after an initial setup phase. [0030] In the further example of the second scenario the trusted dealer 120 may be persistent in the system, but not available to revoke the device 140 even after the initial setup phase. In that case, the share update entity sends the freshly generated randomness to the trusted dealer 120. This ensures that the trusted dealer 120 has randomness that is consistent with the shares that are currently being used by the devices 130. This enables the trusted dealer 120 to generate further new shares which are consistent with current shares for incoming devices. [0031] According to a third scenario, the trusted dealer 120 is assumed to be unavailable after the initial setup and there is no centralised entity trusted to generate and distribute randomly generated data amongst the devices 130. In this scenario all of the devices 130 are assumed to be present. Furthermore, each of the devices 130 is assumed to be able to communicate securely with each of the other devices. [0032] The user 110 instructs one or more of the other devices 130 that they wish to revoke the device 140 from participating in authentication sessions. The remaining devices 130 propagate this message between the other devices. According to examples described herein, one or more of the devices may request confirmation from the user 110 via an out of band communication channel that the user wishes to revoke the device 140. Once all of the devices are in agreement to revoke the device 140, all remaining devices participate in a collaborative share update protocol, to distributively generate random data. Once each of the devices receives random data from the other devices the devices generate updated shares of the authentication token on the basis of the random data. [0033] According to examples, protocols based on proactive secret sharing allow random data to be generated and distributed collaboratively in this manner. According to examples, such a scheme may involve collaboration from all of the remaining devices. As such, they all immediately switch to using the newly updated shares of the authentication token. This has the effect of immediately revoking the device 140 and there is no need for a further protocol to establish which shares the devices are using. [0034] Figure 2 is a block diagram showing a method 200 of revoking a device from a set of devices according to an example. The method 200 shown in Figure 2 may be implemented on the apparatus 100 shown in Figure 1 to revoke the device 140. [0035] In the method 200 shown in Figure 2, it is assumed that there is a set of devices that are registered to participate in the authentication of the user and that the devices have access to a share of an authentication token. In other words, the previously described setup process between the trusted dealer 120 and devices 130 has occurred. [0036] At block 210, an instruction to revoke a device from the set of registered devices is received. According to examples the instruction may be communicated via a device in the possession of the user 110 shown in Figure 1. [0037] At block 220, for each of the other devices in the set of registered devices, further share data of the authentication token is generated on the basis of randomly generated data and the authentication token. In examples described herein generating the further share data of the authentication token comprise generating further shares of the authentication token on the basis of randomly generated data and communicating the further share data to each of the other devices. For example, in the case where the trusted dealer 120 is still present, the trusted dealer 120 generates new shares of the authentication token and distributes the new shares to the devices 130. [0038] In a second example of the method 200, generating further share data of the authentication token comprises communicating a portion of randomly generated data to each of the other devices and generating the further share data on the basis of the share data stored at the respective device and the portion of randomly generated data. This is implemented, for example, using a trusted share update entity as previously described in relation to the second scenario. [0039] According to a third example of the method 200, generating further share data of the authentication token comprises, for each of the other devices, communicating a portion of randomly generated data from each device to each of the other devices and generating further share data at each device on the basis of the portions of randomly generated data that are received from the other devices. As previously indicated in relation to the third scenario, this may be implemented using a proactive secret sharing scheme. [0040] According to examples described herein, the method 200 comprises generating share generation data indicating when the further share data is generated and storing the share generation data with the further share data at the respective device. The share generation data is, in some examples, broadcasted by each device to each of the other remaining devices. The devices may use the share generation data to determine which shares may be used in an authentication session as previously described. [0041] According to an example, the method 200 comprises receiving share generation data from a subset of the devices, determining whether the subset of devices is an authorised subset and participating in an authentication session on the basis of the determination. In some cases, the share generation data comprises a time stamp. Share data may be identified for use in an authentication session on the basis of the time stamp. [0042] According to an example, the method 200 comprises receiving an authentication challenge in an authentication session and generating, for each device in an authorized subset of devices, at least one partial signature of the authentication challenge on the basis of share data stored at the respective device. Authenticating the user 110 depends on the nature of the underlying cryptographic primitive which is implemented. This may involve combining partial signatures to produce a group signature and subsequently verifying the group signature, verifying a multisignature that is received from a combiner device, or verifying individual partial signatures and checking them against an access structure to determine whether a subset is an authorised subset. [0043] The methods and systems described herein increase the security and usability of user authentication in a setting where users have multiple devices. In the event a user loses a device, it is highly likely that they will want to revoke a device. The user does not want to have to log onto every device and system in order to update every public key related to the authentication token. The methods and systems described herein reduce the amount of communication required, and reduce the complexity of performing device revocation. [0044] Examples in the present disclosure can be provided as methods, systems or machine-readable instructions, such as any combination of software, hardware, firmware or the like. Such machine-readable instructions may be included on a computer readable storage medium (including but not limited to disc storage, CD- ROM, optical storage, etc.) having computer readable program codes therein or thereon. [0045] The present disclosure is described with reference to flow charts and/or block diagrams of the method, devices and systems according to examples of the present disclosure. Although the flow diagrams described above show a specific order of execution, the order of execution may differ from that which is depicted. Blocks described in relation to one flow chart may be combined with those of another flow chart. In some examples, some blocks of the flow diagrams may not be necessary and/or additional blocks may be added. It shall be understood that each flow and/or block in the flow charts and/or block diagrams, as well as combinations of the flows and/or diagrams in the flow charts and/or block diagrams can be realized by machine readable instructions. [0046] The machine-readable instructions may, for example, be executed by a general-purpose computer, a special purpose computer, an embedded processor or processors of other programmable data processing devices to realize the functions described in the description and diagrams. In particular, a processor or processing apparatus may execute the machine-readable instructions. Thus, modules of apparatus may be implemented by a processor executing machine-readable instructions stored in a memory, or a processor operating in accordance with instructions embedded in logic circuitry. The term 'processor' is to be interpreted broadly to include a CPU, processing unit, ASIC, logic unit, or programmable gate set etc. The methods and modules may all be performed by a single processor or divided amongst several processors. [0047] Such machine-readable instructions may also be stored in a computer readable storage that can guide the computer or other programmable data processing devices to operate in a specific mode. [0048] For example, the instructions may be provided on a non-transitory computer readable storage medium encoded with instructions, executable by a processor. Figure 3 shows an example of a processor 310 associated with a memory 320. The memory 320 comprises computer readable instructions 330 which are executable by the processor 310. [0049] The instructions 330 are executable by the processor to: receive an instruction to remove a device from a list of registered devices that are registered to participate in an authentication protocol, each device storing a first portion of an authentication token, generate, for each of the other devices in the list of registered devices, a second portion of the authentication token on the basis of randomly generated data and the authentication token and communicate the second portion to the respective device. [0050] Such machine-readable instructions may also be loaded onto a computer or other programmable data processing devices, so that the computer or other programmable data processing devices perform a series of operations to produce computer-implemented processing, thus the instructions executed on the computer or other programmable devices provide an operation for realizing functions specified by flow(s) in the flow charts and/or block(s) in the block diagrams. [0051] Further, the teachings herein may be implemented in the form of a computer software product, the computer software product being stored in a storage medium and comprising a plurality of instructions for making a computer device implement the methods recited in the examples of the present disclosure. [0052] While the method, apparatus and related aspects have been described with reference to certain examples, various modifications, changes, omissions, and substitutions can be made without departing from the present disclosure. In particular, a feature or block from one example may be combined with or substituted by a feature/block of another example. [0053] The word "comprising" does not exclude the presence of elements other than those listed in a claim, "a" or "an" does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. [0054] The features of any dependent claim may be combined with the features of any of the independent claims or other dependent claims.

Claims

CLAIMS 1. A method for a set of devices that are registered to participate in an authentication session, each registered device storing share data of an authentication token, the method comprising: receiving an instruction to revoke a device from the set of registered devices; and generating, for each of the other devices in the set of registered devices, further share data of the authentication token on the basis of randomly generated data and the authentication token.

2. The method of claim 1, wherein generating the further share data of the authentication token comprises: generating the further share data on the basis of a secret sharing scheme; and communicating the further share data to each of the other devices.

3. The method of claim 1, wherein generating further share data of the authentication token comprises: communicating a portion of randomly generated data to each of the other devices; and generating the further share data on the basis of the share data stored at each of the devices and the portion of randomly generated data.

4. The method of claim 1, wherein generating further share data of the authentication token comprises, for each of the other devices: communicating a portion of randomly generated data from each device to each of the other devices; and generating further share data at each device on the basis of the portions of randomly generated data that are received from the other devices.

5. The method of claim 1, comprising generating share generation data indicating when the further share data is generated and storing the share generation data with the further share data at the respective device.

6. The method of claim 5, comprising broadcasting the share generation data to each of the devices.

7. The method of claim 6, comprising receiving share generation data from a subset of the devices; determining whether the subset of devices is an authorised subset; and participating in an authentication session on the basis of the determination.

8. The method of claim 1, comprising: receiving an authentication challenge in an authentication session; and generating, for each device in an authorized subset of devices, at least one partial signature of the authentication challenge on the basis of share data stored at the respective device.

9. The method of claim 6, wherein the share generation data comprises a time stamp.

10. The method of claim 9, comprising identifying share data for use in an authentication session on the basis of the time stamp of the share data.

11. An apparatus, comprising: a share generator arranged to generate shares of an authentication token for each device in a set of registered devices that are registered to participate in an authentication session; and a share distributor arranged to communicate the shares of the authentication token to the set of devices, wherein the share generator is arranged to generate further shares of the authentication token in response to receipt of an instruction to remove a device from the set of registered devices; and wherein the share distributor is arranged to distribute the further shares of the authentication token to the other devices in the set of registered devices.

12. The apparatus of claim 11, wherein, to generate further shares of the authentication token, the share generator module is arranged to share the authentication token on the basis of randomly generated data.

13. A non-transitory machine-readable storage medium encoded with instructions executable by a processor to: receive an instruction to remove a device from a list of registered devices that are registered to participate in an authentication protocol, each device storing a first portion of an authentication token; generate, for each of the other devices in the list of registered devices, a second portion of the authentication token on the basis of randomly generated data and the authentication token; and communicate the second portion to the respective device.

14. The non-transitory machine-readable storage medium 13 comprising instructions executable by a processor to: generate, for each of the other devices in the list of a registered devices, a time stamp indicating when the second portion is generated; and communicate the time stamp to the respective device with the second portion.