Authentication system with reduced attack surface

Abstract

Some embodiments relate to an authentication system (100; 101; 102) for calculating an authentication token of a service provider to authenticate a user system to the service provider, the authentication system comprising a processor configured to blind an encrypted user identity in conjunction with the user system and to calculate an encrypted identity for the service provider based on the blinded encrypted user identity.

Description

Technical Field

[0001] The present invention relates to an authentication system, a user system, an assistant server, an authentication server, a service provider, a first user device, a second user device, an authentication method, a user method, an authentication method of an authentication server, an authentication method of an assistant server, a user method of a first user device, and a user method of a second user device. Background Art

[0002] The Dutch government has published guidance on the security requirements for authentication services for each eIDAS security level [2]. In the European Regulation "Electronic Identification and Trust Services" (eIDAS [1]), the security of digital identities is defined. One of its foundations is the "privacy by design" principle, which minimizes privacy-sensitive tracking information. Polymorphic pseudonyms (abbreviated as PP, [3]) are used as cryptographic primitives to identify individuals.

[0003] The guide claims that there are no privacy hotspots in its scheme because the data on the server is simply encrypted. However, these encryptions are essentially identifiable access tokens that attackers can steal and abuse without having to target a specific individual. This makes the authentication server a single point of security vulnerability for such attackers.

[0004] The guideline proposes a solution by storing the pseudonym on some external smart card given to the corresponding identity owner. To some extent, this can mitigate the above attack on the stored PP. However, the attacker can simply wait for the PP from the authentication server to arrive.

[0005] Furthermore, when a user needs to authenticate to an authentication server, in addition to sending his PP, the user also needs to indicate who he wants to authenticate to. This results in information being analyzed on the server. In other words, the authentication server is also a risk factor from a privacy perspective.

[0006] The following references are incorporated herein by reference:

[0007] [1]EU commission.:REGULATION(EU)No 910 / 2014OF THE EUROPEAN PARLIAMENTAND OF THE COUNCIL of 23July 2014on electronic identification and trustservices for electronic transactions in the internal market and repealingDirective 1999 / 93 / EC

[0008] [2]rijksoverheid.nl.:Uniforme set van eisen 1.0.https: / / www.rijksoverheid.nl / documenten / rapporten / 2016 / 12 / 15 / uniforme-set-van-eisen,2016[3]Eric Verheul.:Privacy protection in electronic education based on polymorphic pseudonymization,Cryptology ePrint Archive:Report 2015 / 1228

[0009] [4] A. Fiat and A. Shamir. How to prove yourself: Practical solutions to identification and signature problems. In Advances in Cryptology–CRYPTO'86, volume 263 of LNCS, pages 186–194, New York, 1987. Springer.

[0010] [5]LAM Schoenmakers.:Lecture Notes Cryptographic Protocols Version1.32,http: / / www.win.tue.nl / ~berry / CryptographicProtocols / LectureNotes.pdf Summary of the invention

[0011] Known authentication methods and servers have several disadvantages. For example, it is relatively easy for an attacker to obtain encrypted user identities, since they are present on every user device. Stolen encrypted user identities can in turn lead to identity theft. Even if one takes into account that encryption in a probabilistic scheme such as ElGamal can take many forms (one form for each value r used in the encryption), there is still the risk that one of these forms is stolen by an attacker, who can impersonate the corresponding user. Possessing only one of many possible encrypted identities is sufficient to impersonate a user, since they can all decrypt to the user's identity.

[0012] In known systems, whether or not smart cards are used, the authentication server will at some point possess the cryptographic identity in order to be able to transform it for the corresponding service provider. Therefore, the adversary must compromise the authentication server to collect the PP. He can then impersonate the corresponding user, since he controls the authentication system. In fact, compromising the authentication server provides the possibility to collect many cryptographic identities. In other words, authentication is a single point of compromise.

[0013] Another problem with the known system is that the user's activities can be analyzed by tracking the user's encrypted identity. Although [2] claims to protect a scheme without "privacy hotspots", if their authentication server is responsible for verifying the authentication data of a specific user indexed by at least its authentication data (e.g., a pair of PIN, OTP key, ...) and forwarding the corresponding EP to the service provider, then the authentication server can distinguish individuals and track which service providers a specific user visits. In other words, the authentication server in [2] does not immediately know the identity of the user and his or her behavior, but it can still collect analytical information and learn a lot of information about the identity of each user. The OTP key can be a one-time password algorithm (HOTP) based on HMAC, such as a one-time password (OTP) algorithm based on HMAC, for example, as used in the Open Authentication Initiative (OATH).

[0014] An authentication system is proposed that solves these and other problems. Embodiments are proposed in which the universal encrypted identity never needs to be in memory; neither in the user system nor in the authentication system. Embodiments are also proposed in which the analyzed information is greatly reduced. In particular, there may still be some information servers that can still track, for example, the fact that some users visit a certain website, but do not know which website, or even whether it is the same or a different website; while another server may know which servers are visited, but have no information associated with the users. Thus, the analysis possibilities are reduced to tracking which servers (e.g. websites) are popular, or which users (e.g. indexed by some identifying information, but not their actual identity) frequently visit a service. This is a clear improvement over known systems, in which such information can be easily combined.

[0015] The present invention can be implemented in an authentication system, a user system, and a service provider. The first two can be implemented as a single device, or a combination of multiple cooperating devices, or as two different devices that only share a predetermined part of the authentication protocol. Aspects of the present invention include: an authentication system, a user system, a service provider, an authentication server, an assistant server, a first user device, a second user device, and a method of operating and / or registering any of these systems and devices.

[0016] Various devices may be electronic devices. Specifically, some or all of the devices in the user system may be mobile electronic devices, such as mobile phones, tablet computers, and the like. For example, the authentication system and the user system may be implemented by one or more devices or subsystems. The assistant server, the authentication server, the service provider, the first user device, and the second user device may be implemented as devices, such as computers, servers, and the like; they may also be implemented as multiple collaborative devices. The authentication method, the user method, the authentication method for the authentication server, the authentication method for the assistant server, the user method for the first user device, and the user method for the second user device may be implemented as electronically implemented methods, such as computer-implemented methods, and the like.

[0017] The methods described in this article can be applied to a wide range of practical applications. Such practical applications include providing access to services, such as government services and non-government services. These services can be provided by official identities (e.g., social security numbers, etc.) or pseudonyms.

[0018] Embodiments of the method may be implemented on a computer as a computer-implemented method, or in dedicated hardware, or in a combination of both. Executable code for embodiments of the method may be stored on a computer program product. Examples of computer program products include memory devices, optical storage devices, integrated circuits, servers, online software, etc. Preferably, the computer program product includes non-transitory program code stored on a computer-readable medium for performing embodiments of the method when the program product is executed on a computer.

[0019] In an embodiment, the computer program comprises computer program code adapted to perform all or part of the steps of an embodiment of the method when the computer program is run on a computer.Preferably, the computer program is embodied on a computer readable medium.

[0020] Another aspect of the invention provides a method of making a computer program available for download. This aspect is used when the computer program is uploaded to, for example, Apple's App Store, Google's Play Store or Microsoft's Windows Store, and when the computer program is available for download from such stores. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Further details, aspects and embodiments of the invention will be described by way of example only with reference to the accompanying drawings. The elements in the drawings are shown for simplicity and clarity and are not necessarily drawn to scale. In the drawings, elements corresponding to elements already described may have the same reference numerals. In the drawings,

[0022] Figures 1a-1gSchematically illustrates examples of embodiments of an authentication system, a user system, and a service provider;

[0023] Figure 1h schematically illustrates examples of embodiments of an authentication system, a user system, a service provider, and a host system;

[0024] Figure 2 schematically illustrates examples of embodiments of an authentication system, a user system, a service provider, and a host system;

[0025] Figure 3 schematically illustrates examples of embodiments of an authentication system, a user system, a service provider, and a host system;

[0026] Figure 4 schematically illustrates examples of embodiments of an authentication system, a user system, a service provider, and a host system;

[0027] Figure 5 schematically illustrates an example of an embodiment of an authentication method,

[0028] Figure 6a schematically illustrates a computer-readable medium having a writable portion including a computer program according to an embodiment;

[0029] Figure 6b A representation of a processor system according to an embodiment is schematically shown.

[0030] List of reference numerals, in Figure 1a-4 、6a-6b:

[0031] 13 Memory

[0032] 14 Processor

[0033] 15 Communication Interface

[0034] 100, 101, 102 authentication system

[0035] 103 Service and Authentication System

[0036] 110 First share of encrypted user identity

[0037] 120 Joint Blinding Unit

[0038] 130 Encrypted Identity Unit

[0039] 150 Communication interface

[0040] 170 Authentication Server

[0041] 180 Assistant Server

[0042] 192 Computer Networks

[0043] 200, 201, 202 User systems

[0044] 210 Second share of encrypted user identity

[0045] 220 Joint Blinding Unit

[0046] 250 Communication interface

[0047] 270 First User Device

[0048] 280 Second User Equipment

[0049] 300 Service Providers

[0050] 310 Challenge

[0051] 400 Main System

[0052] 1000 Computer readable medium

[0053] 1010 Writable part

[0054] 1020 Computer Programs

[0055] 1100 devices

[0056] 1110 System Bus

[0057] 1120 processor

[0058] 1130 Memory

[0059] 1140 User Interface

[0060] 1150 Communication Interface

[0061] 1160 Storage Devices

[0062] 1161 Operating System

[0063] 1162, 1163 instructions DETAILED DESCRIPTION

[0064] While the invention may be embodied in many different forms, one or more specific embodiments are shown in the drawings and will be described in detail herein, it being understood that this disclosure is to be considered as an exemplification of the principles of the invention and is not intended to limit the invention to the specific embodiments shown and described.

[0065] In the following, in order to facilitate understanding, the elements of the embodiments are described in operation. However, it is obvious that the various elements are arranged to perform the functions described as being performed by them.

[0066] Furthermore, the invention is not limited to these embodiments, and the invention lies in each and every novel feature or combination of features described herein or recited in mutually different dependent claims.

[0067] In an embodiment, a user system is provided with a cryptographic identity. This cryptographic identity is generic in that it is not specific to any particular service provider. Service providers do not accept generic cryptographic identities. A first cryptographic share of the cryptographic identity is stored in the user system, while a second cryptographic share of the cryptographic identity is stored in the authentication system. The authentication system and the user system can together derive a new cryptographic identity that is specific to a particular service provider. The calculated specific cryptographic identity will be accepted by the particular service provider for which it was created, but it may not be accepted by others. Typically, the user system and the authentication system are provided with a generic cryptographic identity, for example, during a registration operation, even before knowing which service providers they will need. In fact, which service provider may not exist when registering the user system.

[0068] The specific encrypted identity may be included in an authentication token, which may allow the user system or a device of the user system to access the service provider's services. For example, the token may include further authentication data, such as a signature. For example, the authentication token may be provided to the service provider. Upon receiving the authentication token, the service provider may obtain the encrypted user identity from the authentication token.

[0069] We assume that each user in the system has a unique identity, such as a unique number, such as a serial number or social security number. Some trusted organizations can access a person's social security number, while other organizations can only access a pseudonym. The pseudonym may be different for different parties (e.g., different organizations or websites, etc.), but it is constant for a specific service provider.

[0070] Figures 1a-1g Examples of embodiments of an authentication system, a user system and a service provider are schematically shown.

[0071] Figure 1a An example of embodiment of an authentication system 100 is schematically shown. Figure 1b An example of embodiment of a user system 200 is schematically shown. Figure 1c An example of embodiment of a service provider 300 is schematically shown.

[0072] The user system 200 can be used by the user to access the services of the service provider 300. For example, the service provider 300 can provide digital services, for example, via a computer network. For example, the service provider 300 can include a network server, for example, to display a website to the user of the system 200. The user system 200 can use the authentication system 100 to authenticate himself to the service provider 300. For example, the user system 200 can calculate an authentication token together with the authentication system 100 accepted by the service provider 300. The authentication token enables the service provider 300 to obtain the identity or pseudonym of the user. The authentication token can also include traditional authentication methods. For example, in an embodiment, the authentication token includes a signature of the authentication system 100 so that the service provider 300 can verify that the token is generated by the authentication system 100. The latter implies that the user is accepted by the authentication server.

[0073] Any of the systems 100 and 200 may be embodied using multiple devices or a single device. For example, in an embodiment, the authentication system may include an authentication server 170 and an assistant server 180. For example, the assistant server 180 may be configured to blind the encrypted identity, and the authentication system 170 may be configured to generate a blinded encrypted identity specific to a particular service provider. For example, in an embodiment, the user system may include a first user device 270 and a second user device 280. For example, the first user device 270 may be configured to perform actual authentication of the service provider 300, such as to open a session with the authentication system, and the second user device 280 may be configured to jointly calculate the blinded encrypted identity, such as with the assistant server 180. In general, the embodiments shown herein in which the authentication or user system is implemented in a single device may be applicable to embodiments in which it is implemented as split onto two or more devices, and vice versa.

[0074] Therefore, there are four combinations: The authentication system can be split into two devices, but the user system is not split (not shown separately). The authentication system is not split, but the user system is split ( Figure 3 ). The authentication system is not split, and the user system is not split ( Figure 2 ). The authentication system is split, and the user system is also split ( Figure 4 ). In a split-authentication system, it is more difficult to collect analytical information. In a split-user system, it is more difficult for an attacker to obtain the cryptographic identifier, for example, because the unblinded challenge and the blinded cryptographic identifier do not need to exist on the same device or in the same software, even temporarily.

[0075] Figures 1a-1g The various devices shown in can communicate with each other via computer network 192. For example, Figure 1hThe authentication system 100, user system 200 and service provider 300 are shown connected to a computer network 192, together forming a service and authentication system 103. If the authentication system 100 is split into multiple devices, these may use a computer network to communicate between them, possibly the same computer network.

[0076] The computer network may be the Internet, an intranet, a LAN, a WLAN, etc. The computer network 192 may be the Internet. The computer network may be wired in whole or in part, and / or wireless in whole or in part. For example, the computer network may include an Ethernet connection. For example, the computer network may include a wireless connection, such as Wi-Fi, ZigBee, etc. The device includes a connection interface that is arranged to communicate with other devices and systems as needed. For example, the connection interface may include a connector, such as a wired connector, such as an Ethernet connector, an optical connector, etc., or a wireless connector, such as an antenna, such as a Wi-Fi, 4G or 5G antenna. For example, Figures 1a-1g The device shown in may include a communication interface 15. The computer network 192 may include additional elements, such as routers, hubs, etc. The communication interface 15 may be used to receive digital communications, such as in the form of one or more messages, such as sent and received in electronic form.

[0077] Figures 1a-1g The execution of the illustrated apparatus is implemented in a processor circuit, examples of which are illustrated herein. The figures herein illustrate functional units that may be functional units of a processor circuit. For example, Figure 2-4 Can be used as a blueprint for the possible functional organization of a processor circuit. The processor circuit is not related to Figure 2-4 For example, the functional units shown may be stored in whole or in part on a device (e.g., Figures 1a-1g The functional units are implemented by computer instructions located in an electronic memory 13 (one of the devices of the present invention) and are executable by a microprocessor 14. In a hybrid embodiment, the functional units are implemented partly in hardware, for example as a coprocessor, such as a cryptographic coprocessor, and partly in software stored and executed on the processor 14. The communications established by the communication interface can be integrity and / or confidentiality protected using cryptography (e.g., using https, SSL, TLS).

[0078] Figure 2 Schematically illustrates an example of an embodiment of an authentication system 100, a user system 200, a service provider 300, and a main system 400. As described above, splitting the authentication system and / or the user system brings various advantages. Figure 2 These systems are described at the system level. For the authentication system 100 and the user system 200, unsplit or integrated embodiments are also possible.

[0079] The authentication system 100 includes a storage device storing a first share 110 of an encrypted user identity U. In the detailed embodiment disclosed below, the first share may be represented as The first share may be a component, such as a first or random component of an ElGamal encryption, such as g r While the use of an asymmetric homomorphic cryptographic encryption scheme is effective, this is not a requirement and the shares of the encrypted identity can be based on any multi-purpose MPC algorithm, such as the SPDZ protocol.

[0080] The user system 200 includes a storage device storing a second share 210 of the encrypted user identity. In the detailed embodiment disclosed below, the second share can be represented as The second share may be a component, such as a second or data-dependent component of the ElGamal encryption, such as h r U.

[0081] Encrypted identities, e.g. is a generic cryptographic identity. It is not specific to any particular service provider, such as service provider 300.

[0082] In case there is only one share (either the first share 110 or the second share 210), one cannot use the encrypted identity.The authentication system and the user system will need to cooperate to exploit the encrypted identity, for example, to derive a blinded encrypted identity therefrom.

[0083] The user's identity U may be encrypted with a master public key, such as h, corresponding to a master private key such as x. The encrypted share of the identity may be provided by some trusted party, such as a government agency. For example, the identity may be a social security number, etc. The identity may be a phone number or a SIM number, and may be provided, for example, by a trusted party such as a telecommunications provider. The identity may be provided by a trusted party in encrypted form, or in the form of a share of an encrypted identity. Figure 2 A host system 400 is shown. The host system 400 can register an authentication system, a service provider and / or a user system. In particular, the host system can select a public master key and a private master key.

[0084] For example, in an embodiment, the host system may select a public master key and a private master key. The host system may use it to encrypt or have encrypted the identity of each user system. A share of the encrypted identity is then sent to the user system and another share is sent to the authentication system.

[0085] While computing a cryptographic identity at a trusted party (eg, a key master) is a convenient way to register, there are several alternatives.

[0086] For example, as a first alternative, the identity U can be chosen by the user himself. In this case, two shares can be calculated by the user, he keeps one and sends the other to the authentication system. After sending the share, it is preferably deleted from the user system.

[0087] As a second alternative, the user system 200 and the authentication system 100 may participate in a multi-party computation to jointly compute an encrypted identity. For example, the authentication system and the user system may be arranged to jointly encrypt a user identity U for a common master key h, so that each obtains a share of the encrypted user identity. The multi-party computation may obtain the user identity U from the user system 200 as a private input, so that the authentication system 100 does not need to learn the identity U.

[0088] However, in many envisioned actual systems, such joint computation is not required, and the shares of the encrypted identity will be obtained from the trusted party. One or both of the shares may be associated with a unique number that is also associated with the user system. For example, the unique number may be an application ID (e.g., AppId) that distinguishes the user system 200 from other user systems. The application ID may be a number, such as a serial number, a random number, etc., that may be selected by the user system 200 or a trusted party, etc. The unique number may be used primarily for accounting purposes and may not be suitable for logging into a service provider.

[0089] Both the authentication system and the user system include communication interfaces to communicate with each other and with other parties (e.g., service providers) as needed. For example, the communication can be through a computer network, such as the Internet. In general, the communication within and between the systems 100, 200, and 300 can be cryptographically protected for integrity and / or confidentiality using conventional means (e.g., https, SAML protocol, SLL, TLS, etc.).

[0090] When a user system needs to log in or register for a service provider's service, for example, via a computer network, such as logging into a website, the service provider 300 selects a challenge 310, also denoted as e. The challenge may be selected randomly. The challenge is sent to the user system 200 in a deblinded form and to the authentication system 100 in a blinded form. The blinded form is useful because the blinded challenge can be used to verify computations based on the challenge. In addition, the blinded challenge can be used to bind other parties to the correct value of the challenge 310. The blinded challenge can therefore prevent session hijacking or replay attacks.

[0091] Note that the blinded and unblinded challenges may be protected using conventional cryptographic means, e.g., encrypted with the public key of the user system 200 and / or signed with the private key of the service provider 300. The blinded challenge may be performed using the challenge in the exponent of the master public key, e.g., for some function f, as h e orf(e) .

[0092] The blinded challenge may be received from a service provider (e.g., from a website) in the form of a redirect. Receiving the challenge from the service provider may be accomplished by receiving the challenge directly from the website in electronic communication or by optical communication. For example, the service provider may display the challenge in the form of a barcode (e.g., a linear barcode) or a two-dimensional barcode (e.g., a QR code). The optical code may be read by a device of the user system 200, such as a smartphone equipped with a camera.

[0093] Once the authentication system has the blinded challenge, and the user system has the unblinded challenge, they can participate in the protocol to obtain a blinded encrypted identity. The blinded encrypted identity is not used directly for authentication, but is an intermediate result. Because it is blinded by the challenge, which is unknown to the authentication system 100, it is safe to allow the authentication system to perform calculations on it.

[0094] The user system 200 and the authentication system 100 jointly blind the encrypted user identity for the challenge e. For example, the authentication system may include a joint blinding unit 120 that accesses the first share, and the user system may include a joint blinding unit 220 that accesses the second share. The joint blinding units 120 and 220 are configured to collaborate and jointly calculate the blinded encrypted identity.

[0095] Joint blinding can be so-called multi-party computations, where each party may have private inputs. After the computation is over, the parties should not know more than they could from their own inputs that they started with and the results they legally obtained. Preferably, the multiple parties should also be able to verify that the other party performed its actions correctly. If enough parties are compromised, then these goals may not be fully achieved.

[0096] The authentication system 100 will obtain a blinded encrypted identity as a result of the calculation. Preferably, he should be able to verify, for example using his blinded challenge, that the blinded encrypted identity was calculated correctly. The authentication system preferably cannot derive the complete encrypted identity from, for example, his first share, the blinded challenge and the blinded encrypted identity.

[0097] For user system 200, this is also desirable, but it is less important if the user system can derive his own cryptographic identity. It is his own identity, so it is in his interest to protect it well. Furthermore, he is not a target for many identities to be available, because the authentication system is, for example, a single point of breach. In this case, the cryptographic identity may be blinded by exponentiation of the cryptographic identity with the challenge e. The blinded cryptographic identity may be referred to as a BPP u . It can be calculated as (PP u ) e .

[0098] In an embodiment, the authentication system may receive a blinded challenge from a service provider via a user system. For example, the blinded challenge may be forwarded by the user system to the authentication system. This avoids the need to establish direct communication between the authentication system and the service provider, and thereby eliminates potential points of attack. For example, the blinded challenge may be forwarded to the authentication system in the form of a redirect. For example, the user system may include a browser, and the authentication system and the service provider may include a web server. The blinded challenge may be forwarded by redirecting from a service provider website to an authentication system website. The completed specific encrypted identity may be returned from the authentication system to the service provider in the same manner.

[0099] In an embodiment, the user system may also calculate the blinded challenge itself. For example, the user system may receive the unblinded challenge e and use it to calculate the blinded challenge and forward it to the authentication system. The user system cannot simply choose its own challenge because the service provider does not accept the generated identity. However, in an embodiment, this may be used so that the user system's device can prove to the authentication system that it knows the unblinded challenge. This may be used advantageously to split the user system.

[0100] Instead of providing the user system 200 with a deblinded challenge e, in a variant, both the user system 200 and the authentication system 100 are provided with a share of the challenge by the service provider. In this way, the deblinded challenge does not need to leave the service provider. This reduces the risk that an attacker may obtain the challenge e and the blinded encrypted identity, and he can calculate the encrypted identity itself based on the challenge e and the blinded encrypted identity. In a variant, the share in the challenge and the share in the encrypted identity are used as private inputs to jointly calculate the blinded encrypted identity. This can be done using ElGamal. However, if ElGamal is not used, other multi-party computations can be used. For example, the challenge can be a bit string generated by the provided service and used as a one-time secret, such as by XOR; each of the authentication system and the user system can receive a share in the one-time secret. The blinded encrypted identity can then be calculated using a general MPC protocol. The benefit of this is that, for example, an attacker who knows the challenge through the user and observes the BPP or BEP cannot find the PP or EP. For example, multi-party computation can be used to calculate the BPP without obtaining the PP only from the knowledge of a challenge share. Specifically, one can use the following protocol:

[0101] The server (shares e_s and PPb) sends A=PPb^e_s to the client,

[0102] The client (share e_c and PPa) calculates B = A^e_c and C = PPa^e_c, and

[0103] C is sent back to the server. Finally, the server calculates: BPP = B, C^e_s

[0104] An attacker on the server cannot obtain PPa without knowing e_c, and an attacker on the client cannot obtain PPb without knowing e_s. Elsewhere, an attacker cannot derive PP from BPP without knowing e_s and e_c.

[0105] The result of the joint blinding may be that the authentication system 100 has access to a blinded encrypted identity. He can use the blinded encrypted identity for various purposes, as described in further detail below. In addition, the blinded encrypted identity is bound to the challenge e, so that even if an attacker obtains it, it will be useless because in the next session, the service provider will choose a different e.

[0106] For example, in an embodiment, the authentication system 100 can calculate an encrypted identity based on a blinded encrypted identity dedicated to the service provider. To this end, the authentication system may include an encrypted identity unit 130. Specifically, the specific encrypted identity can be decrypted using the service provider's private key and challenge e, so that the service provider obtains the valid identity of the user. In an embodiment, the specific encrypted identity is integrity protected, for example, by signing it with the public key of the authentication system. If this is done, the specific encrypted identity not only provides identity, but also authentication. For example, the specific identity is timely because it is bound to the session challenge, and the signature proves that it was made by the authentication system 100. This in turn means that it was made with a user system that has access to an appropriate share of the general encrypted identity.

[0107] Note that in an embodiment, it may be permitted that the service provider cannot authenticate a specific encryption as the actual identity U.

[0108] There are at least two types of encrypted identities that can be calculated from the blinded encrypted identity. The service provider can decrypt both using its private key and the challenge. That is, both types are encrypted identities that are specific to the service provider 300. The first type of encrypted identity can be decrypted by the service provider to obtain the actual identity of the user U. The second type of encrypted identity can be decrypted by the service provider to obtain the pseudonym of the user. Although the pseudonym is different from the identity U itself, it is the same if two authentications are performed. In other words, the pseudonym can be perfectly used as a username, etc. However, the pseudonyms of different service providers are different. The identity U of the user and one of its pseudonyms can be related by a one-way function. For example, the one-way function can take the identity U and the identity of the service provider as input. Further inputs are possible, such as a local key seed, which can be random but fixed. Calculating the encrypted identity for the service provider can also rely on the public key of the service provider, or cryptographic system data that allows decryption by the private key of the service provider. This can be obtained using the homomorphic properties of the underlying encryption scheme. For example, the authentication scheme may add the encryption of the service provider while retaining the masking. For additional security, the blinded encrypted identity can even be encrypted with the public key of the authentication system, which can be done, for example, during a federated computation, for example, to prevent a compromised encrypted identity from providing any benefit to an unknowing challenge attacker. While the authentication system 100 adds the service provider's encryption, it can remove its own encryption. However, this is not required, especially when using basic security such as TLS.

[0109] For example, in an embodiment, computing the encrypted identity may include encrypting at least a component of the blinded encrypted user identity, the encryption being arranged for decrypting the encrypted identity using the private key of the service provider. This may be sufficient for the encrypted identity to decrypt to the actual identity. For example, the second component may be equal to the second component of the blinded encrypted identity. In this case, the encrypted identity specific to the service provider need not be a pseudonym. For example, the encrypted identity is modified from being encrypted by the master public key to being encrypted by the service provider public key; the blinded form is maintained.

[0110] To obtain the encrypted identity for the service provider decrypted into a pseudonym, the authentication system may also be blinded with a value derived from the service provider identity (N). For example, the value may be obtained using a key derivation function, a hash function, etc. The derivation may depend on a local key seed.

[0111] In an embodiment, the authentication system may store a conversion key seed, and the service provider has been provided with a private key calculated from the conversion key seed and the service provider identity. Using the conversion key seed, the authentication system can correctly encrypt so that the service provider can decrypt. The service provider private key can be derived from the conversion key seed and the master private key. The authentication system has access to the conversion key seed and the master public key and is configured to convert data encrypted for the master private key to data encrypted for the service provider private key.

[0112] The encrypted user identity specific to the service provider can now be sent to the service provider. This can be done directly, or can be done by the user system, such as by redirection. The user system can use the encrypted user identity to authenticate to the service provider having the encrypted identity. For example, additional authentication measures can be added, such as a signature of the authentication system and / or a signature of the user system.

[0113] Figure 3 An example of an embodiment of the authentication system 101, the user system 201, the service provider 300 and the host system 400 is schematically shown. Figure 2 The described embodiment is except that the user system 202 is split into two parts, for example, embodied by a first user device 270 and a second user device 280 .

[0114] The first user device 270 comprises a communication interface arranged to communicate with a service provider and an authentication system, the first user device being arranged to receive a blinded challenge (h e ) to forward the blinded challenge to the authentication system and receive a specific encrypted identity.

[0115] The first user device 270 may act as a conduit between the authentication system 100 and the service provider 300. For example, in an embodiment, the user device 270 may be a web browser with which the user can use the service of the service provider, and therefore he wants to log in with it. In an embodiment, the first user device 270 does not have access to the de-blinded challenge e, nor can it share the encrypted identity.

[0116] The second user device 280 comprises a communication interface arranged to communicate with the service provider and the authentication system, the second user device being arranged to receive the de-blinded challenge e and jointly calculate the blinded encrypted identity. For example, the second user device 280 may comprise the joint blinding unit 220 .

[0117] For example, the unblinded challenge may be obtained in a digital communication. This may be a wired or wireless message over a computer network, but may also be an optical message. The optical message may be displayed on a screen of a first device, for example caused by a service provider, and may then be captured by a camera of a second device. After decoding the image, the unblinded challenge is available on the second device.

[0118] The second device includes a second share storing the encrypted user identity of memory.

[0119] In an embodiment, the second device 280 is engaged with the authentication system to jointly calculate a blinded encrypted identity. The authentication system can then use the blinded encrypted identity to calculate a specific encrypted identity of the desired type. The specific encrypted identity can be forwarded to the service provider via the first user device so that the first user device can log in to the service provider. Interestingly, the second user device 280 can prove to the authentication system that the second user device 280 corresponds to the first user device by calculating a blinded challenge and sending it to the authentication system 100. The authentication system can verify that it is the same as the blinded challenge received from the first user device 270.

[0120] A split user system may also be used when the challenge is communicated in shares. For example, the first user device 270 may receive a first share of the challenge from the service provider 300 and forward it to the authentication system. The second user device 280 may receive a second share of the challenge. Using the two shares, a blinded encrypted identity may be jointly computed without any authentication system and user system learning the challenge, e.g., using encrypted multi-party computation. One may supplement this with some other mechanism to prove the relationship between the first and second user devices, e.g., a challenge response protocol based on a challenge from the service provider or the authentication system. Alternatively, the second user device may receive a blinded challenge h from the service provider. e , for example, optically. The second user device can forward this value while also jointly calculating the blinded encrypted identity based on its share. In this way, the relationship between the first and second user devices can also be proved; a blinded challenge h received from the service provider, for example via the first user device, can be used e To verify the jointly computed blinded encrypted identity.

[0121] In an embodiment, the second user device 280 is configured to jointly compute the blinded encrypted identity. The first user device 270 is configured to authenticate to a service provider with a specific encrypted identity. This split has multiple advantages. For example, the second user device 280 can be used with multiple user devices 270; for example, the second user device 280 can be a smart phone running appropriate software (e.g., an app). In addition, a better separation between the challenge of de-blinding and the blinded encrypted identity is obtained.

[0122] Both the first user device and the second user device may implement user authentication and / or access the system to prevent unauthorized access, such as entering a PIN code, biometrics, password, etc.

[0123] The first and second user devices are preferably different software units, and more preferably different devices. The second user device can be a user phone, such as an app running on a user's portable device. The first user device can be a desktop computer. The same second device can be used with many first devices, such as a computer. The first device can also be a mobile device. However, the first and second user devices can be embedded in the same device. For example, in an embodiment, the first and second user devices can both be implemented as applications on the same smart phone. In that case, preferably, the first and second user devices have an independent connection to a service provider and / or an authentication server so that one user device can receive information that another user device cannot access, such as a blinded or de-blinded challenge, a blinded encrypted identity, and a specific encrypted identity.

[0124] Figure 4 An example of an embodiment of the authentication system 102, the user system 202, the service provider 300 and the host system 400 is schematically shown. Figure 4 In the example, the authentication system and the user device are separated. Note that one can modify this embodiment, or Figure 2 and Figure 3 An embodiment of the invention is such that only the authentication system is split, not the user system.

[0125] The authentication system 102 includes an assistant server 180 and an authentication server 170. The responsibility for jointly calculating the blinded encrypted identity falls on the assistant server 180 and the second user device 280. For example, the assistant server may store a first share of the universal encrypted user identity U. In addition, the assistant server 180 may include a communication interface, which is arranged to receive a blinded challenge. The blinded challenge may come from a service provider, possibly through another device, such as the authentication server 170 and / or the first user device 270. The assistant server is configured to jointly blind with the user system (particularly the second user device 280), and the encrypted user identity obtains a blinded encrypted user identity. For example, the assistant server 180 may include a joint blinding unit 120. The blinded encrypted user identity can be sent from the assistant server to the authentication server. The authentication server can then calculate the desired specific encrypted identity for the desired type of service provider. For example, the authentication server 170 may include an encrypted identity unit 130.

[0126] Interestingly, the assistant server may learn some identity of the user, or at least some proxy, such as an application ID. However, the assistant server does not need to know the identity of the service provider. In fact, the assistant server does not need to have any direct contact with the service provider at all. Although the blinded challenge may come from the service provider, for example, through the first user device and the authentication server, once the assistant server learns the blinded challenge, it does not need to include the identity of the service provider.

[0127] The authentication server may receive the blinded encrypted identity and use it to derive a specific encrypted identity for the service provider.

[0128] For example, as referenced Figure 2-4 The described service provider may include a storage device and a communication interface. The storage device may store a private key that may be used to decrypt the encrypted identity to obtain the identity U or pseudonym. The storage device may also be used to temporarily store challenges. The communication interface may be configured to communicate with at least a user system, such as at least a user device 270. For example, in an embodiment, the service provider may include a network server served by the communication interface.

[0129] The service provider may be configured to generate a challenge e and calculate a blinded challenge corresponding to the challenge. This may be done, for example, upon receiving a login request. The challenge may be encoded in an optically readable image so that it may be optically read by a user system, such as by a second device 280. The blinded challenge may be sent to a user system, such as to a first user device 270, and from there to an authentication system. For example, the blinded challenge may be sent from a service provider to a first user device to an authentication server to an assistant server.

[0130] Finally, the service provider receives the encrypted identity, which it can decrypt with the private key and deblind with the challenge (e). In addition, the service provider can verify other authentication tokens, such as signatures by the helper server and / or the authentication server. For example, the helper server can sign the blinded challenge. For example, the authentication can sign a specific encrypted identity.

[0131] In various embodiments of the authentication system, user system, service provider, authentication server, assistant server, first user device, and second user device, the communication interface can be selected from various alternatives. For example, the interface can be a network interface to a local area network or a wide area network (such as the Internet). If the two devices are in the same system, they can communicate through an application program interface (API), etc.

[0132] The authentication system, the user system, the service provider, the authentication server, the assistant server, the first user device, and the second user device may have a user interface, which may include well-known elements, such as one or more buttons, a keyboard, a display, a touch screen, etc. The user interface may be arranged to accommodate user interactions for performing login actions, reading challenges, entering PIN codes, etc.

[0133] The storage device in the device may be implemented as an electronic memory, such as a flash memory, or a magnetic memory, such as a hard disk, etc., or an optical memory, such as a DVD. The storage device may include a plurality of discrete memories that together constitute the storage device.

[0134] Typically, the authentication system, user system, service provider, authentication server, assistant server, first user device and second user device all include a microprocessor that executes appropriate software stored in the system and / or device; for example, the software may have been downloaded and / or stored in a corresponding memory, for example, a volatile memory such as RAM or a non-volatile memory such as flash memory. Alternatively, the system or device may be implemented in whole or in part in programmable logic, for example as a field programmable gate array (FPGA). The system or device may be implemented in whole or in part as a so-called application-specific integrated circuit (ASIC), such as an integrated circuit (IC) customized for their specific purpose. For example, the circuit may be implemented in CMOS, for example using a hardware description language such as Verilog, VHDL, etc.

[0135] Embodiments may include one or more electronic circuits to implement the corresponding means described herein. The electronic circuits may include processor circuits and memory circuits, the processor circuits executing instructions electronically represented in the memory circuits.

[0136] The processor circuit may be implemented in a distributed manner, for example, as multiple sub-processor circuits. The storage device may be distributed across multiple distributed sub-storage devices. Some or all of the memory may be electronic memory, magnetic memory, etc. For example, the storage device may have volatile and non-volatile portions. A portion of the storage device may be read-only. For example, the device may have one or more processors or microprocessors to execute software stored in the device. The circuit may also be an FPGA, an ASIC, etc.

[0137] Some of the examples in this article use the ElGamal encryption scheme. ElGamal is convenient because it has homomorphic properties. ElGamal provides an efficient way to re-encrypt a ciphertext into a new ciphertext that encrypts the same data. The semantic security of ElGamal means that no observer can determine whether two ciphertexts are encryptions of the same identity. However, the examples can be modified appropriately for another encryption scheme. Instead of ElGamal, other asymmetric homomorphic encryption schemes can be used, in particular other probabilistic encryption schemes. Another example of a homomorphic encryption scheme is, for example, Paillier. However, even non-homomorphic encryption schemes can be used. For example, a ciphertext can be modified by sharing a private key between multiple parties and using multi-party computation to modify the ciphertext without any party knowing the decryption or the private key.

[0138] For example, the encryption may be based on a probabilistic encryption scheme, for example, the scheme may be ElGamal. If the encryption is probabilistic, there are many different ciphertexts that encrypt the same identity.

[0139] A specific embodiment is disclosed below based on the ElGamal encryption scheme. This example uses a key management authority (KMA), such as a main server 400, an authentication system, one or more service providers, and a user system. The user system intends to authenticate to a service provider, but does not know which service providers the user can use at registration.

[0140] In this example, the underlying encryption uses a cyclic group G of order prime p generated by g. The KMA selects a master private key and a master public key. Let h = g x ∈G is the primary public key, and is the corresponding master private key of the ElGamal cryptographic system. Let μ: {0, 1} * →G is a function that maps digital identities to elements in G in a reversible manner. KMA also selects the transformation key seed (D K ).

[0141] During the registration phase, the conversion key seed (D K ) is distributed to one or more authentication systems. In addition, KMA calculates a private key or decryption key x for each service provider N N For example, one can choose in is a key derivation function, such as a hash function. Note that the corresponding public key of N is equal to

[0142] For each user, a polymorphic pseudonym is calculated. The polymorphic pseudonym of a user U = μ(u) is the ElGamal encryption of U, i.e.,

[0143]

[0144] For some randomly selected A polymorphic pseudonym is an encrypted user identity; in this case, an ElGamal encryption of the user identity U.

[0145] Interestingly, PP is split between the user system and the authentication system. In this way, PP is not stored on the user system or the authentication system. Therefore, if an attacker breaks into either the user system or the authentication system, he will not be able to find PP. For example, PP u It can be shared between the authentication server (authentication system) and the user (U) as follows. The authentication system stores the first share User storage as second share Currently, the authentication system only has the random part of PP, so no information about U or PP can be inferred. u On the other hand, users only have h r U∈G. Value contains no information about U, since for any U′ there exists r′ such that Therefore, no information about the fully encrypted user identity can be derived from the first share alone or from the second share alone.

[0146] Storage splits the PP between the authentication system and the user system in several ways. For example, in an embodiment, a trusted party (e.g., a KMA) can calculate the PP and send shares, such as components, to each of the authentication system and the user system. This does not need to be done by the KMA since only the public master key h is required. For example, in an embodiment, the registration device encrypts the social security number using the public master key h and sends the shares to the authentication system and the user system. In an embodiment, the user can calculate the PP. For example, the user can choose an identity for themselves, such as a full name, etc., and calculate the PP based on it. Afterwards, the user can keep a share and can send a share to the authentication system. Multi-party computation can also be used to calculate the split PP, for example, between the authentication system and the user system.

[0147] After registration, during the use phase, the user system may need to authenticate with the service provider. In the following protocol, the service provider can generate a challenge e and send it to the user system. Usually, the challenge will be randomly generated. The service provider sends a blinded challenge h to the authentication system. e :=g e The user system and the authentication system will blind the encrypted user identity of challenge e to obtain

[0148]

[0149] For example, this can be done using multi-party computation. In multi-party computation, the user system has access to one share of PP and the challenge e, while the authentication server (AS) has access to another share of PP and the blinded challenge. As a result, at least the authentication server obtains the blinded encrypted user identity BPP u . The user system can gain access to the blinded encrypted identity, but this is neither required nor desirable. Preferably, none of the parties to the multi-party computation is informed of the full PP, in particular the authentication system. Furthermore, the authentication system does not learn the unblinded challenge e. Preferably, the protocol also proves to the authentication system that the user system has access to the unblinded challenge e. The latter can be done via a zero-knowledge proof of knowledge, e.g. as part of MPC. The zero-knowledge proof can be done using the so-called Fiat-Shamir heuristic [4], based on the hash function

[0150] Jointly computing the blinded encrypted identity may be done according to known multi-party computation protocols.

[0151] However, the optimized protocol is as follows:

[0152] The user obtains a random challenge from the service provider: The service provider generates and sends a random And generate and send h to the authentication system e =g e .

[0153] Joint blinding of PP. The user system establishes a connection with the authentication system.

[0154] (a) Randomization Authentication system selects random and will Sent to user U. (Note: the user will not be able to reconstruct without knowing c )

[0155] (b) Convert to e:U and calculate A=C e and

[0156] (c) Session ownership proof: U chooses random And calculate a=C r , b=g r , And ρ = r + ze mod p.

[0157] (d) Reply to the authentication system: U sends A, B, a, b, ρ to the authentication system

[0158] (e) Verification Proof: Authentication System Calculation And verify whether

[0159] (C) ρ = =aA z and

[0160]

[0161] The authentication system now knows that the user system has access to challenge e, so that h e =g e And A is equal to C e .

[0162] (f) Complete blind reconstruction: Authentication system settings

[0163] During the agreement, no party saw the full PP u In addition, BPP u It can only be used in sessions indexed by challenge e, so it is useless to an attacker because the range of e is very large in the discrete log setting.

[0164] Once the authentication system has access to the blinded encrypted identity BPP u , the authentication system can then calculate one of two values.

[0165] The blinded encrypted identity BEI of user U is U under the ElGamal key of a service provider. e ElGamal encryption. So the form of user U's EI with respect to service provider N for some random number r is:

[0166]

[0167] It can be given by BPP u The authentication system is calculated as follows:

[0168]

[0169] The service provider can decrypt it with his private decryption key and use d=e -1 mod p to unblind and obtain U.

[0170] The encrypted pseudonym EP of user U is the ElGamal encryption of f(U, K, N) under the ElGamal key of some service provider N. One can choose f(U, K, N) to be

[0171] therefore,

[0172]

[0173] This can be calculated by the authentication system from the BPP as follows:

[0174]

[0175] Correctness results from the homomorphic properties of ElGamal. Note that BEP U，N can be decrypted and unblinded by N, because the service provider knows e, so he can calculate d = e -1 modp. Service providers can use BEP U，N Get Value The latter is a pseudonym of U, which is specific to the service provider N. Each time the user U authenticates to the service provider N, the service provider will obtain the same pseudonym. However, the service provider will not be aware of the corresponding value U. Even if two service providers cooperate, they will find it difficult to check their information about the user U, because they do not know which user pseudonym on one server corresponds to the pseudonym on the other server.

[0176] Therefore, the service provider provides the user with a random challenge to encrypt his PP, resulting in what we call a BPP. This encryption ensures that the BPP is not available in any other context. The protocol does not require that the parties see the full PP, but at most the BPP.

[0177] If the authentication server is implemented as a single device, the authentication server can still obtain analytical information, that is, the server can learn some form of ID connected to the user and the ID of the service provider that the user is contacting. In an embodiment, this is avoided by performing the reconstruction of the BPP on a separate server-helper server, which forwards the reconstructed BPP to the authentication server, which can convert the result and send it to the service provider. Therefore, the separate server will only know that "a specific user wants to use his PP", while the authentication server will only know that "someone wants to contact a certain service provider".

[0178] In an embodiment, the authentication system is assured that the user system has used the correct challenge corresponding to a valid session. In this way, attackers who attempt to forge a BPP encrypted with a key of their own choice will be thwarted. This part can apply zero-knowledge proof. In addition, the evidence can also be enhanced to prove the authenticity of the user's identity. The latter avoids having to do the proof again.

[0179] These PPs are removed as targets by splitting the PPs between the two parties and blinding the joint. The indexed user wishes to connect to service provider N, but the authentication system is still aware of this. In an embodiment, this is accomplished by splitting the BBP u Calculation and use of BBP u To calculate BEP U，N or BEI U，N to two different servers (helper server and authentication server) to avoid.

[0180] No shares are stored on the authentication server (AS), so that the AS can only see the BBP that cannot be connected to a specific user interaction u The user system can perform the reconstruction of the BPP with the help of a helper server (HS), which forwards the reconstructed BPP to the authentication server. The helper server then learns only the “ The user "wants to use his PP, while the authentication server only learns "someone wants to authenticate to the service provider (N)".

[0181] The following protocols can be used:

[0182] The user system gets a random challenge from the service provider. The service provider generates and sends a random And generate and send h to AS e =g e The user system connects to the assistant server. The authentication server will e Forwarded to the assistant server. The blinded challenge h e Can also be sent directly to the helper server.

[0183] Joint blinding of PP

[0184] (a) Randomization HS selects random and will Sent to user U. (Note: the user will not be able to reconstruct without knowing c )

[0185] (b) Convert to e:U and calculate A=C e and

[0186] (c) Session ownership proof: U chooses random And calculate a=C r , b=g r , And ρ = r + ze mod p.

[0187] (d) Reply to HS: U sends A, B, a, b, ρ to HS

[0188] (e) Verification: HS calculation And verify whether

[0189] (C) ρ = =aA z and

[0190]

[0191] Now HS knows that U knows e, so that h e =g e And A is equal to C e .

[0192] (f) Complete blind reconstruction: HS settings

[0193] Send result to AS: HS sends BPP to AS u Optionally, BPP u may be additionally blinded to ensure that even if e is leaked in some way, the corresponding PP u Still can't link with AS. Note that the latter optional blinding does not require a separate unblinding step. In a sense, this blinding just changes the random part of the encryption. Decryption will undo all randomization.

[0194] Conversion: Convert the value to BPP u Convert to BEP U，N or BEI U，N and sent to the service provider.

[0195] Decryption: The service provider decrypts using his secret key and deblinds using e.

[0196] The protocol may include authentication via a challenge-response protocol, but this involves additional communication, see Chapters 4 and 5 of [5] for more examples. In an embodiment, authentication is added without additional communication cost.

[0197] Method 1: Proving session ownership may rely on hashing functions We observed It can also be a keyed hash function, such as HMAC. Assume that the z value is calculated as follows

[0198]

[0199] In it, both the server and the user have the secret key and the SessionData (which may be empty, a SessionCounter, a challenge from the server, etc.). Now the "session ownership proof" can only succeed if the user actually has the HMAC key that the server also has, otherwise the z value calculated by the user will not match the one calculated by the server, and the verification on the server side will fail. Furthermore, an eavesdropper can no longer calculate z and check if the transcript is a "verifiable transcript", i.e., a proof that will verify.

[0200] Method 2: Alternatively or additionally, one can use HMAC with a pre-shared key as the PRF to blind the ElGamal encryption BPP as follows. The user computes r′=HMAC(key, g e ||SessionData), and instead compute

[0201] A=g r ′C e and

[0202]

[0203] Other calculations can remain unchanged.

[0204] On the other hand, the server may calculate r′=HMAC(key,h e ||SessionData) and verify (C) ρ = =a(A / g r ′) z .

[0205] Final calculation

[0206]

[0207] Compared to method 1, the described method has the additional advantage that the protocol enforces the act of blinding the BPP in order to obtain a valid BPP (if h remains hidden from HS). Furthermore, the server can distinguish between invalid proofs due to not using the correct key (e.g. by pressing the wrong PIN) or not having a valid session. In fact, if the secret key is wrong, then only r′ is wrong, making it possible to check only

[0208]

[0209] Not in compliance,

[0210] (C) ρ = =a(A / g r ′) zis still correct. But if e is wrong, then z is wrong, and both verifications fail.

[0211] A further embodiment is described below in which the user system is split into a first user device and a second user device: for example, a user browser running on a desktop, and a user application (App) running, for example, on a user smartphone. The authentication system is split into an assistant server and an authentication server. The App can register with the assistant server with an app identification (e.g., app ID). Shares of the encrypted identity can be stored on the assistant server associated with the app ID. Both the assistant server and the app can maintain a session counter.

[0212] 1. The user connects to the service provider via a web browser.

[0213] 2. The user requests a service and wishes to log in.

[0214] 3. The service provider provides the random challenge e to the user application. For example, the service provider may display an optically readable code, such as a QR code, of the random challenge e, such as via a pop-up window. The user browser is redirected to the authentication server, where the authentication server obtains h e =g e as the session ID. Redirection can use standard SAML redirection.

[0215] 4.AS stores h as service provider N e , then h e Forwarded to the assistant server.

[0216] 5. The assistant server will h e Add to the list of open sessions.

[0217] 6. The user opens an application (App), such as "client software" to read the challenge, such as scanning a QR code.

[0218] 7. App uses its app ID, AppID and h=g e Connect to the helper server.

[0219] 8. The assistant server verifies whether there is a value h e = Idle session of h.

[0220] 9. The assistant server obtains the corresponding App ID And h e Link to AppID. Now h e No longer free.

[0221] 10. Assistant server selection is random And reply

[0222] 11. The user enters an access code, such as a PIN.

[0223] 12. The App obtains the seed, e and SessionCounter.

[0224] 13. The App calculates KU = H(seed||PIN) and r′ = HMAC(KU||g e ||sessionCounter).

[0225] 14.App calculates A=g r ′C e and

[0226] 15.App selection is random And calculate a=C r , b=g r , And ρ = r + zemodp.

[0227] 16. App sends AppID, A, B, a, b, ρ to the assistant server

[0228] 17. The assistant server obtains the KU and sessionCounter corresponding to the AppID, and calculates r′=HMAC(KU, sessionCounter).

[0229] 18.Assistant Server Calculation And verify whether

[0230] (C) ρ = =a(A / g r ′) z ,as well as

[0231]

[0232] 19. If only the second check is true, infer "PIN incorrect"; if both are false, infer "Malicious message received". Otherwise, if both are true: continue.

[0233] 20. Assistant Server Settings

[0234] 21. The assistant server sends the BPP to the authentication server u and h e and certification conclusions.

[0235] 22. The assistant server increments the SessionCounter and replies to the App with the conclusion.

[0236] 23. The App increments the SessionCounter and displays the result to the user.

[0237] 24. The authentication server obtains the corresponding h e The ID of the service provider that identifies the session.

[0238] 25. The authentication server requests BSNk to convert BPP u (Plays the role of PI in Figure 1) Converted to BEP U，N (Plays the role of VI in Figure 1).

[0239] 26. Authentication server using BEP U，N Redirects the browser back to the relying party.

[0240] 27. The service provider decrypts the BP using his secret key U，N and rebuild

[0241] 28. The user is authenticated.

[0242] Many elements of this embodiment are optional and / or can be replaced by alternatives. For example, the use of a session counter or PIN code is optional. For example, in step 13, you can choose to use KU, a session counter, or HMAC, etc. The seed in step 13 can be a random string generated by the App, such as at registration, such as when the PIN is entered for the first time. The seed protects a database on the server containing KU values ​​to leak PINs on a large scale through rainbow table attacks.

[0243] Figure 5 An example of embodiment of an authentication method is schematically shown. Figure 5 An overall method 500 is shown including a method 501 for a user system and a method 551 for an authentication system. The present invention extends to parts of a method that can be performed, for example, by an assistant server, an authentication server, a first user device, and a second user device. The present invention further extends to a method that can be performed by a service provider.

[0244] Method 501 includes

[0245] - storing 510 the encrypted second share of the user identity,

[0246] - receiving 520 the blinded challenge and the unblinded challenge generated by the service provider. The blinded challenge may be forwarded to the authentication system, such as Figure 5 As shown by the right-pointing arrow in

[0247] - Jointly blinding 530 the encrypted user identity with the authentication system for the challenge. Jointly blinding by Figure 5 The dotted line indicates that

[0248] - Receive 540 a specific encrypted identity and authenticate to the service provider.

[0249] Method 551 includes

[0250] - storing 550 a first share of the encrypted user identity,

[0251] - receiving 560 a blinded challenge corresponding to a challenge generated by the service provider,

[0252] - Jointly blinding 570 the encrypted user identity with the user system in response to the challenge,

[0253] - Calculate 580 an encrypted identity for the service provider and send the specific encrypted identity to the user system. Figure 5 Indicated by a left-pointing arrow.

[0254] Many different ways of performing these methods are possible, as will be apparent to one skilled in the art. For example, the steps may be performed in the order shown, but the order of the steps may also be changed or some steps may be performed in parallel. In addition, other method steps may be inserted between the steps. The inserted steps may represent improvements to the methods described herein, or may be independent of the methods. For example, some steps may be performed at least partially in parallel. In addition, a given step may not be fully completed before starting the next step.

[0255] Embodiments of the method can be performed using software, which includes instructions for causing a processor system to perform method 500. The software may include only those steps taken by a specific sub-entity of the system. The software may be stored in a suitable storage medium, such as a hard disk, a floppy disk, a memory, an optical disk, etc. The software may be sent as a signal along a wired, wireless or data network (e.g., the Internet). The software may be available for download and / or remote use on a server. An embodiment of the method may be performed using a bitstream arranged to configure a programmable logic (e.g., a field programmable gate array (FPGA)) to perform the method.

[0256] It should be understood that the present invention also extends to computer programs, in particular computer programs on or in a carrier, suitable for putting the present invention into practice. The program may be in the form of source code, object code, code intermediate source code and object code, such as partially compiled form, or any other form suitable for implementing an embodiment of the method. An embodiment relating to a computer program product comprises computer executable instructions corresponding to each processing step of at least one of the methods described. These instructions may be subdivided into subroutines and / or stored in one or more files that may be statically or dynamically linked. Another embodiment relating to a computer program product comprises computer executable instructions corresponding to each unit of at least one of the stated systems and / or products.

[0257] Figure 6a A computer readable medium 1000 having a writable portion 1010 is shown according to an embodiment, the writable portion 1010 including a computer program 1020, the computer program 1020 including instructions for causing a processor system to perform an authentication method; for example, methods 500, 501, 551 or portions thereof. The computer program 1020 may be embodied on the computer readable medium 1000 as a physical mark or by magnetization of the computer readable medium 1000. However, any other suitable embodiments are also contemplated. Furthermore, it should be understood that although the computer readable medium 1000 is shown herein as an optical disk, the computer readable medium 1000 may be any suitable computer readable medium, such as a hard disk, solid state memory, flash memory, etc., and may be non-recordable or recordable. The computer program 1020 includes instructions for causing a processor system to perform the authentication method.

[0258] Figure 6b An exemplary hardware diagram 1100 for implementing a device according to an embodiment is illustrated. For example, the hardware diagram 1100 may be configured to implement one or more of an authentication system, a user system, an authentication server, a first user device, a second user device, or a service provider. As shown, the device 1100 includes a processor 1120, a memory 1130, a user interface 1140, a communication interface 1150, and a storage device 1160 interconnected via one or more system buses 1110. It should be understood that the diagram constitutes an abstraction in some respects, and the actual organization of the components of the device 1100 may be more complex than illustrated.

[0259] The processor 1120 may be any hardware device capable of executing instructions stored in the memory 1130 or the storage device 1160 or otherwise processing data. Thus, the processor may include a microprocessor, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or other similar device. For example, the processor may be an Intel Core i7 processor, an ARM Cortex-R8, etc. In an embodiment, the processor may be an ARM Cortex M0.

[0260] The memory 1130 may include various memories, such as L1, L2 or L3 cache or system memory. Thus, the memory 1130 may include static random access memory (SRAM), dynamic RAM (DRAM), flash memory, read-only memory (ROM), or other similar memory devices. It is apparent that in embodiments where the processor includes one or more ASICs (or other processing devices), these ASICs implement one or more functions described herein in hardware, and software described as corresponding to such functions in other embodiments may be omitted.

[0261] The user interface 1140 may include one or more devices for communicating with a user such as an administrator. For example, the user interface 1140 may include a display, a mouse, and a keyboard for receiving user commands. In some embodiments, the user interface 1140 may include a command line interface or a graphical user interface that may be presented to a remote terminal via the communication interface 1150.

[0262] The communication interface 1150 may include one or more devices for implementing communication with other hardware devices. For example, the communication interface 1150 may include a network interface card (NIC) configured to communicate according to the Ethernet protocol. For example, the communication interface 1150 may include an antenna, a connector, or both. In addition, the communication interface 1150 may implement a TCP / IP stack for communication according to the TCP / IP protocol. Various alternative or additional hardware or configurations for the communication interface 1150 will be apparent.

[0263] The storage device 1160 may include one or more machine-readable storage media, such as a read-only memory (ROM), a random access memory (RAM), a magnetic disk storage medium, an optical storage medium, a flash memory device, or a similar storage medium. In various embodiments, the storage device 1160 may store instructions for execution by the processor 1120 or data that may be operated by the processor 1120. For example, the storage device 1160 may store a basic operating system 1161 for controlling various basic operations of the hardware 1100. For example, the storage device may store instructions 1162 to blind an encrypted user identity jointly with a user system for a challenge, and / or instructions 1163 to calculate an encrypted identity for a service provider, etc.

[0264] Obviously, various information described as being stored in storage device 1160 may be stored in memory 1130 in addition or in lieu thereof. In this regard, memory 1130 may also be considered to constitute a "storage device" and storage device 1160 may be considered to be a "memory". Various other arrangements will be apparent. In addition, both memory 1130 and storage device 1160 may be considered to be "non-transitory machine-readable media". As used herein, the term "non-transitory" will be understood to exclude transient signals but include all forms of storage devices, including volatile and non-volatile memory.

[0265] Although the device 1100 is shown as including one of each of the described components, various components may be replicated in various embodiments. For example, the processor 1120 may include multiple microprocessors that are configured to independently perform the methods described herein or are configured to perform the steps or subroutines of the methods described herein, so that multiple processors cooperate to implement the functions described herein. In addition, in the case where the device 1100 is implemented in a cloud computing system, the various hardware components may belong to separate physical systems. For example, the processor 1120 may include a first processor in a first server and a second processor in a second server.

[0266] It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments.

[0267] In the claims, any reference signs placed between brackets shall not be construed as limiting the claims. The use of the verb "comprise" and its variants does not exclude the presence of elements or steps other than those stated in the claims. The word "one" or "an" preceding an element does not exclude the presence of a plurality of such elements. An expression such as "at least one" preceding a list of elements indicates that all elements or any subset of elements are selected from the list. For example, the expression "at least one of A, B, and C" should be understood to include only A, only B, only C, both A and B, both A and C, both B and C, or all A, B, and C. The present invention can be implemented by hardware comprising several different elements and by a suitably programmed computer. In a device claim that lists several units, several of these units may be embodied by the same hardware item. Although specific measures are recorded in mutually different dependent claims, this does not mean that a combination of these measures cannot be used advantageously.

[0268] In the claims, reference numerals in parentheses refer to reference numerals in the drawings of exemplifying embodiments or formulas of embodiments, thereby increasing the intelligibility of the claims. These references should not be construed as limiting the claims.

Claims

1. An authentication system for calculating an authentication token of a service provider to authenticate a user system to the service provider, the authentication system comprising: Storage devices that store: Encrypting a first share of a user identity, wherein a corresponding user system stores a second share of the encrypted user identity; a communication interface configured to communicate at least with the user system, the communication interface further configured to receive a first share of a challenge corresponding to a challenge generated by the service provider, the user system receiving a second share of the challenge; A processor configured to: Calculate an encrypted identity for the service provider that can be decrypted using the private key of the service provider and the challenge, including: jointly blinding the encrypted user identity for the challenge with the user system, the blinded encrypted user identity is calculated based on multiple private inputs, the authentication system provides the first share of the encrypted user identity and the first share of the challenge as private inputs, the user system provides the second share of the encrypted user identity and the second share of the challenge as private inputs, wherein the blinding performed is a multi-party calculation, and the authentication system obtains the blinded encrypted user identity.

2. The authentication system according to claim 1, comprising an assistant server and an authentication server, The assistant server comprises: Storage devices that store: said first share of said encrypted user identity, a communication interface configured to receive said first share of said challenge, a processor configured to blind the encrypted user identity in conjunction with the user system to obtain a blinded encrypted user identity, The authentication server comprises: a communication interface arranged to receive said blinded encrypted user identity from said helper server, A processor is arranged to calculate said encrypted identity for said service provider.

3. A user system, comprising a first user device and a second user device, wherein: The first user equipment comprises: a communication interface arranged to communicate with a service provider and an authentication system, the first user device being arranged to receive a first share of a challenge, to forward the first share of the challenge to the authentication system, and to receive an encrypted identity for the service provider, The second user equipment comprises: a storage device storing a second share of the encrypted user identity, and A communication interface is arranged to communicate with the service provider and the authentication system, the second user device being arranged to receive a second share of the challenge and to jointly blind the encrypted user identity.

4. An assistant server, comprising: a storage device storing a first share of an encrypted user identity, and a corresponding user system storing a second share of the encrypted user identity; a communication interface configured to communicate with at least the user system, the communication interface further configured to receive a blinded challenge corresponding to a challenge generated by a service provider; A processor configured to: jointly with the user system blinding the encrypted user identity for the challenge, the blinded encrypted user identity being calculated based on a plurality of private inputs, the helper server providing the first share of the encrypted user identity and the blinded challenge as private inputs, the user system providing the second share of the encrypted user identity and the unblinded challenge as private inputs, wherein the blinding performed is a multi-party computation, and the helper server obtains the blinded encrypted user identity, The blinded encrypted user identity is sent to an authentication server.

5. An authentication server, comprising: a communication interface configured to communicate with at least an assistant server and a user system, the communication interface configured to receive a blinded encrypted user identity, the blinded encrypted user identity having been jointly calculated by the assistant server and the user system, A processor configured to compute an encrypted identity for the service provider from the blinded encrypted user identity decryptable using a private key of the service provider and a challenge, and to send the encrypted identity to the user system for authentication with the service provider.

6. A service provider configured to accept an authentication token from a user system according to claim 3 for authentication, the service provider comprising: a storage device storing a private key, a communication interface configured to communicate at least with the user system, A processor configured to: generating a challenge and calculating a first share and a second share of the challenge corresponding to the challenge, sending the challenge and the first share and the second share to the user system, Receive an encrypted identity, The encrypted identity is decrypted using the private key and unblinded using the challenge.

7. A second user device, configured to calculate an authentication token of a service provider to authenticate a user system to the service provider, the second user device comprising: a storage device storing a second share of an encrypted user identity, the first share of the encrypted user identity being stored at the authentication system, a communication interface configured to communicate with at least the service provider and the authentication system, the communication interface configured to receive a second share of the challenge from the service provider, A processor configured to: Jointly with the authentication system, blinding the encrypted user identity for the challenge is performed, wherein the blinded encrypted user identity is calculated based on multiple private inputs, the authentication system provides the first share of the encrypted user identity and the first share of the challenge as private inputs, and the user system provides the second share of the encrypted user identity and the second share of the challenge as private inputs, wherein the blinding performed is a multi-party computation, and the authentication system obtains the blinded encrypted user identity.

8. An authentication method for an authentication system, for calculating an authentication token of a service provider to authenticate a user system to the service provider, the authentication method comprising: storage: Encrypting a first share of a user identity, wherein a corresponding user system stores a second share of the encrypted user identity; establishing communication with at least the user system and receiving a first share of a challenge corresponding to a challenge generated by the service provider, the user system receiving a second share of the challenge; Calculating an encrypted identity for the service provider, comprising: jointly blinding the encrypted user identity for the challenge with the user system, wherein the blinded encrypted user identity is calculated based on multiple private inputs, the authentication system provides the first share of the encrypted user identity and the first share of the challenge as private inputs, and the user system provides the second share of the encrypted user identity and the second share of the challenge as private inputs, wherein the blinding performed is a multi-party calculation, thereby obtaining the blinded encrypted user identity.

9. A second user device method for calculating an authentication token of a service provider to authenticate a user system to the service provider, the second user device method comprising: storing a second share of the encrypted user identity, the first share of the encrypted user identity being stored at the authentication system, establishing communication with at least the service provider and the authentication system, the communication interface being configured to receive a second share of the challenge from the service provider, Jointly with the authentication system, blind the encrypted user identity for the challenge, wherein the blinded encrypted user identity is calculated based on multiple private inputs, the second share of the encrypted user identity and the second share of the challenge are provided as private inputs, and the authentication system provides the first share of the encrypted user identity and the first share of the challenge as private inputs, wherein the blinding performed is a multi-party computation, and the authentication system obtains the blinded encrypted user identity.

10. A transient or non-transitory computer readable medium comprising data representing instructions for causing a processor system to perform the method according to claim 8 and / or 9.

Images