WO2020144518A1 - Utilisation de jetons virtuels pour étendre des protocoles d'authentification - Google Patents

Utilisation de jetons virtuels pour étendre des protocoles d'authentification Download PDF

Info

Publication number
WO2020144518A1
WO2020144518A1 PCT/IB2019/061083 IB2019061083W WO2020144518A1 WO 2020144518 A1 WO2020144518 A1 WO 2020144518A1 IB 2019061083 W IB2019061083 W IB 2019061083W WO 2020144518 A1 WO2020144518 A1 WO 2020144518A1
Authority
WO
WIPO (PCT)
Prior art keywords
challenge
response
client
request
protocol
Prior art date
Application number
PCT/IB2019/061083
Other languages
English (en)
Inventor
Yaron KASSNER
Hed KOVETZ
Rotem ZACH
Original Assignee
Silverfort Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Silverfort Ltd. filed Critical Silverfort Ltd.
Publication of WO2020144518A1 publication Critical patent/WO2020144518A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2103—Challenge-response
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2115—Third party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/082—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying multi-factor authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H04L63/0838—Network architectures or network communication protocols for network security for authentication of entities using passwords using one-time-passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication

Definitions

  • the present invention relates to the field of computer security.
  • a relying party is a server providing access to a secure software application.
  • U2F Universal 2nd Factor
  • FIDO Fast Identity Online
  • U2F Universal 2nd Factor
  • the RP generates a challenge, passes the challenge to the client, and looks up a public key.
  • the client transfers the challenge to a U2F device, referred to herein as a“token,” which stores a private key.
  • the token uses the private key, the token generates a response to the challenge by signing the challenge.
  • the token passes the response to the client, and the client then passes the response to the RP.
  • the RP verifies the response with the public key.
  • NTLM NT Local Area Network Manager
  • the processor is further configured to, subsequently to obtaining the NTLM authentication token, receive, via the communication interface, from another processor that belongs to the client device, a challenge that was sent to the client device by the service in response to a request, from the client device, to access the service.
  • the processor is further configured to, using the NTLM authentication token, compute a response to the received challenge, and to communicate the computed response to the client device, without exposing the NTLM authentication token to the client device.
  • an apparatus including a network interface and a processor.
  • the processor is configured to receive, via the network interface, a challenge generated by a relying party (RP) in accordance with a protocol requiring that a key, which is needed to sign the challenge, be provided by a token associated with the processor.
  • the processor is further configured to pass a request to sign the challenge, over a network, to an authenticating server that possesses the key, in response to receiving the challenge.
  • the processor is further configured to receive from the authenticating server, subsequently to passing the request to the authenticating server, a response to the challenge, which was generated by the authenticating server by using the key to sign the challenge.
  • the processor is further configured to cause the response to be passed to the RP, in response to receiving the response.
  • the protocol is a Universal 2nd Factor (U2F) protocol.
  • U2F Universal 2nd Factor
  • the protocol is a Web Authentication (WebAuthn) protocol.
  • WebAuthn Web Authentication
  • the token includes a Universal 2nd Factor (U2F) token.
  • U2F Universal 2nd Factor
  • the token includes a Client to Authenticator Protocol (CTAP) token.
  • CTAP Client to Authenticator Protocol
  • the processor is configured to pass the request to the authenticating server using a software agent that simulates the token.
  • the processor is configured to receive the challenge via a proxy server
  • the processor is further configured to receive together with the challenge, from the proxy server, code that was received by the proxy server from the RP together with the challenge and was modified by the proxy server, and
  • tire processor is configured to pass the request to the authenticating server by executing the modified code.
  • the processor is configured to pass the request to the authenticating server via the proxy server.
  • the authenticating server is the proxy server.
  • a method including receiving, by a client, a challenge generated by a relying party (RP) in accordance with a protocol requiring that a key, which is needed to sign the challenge, be provided by a token associated with the client.
  • the method further includes, in response to receiving the challenge, passing a request to sign the challenge, over a network, to an authenticating server that possesses the key.
  • the method further includes, subsequently to passing the request to the authenticating server, receiving, from the authenticating server, a response to the challenge, which was generated by the authenticating server by using the key to sign the challenge.
  • the method further includes, in response to receiving the response, causing the response to be passed to the RP.
  • a computer software product including a tangible non-transitory computer-readable medium in which program instructions are stored.
  • the instructions when read by a processor, cause the processor to receive a challenge generated by a relying party (RP) in accordance with a protocol requiring that a key, which is needed to sign the challenge, be provided by a token associated with the processor.
  • the instructions further cause the processor to pass a request to sign the challenge, over a network, to an authenticating server that possesses the key, in response to receiving the challenge.
  • RP relying party
  • the instructions further cause the processor to receive from the authenticating server, subsequently to passing the request to the authenticating server, a response to the challenge, which was generated by the authenticating server by using the key to sign the challenge.
  • the instructions further cause the processor to cause tire response to be passed to tire RP, in response to receiving the response.
  • an apparatus including a network interface and a processor.
  • the processor is configured to receive via the network interface, from a relying party (RP), a challenge directed to a client, the challenge having been generated by the RP in accordance with a protocol requiring that a key, which is needed to sign the challenge, be provided by a token associated with the client.
  • the processor is further configured to cause a request to sign the challenge to be passed, over a network, to an authenticating server that possesses the key, in response to receiving the challenge.
  • the processor is further configured to receive a response to the challenge, which was generated by the authenticating server by using the key to sign the challenge, subsequently to causing the request to be passed to the authenticating server.
  • the processor is further configured to cause the response to be passed to the RP, in response to receiving the response.
  • the protocol is a Universal 2nd Factor (U2F) protocol.
  • U2F Universal 2nd Factor
  • the protocol is a Web Authentication (WebAuthn) protocol.
  • the token includes a Universal 2nd Factor (U2F) token.
  • the token includes a Client to Authenticator Protocol (CTAP) token.
  • CTAP Client to Authenticator Protocol
  • the processor is further configured to:
  • the processor being configured to cause the request to be passed to the authenticating server by:
  • the processor belongs to the authenticating server.
  • a method including receiving by a proxy server, from a relying party (RP), a challenge directed to a client, the challenge having been generated by the RP in accordance with a protocol requiring that a key, which is needed to sign the challenge, be provided by a token associated with the client.
  • the method further includes, in response to receiving the challenge, causing a request to sign the challenge to be passed, over a network, to an authenticating server that possesses the key.
  • the method further includes, subsequently to causing the request to be passed to the authenticating server, receiving a response to the challenge, which was generated by tire authenticating server by using the key to sign the challenge.
  • the method further includes, in response to receiving the response, causing the response to be passed to the RP.
  • the authenticating server is the proxy server.
  • a computer software product including a tangible non-transitory computer-readable medium in which program instructions are stored.
  • the instructions when read by a processor, cause the processor to receive, from a relying party (RP), a challenge directed to a client, the challenge having been generated by the RP in accordance with a protocol requiring that a key, which is needed to sign the challenge, be provided by a token associated with the client.
  • the instructions further cause the processor to cause a request to sign the challenge to be passed, over a network, to an authenticating server that possesses the key, in response to receiving the challenge.
  • RP relying party
  • the instructions further cause the processor to receive a response to the challenge, which was generated by tire authenticating server by using the key to sign the challenge, subsequently to causing the request to be passed to the authenticating server.
  • the instructions further cause the processor to cause the response to be passed to the RP, in response to receiving the response.
  • an apparatus including a network interface and a processor.
  • the processor is configured to receive, via the network interface, a request to sign a challenge, the challenge being directed to a client and having been generated by a relying party (RP) in accordance with a protocol requiring that a key, which is needed to sign the challenge, be provided by a token associated with the client.
  • the processor is further configured to request that a user of the client prove possession of at least one authentication factor, in response to receiving the request.
  • the processor is further configured to generate a response to the challenge by using the key to sign the challenge and to cause the response to be passed to the RP, in response to the user proving possession of the authentication factor.
  • the protocol is a Universal 2nd Factor (U2F) protocol.
  • U2F Universal 2nd Factor
  • the protocol is a Web Authentication (WebAuthn) protocol.
  • WebAuthn Web Authentication
  • the token includes a Universal 2nd Factor (U2F) token.
  • U2F Universal 2nd Factor
  • the token includes a Client to Authenticator Protocol (CTAP) token.
  • CTAP Client to Authenticator Protocol
  • the processor is configured to cause the response to be passed to the RP by passing the response to the client such that the client passes the response to the RP.
  • the processor is configured to pass the response to the client via a proxy server.
  • the processor is configured to receive the challenge from the RP by proxying between the client and the RP.
  • a method including receiving a request to sign a challenge, the challenge being directed to a client and having been generated by a relying party (RP) in accordance with a protocol requiring that a key, which is needed to sign the challenge, be provided by a token associated with the client.
  • the method further includes, in response to receiving the request, requesting that a user of the client prove possession of at least one authentication factor.
  • the method further includes, in response to the user proving possession of the authentication factor, generating a response to the challenge by using the key to sign the challenge and causing the response to be passed to the RP.
  • a computer software product including a tangible non-transitory computer-readable medium in which program instructions are stored.
  • the instructions when read by a processor, cause the processor to receive a request to sign a challenge, the challenge being directed to a client and having been generated by a relying party (RP) in accordance with a protocol requiring that a key, which is needed to sign the challenge, be provided by a token associated with the client.
  • the instructions further cause the processor to request that a user of the client prove possession of at least one authentication factor, in response to receiving the request.
  • the instructions further cause the processor to generate a response to the challenge by using the key to sign the challenge and to cause tire response to be passed to the RP, in response to tire user proving possession of the authentication factor.
  • Fig. 1 is a schematic illustration of a system for authenticating to a relying party (RP), in accordance with some embodiments of the present invention
  • FIG. 2 is a schematic illustration of a flow of communication for authenticating to an RP, in accordance with some embodiments of the present invention
  • FIG. 3 is a schematic illustration of a flow of communication for authenticating to an RP using a proxy server, in accordance with some embodiments of the present invention
  • Fig 4 is a schematic illustration of an example algorithm for authenticating to an RP, in accordance with some embodiments of the present invention.
  • Fig. 5 is a schematic illustration of an example algorithm for proxying between a client, an authenticating server, and an RP, in accordance with some embodiments of the present invention.
  • Fig. 6 is a schematic illustration of an example algorithm for facilitating authentication to an RP, in accordance with some embodiments of the present invention.
  • RP relying party
  • U2F Universal 2nd Factor
  • USB Universal Serial Bus
  • an authenticating server configured to store the respective private keys of a large number of users.
  • Each client, or a proxy server on behalf of the client is configured to forward challenges received from the RP to the authenticating server.
  • Each challenge is forwarded along with relevant data that may be used, by the authenticating server, to identify the key required to sign the challenge and the user to whom the key is assigned.
  • the authenticating server may request, from the user, proof of possession of at least one authentication factor such as a password, a biometric factor (e.g., a fingerprint), or a device (e.g., a cellphone, such as a smartphone).
  • the authenticating server may generate a response to the challenge by using the identified key to sign the challenge. Subsequently, the authenticating server may pass the response to the client or to the proxy server, and the response may then be passed to the RP.
  • the authenticating server together with the relevant authentication factors, function as respective virtual tokens for multiple users, thereby extending the applicability of the authentication protocol by obviating the need for the dedicated tokens normally required by the protocol.
  • the techniques described herein typically do not require any changes to the protocol or to the functionality of the RP.
  • FIG. 1 is a schematic illustration of a system 20 for authenticating to a relying party (RP) 44, in accordance with some embodiments of the present invention.
  • Fig. 1 depicts a user 26 using a client device 22, referred to hereinbelow simply as a “client,” to request to authenticate to RP 44 for the purpose of accessing a secure software application.
  • Client 22 may comprise a notebook computer, a desktop computer, a smartphone, or any other computing device. In some cases, client 22 belongs to a local area network (LAN) or a cloud computing environment.
  • Client 22 comprises a network interface, such as a network interface controller 40, and a processor 42.
  • RP 44 in response to the request from the client, RP 44 generates a challenge in accordance with a protocol requiring that a (private) key, which is needed to sign the challenge, be provided by a token associated with the client.
  • a protocol requiring that a (private) key, which is needed to sign the challenge, be provided by a token associated with the client.
  • the protocol requires that a token be associated with the client and that the token provide the key.
  • the protocol may require that the key be stored on a physical token, such as a Universal Serial Bus (USB) token, connected to the client, or that the key be provided by a software token running on the client.
  • USB Universal Serial Bus
  • the RP may generate a challenge in accordance with the U2F protocol or the Web Authentication (WebAuthn) protocol.
  • the protocol may require that the client be associated with a U2F token or a Client to Authenticator Protocol (CTAP) token, such as a CTAP2 token.
  • CTAP Client to Authenticator Protocol
  • the RP communicates the challenge to the client. If a response to the challenge, generated by using the key to sign the challenge, is received by the RP, the RP authenticates the client (i.e., the RP accepts the client’s request to authenticate to the RP), and hence allows the client to access the secure application. Otherwise, the RP denies the client’s request.
  • System 20 comprises an authenticating server (AUTH SERVER) 28, comprising a network interface, such as a NIC 32, a processor 34, and a data storage 35, such as a hard drive or flash drive.
  • AUTH SERVER authenticating server
  • Data storage 35 stores any keys belonging to user 26, typically along with the respective keys of multiple other users.
  • data storage 35 may store any authentication policies for implementing the adaptive authentication techniques described hereinbelow with reference to Fig. 2, including, for example, a list of secure applications each user is allowed to access.
  • Each key is associated in data storage 35 with the user to whom the key is assigned.
  • each key may be associated with the user ID used by the user, the user’s name, the user’s cellphone number and/or another identifier of the user’s cellphone, and/or the user’s email address.
  • each key is further associated with a key handle, which, as further described below with reference to Fig. 2, may be used by authenticating server 28 to look up the key.
  • each key may be associated with the secure application for which the key is required, e.g., by virtue of being associated with an application ID identifying the application and/or an identifier (e.g., an Internet Protocol (IP) address) of the RP providing access to the application.
  • IP Internet Protocol
  • authenticating server 28 is configured to receive a request to sign the challenge, the challenge having been generated by RP 44 and directed to the client.
  • the authenticating server may request proof of possession of at least one authentication factor from user 26, either directly or using a third-party multi-factor authentication (MFA) provider.
  • MFA multi-factor authentication
  • the authenticating server may instruct an MFA provider to request that the user provide proof of possession of a password, a biometric factor, and/or a particular device, such as a cellphone (e.g., a smartphone).
  • the request for the proof of possession may be out-of-band - such as in cases in which the request is sent to the user’s cellphone - or in-band.
  • the authenticating server in response to receiving the proof of possession, the authenticating server generates a response to the challenge by using the appropriate key to sign the challenge, and then causes the response to be passed to the RP.
  • system 20 further comprises a proxy server 24, comprising a network interface, such as a NIC 36, and a processor 38.
  • system 20 does not comprise proxy server 24; in such embodiments, the functionality of proxy server 24, described below with reference to Fig. 3, may be performed by authenticating server 28.
  • the respective processors of client 22, RP 44, authenticating server 28, and proxy server 24 are configured to communicate with each other, via their respective network interfaces, over a network 30, such as the Internet or any other computer network.
  • each of the aforementioned processors may be embodied as a single processor, or as a cooperatively networked or clustered set of processors.
  • the functionality of each processor, as described herein, is implemented solely in hardware, e.g., using one or more Application-Specific Integrated Circuits (ASICs) or Field-Programmable Gate Arrays (FPGAs).
  • ASICs Application-Specific Integrated Circuits
  • FPGAs Field-Programmable Gate Arrays
  • the functionality of at least one of the processors is implemented at least partly in software.
  • the processor is embodied as a programmed digital computing device comprising at least a central processing unit (CPU) and random access memory (RAM). Program code, including software programs, and/or data are loaded into the RAM for execution and processing by the CPU.
  • the program code and/or data may be downloaded to the processor in electronic form, over a network, for example.
  • the program code and/or data may be provided and/or stored on non-transitory tangible media, such as magnetic, optical, or electronic memory.
  • Such program code and/or data when provided to the processor, produce a machine or special-purpose computer, configured to perform the tasks described herein.
  • FIG. 2 is a schematic illustration of a flow of communication for authenticating to RP 44, in accordance with some embodiments of the present invention.
  • the flow' illustrated in Fig. 2 begins with a request 48 to authenticate to the RP, which the client sends, in an authentication-request-containing message 47, to the RP.
  • the RP In response to receiving request 48, the RP generates a challenge 50 and passes challenge
  • Challenge -containing message 49 may include, in addition to the challenge, code that, if executed by tire client, would cause the client to pass the challenge to the token required by the protocol.
  • challenge-containing message 49 may include a webpage containing, in addition to the challenge, a call to an application programming interface (API) for passing the challenge to the token.
  • API application programming interface
  • challenge-containing message 49 may contain other data associated with the challenge, such as the application ID of the secure application to which access is requested and/or a key handle identifying the key required to sign the challenge.
  • the client may validate any of the data contained therein. For example, for cases in which the application is accessed by pointing a web browser to a Uniform Resource Identifier (URI), the client may verify that the received application ID matches the URI, i.e., is derived from the URI as specified by the protocol.
  • URI Uniform Resource Identifier
  • sign-request-containing message 51 contains, along with the challenge, data for identifying the key required to sign the challenge, the user to whom the key is assigned, and/or the application to which access is requested.
  • message 51 may contain the key handle identifying the key, the user ID of the user (under which request 48 was generated), the application ID of the application, and/or one or more properties of the RP, such as the IP address of the RP.
  • message 51 may contain one or more properties of client 22, such as the IP address of the client, which may be used to identify the user ID.
  • message 51 Other relevant data that may be included in message 51 include the URI pointed to by the browser running on the client, the Transport Layer Security (TLS) Channel ID over which the client is in communication with the RP, and/or the time at which request 48 was generated. Such data may be used for performing the adaptive authentication techniques described hereinbelow.
  • TLS Transport Layer Security
  • the communication of request 45 to the authenticating server may be implemented using any suitable technique.
  • an application used by the client to request to authenticate to the RP such as a web browser, may be modified to perform this functionality.
  • a portion of code that, when executed by processor 42 (Fig. 1), causes the application to pass request 45 to the token required by the protocol may be replaced with another portion of code that causes the application to pass request 45 to the authenticating server.
  • a dedicated application which is configured to communicate with the authenticating server in lieu of the token, may be used to request to authenticate to the RP.
  • a software agent e.g., a driver or filter driver
  • a software agent that simulates the token and is installed on the client may be used to pass the request to the authenticating server.
  • the application used by the client to request to authenticate to the RP e.g., a web browser
  • the software agent passes request 45 to the software agent (e.g , by executing the aforementioned code received from the RP) even without any special configuration of the application.
  • the software agent passes the request to the authenticating server.
  • the client communicates with the authenticating server over a secure encrypted TLS channel.
  • the authenticating server prior to the communication of any requests to the authenticating server over the channel, the authenticating server requires that the user prove the possession of a designated authentication factor, such as a password.
  • a designated authentication factor such as a password.
  • challenge -related communication between the client and the authenticating server may be enabled until the user logs out from the client.
  • proof of a different respective authentication factor may be required to enable challenge-related communication for each RP or group of RPs.
  • the authenticating server In response to receiving message 51, the authenticating server identifies the key required to sign the challenge, the user to whom the key is assigned, and/or the application to which access is requested. These parameters are typically identified from data contained explicitly in the message - such as a key handle, a user ID, a client IP address, or an RP IP address - in combination with relevant information stored in data storage 35 (Fig. 1). For example, given a key handle, the authenticating server may look up the key and the user with which the key handle is associated in the data storage. (It is noted that in the context of the present application, including the claims “looking up” or“identifying” a user may include looking up or identifying any identifier for the user or for a device belonging to the user, even without identifying the name of the user.)
  • the authenticating server may generate a response 56 to the challenge by using the key to sign the challenge, even without first requiring that user 26 authenticate himself.
  • the authenticating server may then cause the response to be communicated to the RP.
  • the authenticating server may pass the response to the client such that the client passes the response to the RP.
  • the authenticating server may pass the response to the aforementioned software agent, and the software agent may then pass the response to the application that submitted the request to authenticate, thus causing the response to be passed to the RP.
  • the authenticating server may pass tire response directly to the RP.
  • the authenticating server may request, from user 26, proof 54 of possession of at least one authentication factor (AF) associated with the user to whom the key is assigned, as described above with reference to Fig. 1.
  • the authenticating server may request that user 26 prove that he is the user to whom tire key is assigned. (In such cases, the authenticating server may not identify the key until after proof 54 is recei ved.)
  • the authenticating server in response to the user proving possession of the authentication factor, the authenticating server generates response 56 and then causes the response to be communicated to the RP, e.g., by communicating the response to the client such that the client communicates the response to the RP.
  • the authenticating server refrains from signing the challenge. In such a case, the authenticating server may return a faulty response to the client, such that the client cannot authenticate to the RP. Alternatively, the authenticating server may send the client an error or close the connection wdth the client, thus causing the client to close the connection between the client and the RP.
  • the authenticating server implements adaptive authentication, based on authentication policies stored in data storage 35 (Fig. 1). In other words, the authenticating server decides whether to request proof 54 from the user based on relevant parameters of the client’s request to authenticate to the RP and, optionally, a stored record of previous authentication requests and/or other data collected by security systems or sensors. Examples of relevant parameters include the user ID that was used to generate tire request to authenticate, the identity of the RP, the identity of the client, and the time of the request. In some embodiments, the authenticating server computes a measure of risk associated with each request to authenticate to the RP, and then requests proof 54 in response to the measure exceeding a predefined threshold.
  • the authenticating server may sign the challenge without first requesting proof 54 from the user.
  • the authenticating server may require that the user first submit proof 54. (In some cases, the authenticating server may decide, based on the aforementioned relevant parameters, not to sign the challenge regardless of whether the user possesses the authentication factor.)
  • the authenticating server requests proof 54 directly from the user.
  • the request for the proof of possession is performed via an MFA provider 46.
  • the authenticating server communicates, to MFA provider 46, a request 52 to authenticate the user (For simplicity, the message in which request 52 is contained, along with the subsequent messages in the flow of communication, are not explicitly labeled in Fig. 2 or mentioned in the present description. )
  • the MFA provider communicates, to user 26, a request 53 to provide proof of possession of the authentication factor.
  • the user may communicate the proof to the MFA provider.
  • the MFA provider may authenticate the user and then communicate an authentication confirmation 55 to the authenticating server.
  • the MFA provider may forward the proof to the authenticating server and the authenticating server may then authenticate the user.
  • the required authentication factor includes a cellphone, such as a smartphone.
  • the authenticating server may identify an identifier of the cellphone of the user to whom the key is assigned. Subsequently, the authenticating server may pass the identifier, along with request 52, to the MFA provider. In response to receiving the identifier and the request, the MFA provider may communicate a message to the cellphone, the message asking the user of the cellphone to confirm that he requested to authenticate to the RP. Subsequently, provided that user 26 is carrying the cellphone, the user may provide the confirmation, thus proving possession of the cellphone.
  • the identifier communicated to the MFA provider may include any suitable alphanumeric string, such as a phone number, an IP address, or a dedicated identifier used by the authenticating server and the MFA provider.
  • tire MFA provider includes a push-notification service, and the message sent to the user includes an IP-based push notification.
  • request 53 may be communicated to client 22.
  • the MFA provider may communicate (e.g., via short message service (SMS)) a one-time password (OTP) to the cellphone and also communicate request 53 to client 22, requesting that user 26 prove possession of the cellphone by submitting the OTP.
  • request 53 communicated to client 22 may request that user 26 submit (and hence prove possession of) another, predesignated password, which functions as the required authentication factor.
  • the authenticating server is also configured to perform, in lieu of the regular token, any other relevant functions required by the protocol. For example, in response to receiving (or signing) the challenge, the authenticating server may increment a counter that tracks, for each key, the number of requests (or the number of successful requests) to authenticate. The authenticating server may then generate the response by signing the counter value in combination with the challenge. Alternatively or additionally, the authenticating server may sign, in combination with the challenge, the aforementioned URI, TLS Channel ID, and/or application ID.
  • FIG. 3 is a schematic illustration of a flow of communication for authenticating to RP 44 using proxy server 24, in accordance with some embodiments of the present invention.
  • proxy server 24 proxies between the client and the RP.
  • the client communicates request 48 to the RP via proxy server 24.
  • the RP generates challenge 50, which is directed to the client, and passes the challenge to the proxy server in challenge-containing message 49.
  • the proxy server causes request 45 to be passed to the authenticating server.
  • challenge-containing message 49 may contain code that, if executed by the client, would cause the client to pass request 45 to the token required by the protocol.
  • the proxy server may modify the code to cause the client to pass request 45 to the proxy server upon execution of the code by the client.
  • the proxy server may then pass the modified code, together with the challenge, to the client, in a modified challenge-containing message 49’.
  • the proxy server may receive request 45 from the client.
  • the proxy server may pass request 45 to the authenticating server.
  • the proxy server may modify the code to cause tire client to pass request 45 directly to the authenticating server.
  • the authenticating server may receive request 45 from the client.
  • the aforementioned code includes a call to an API.
  • the proxy server may modify the code to call a different API, such that, upon execution of the modified code, the client passes request 45 to the proxy server or directly to the authenticating server.
  • the code may include a call to a javascript function named“u2f.sign,” which, when executed, causes the challenge to be sent to a physical U2F token in such a case, the proxy server may replace the call to“u2f.sign” with a call to another javascript function that, when executed by the client, causes the client to pass request 45 to the proxy server or directly to the authenticating server.
  • the proxy server may generate request 45 on behalf of the client and then pass request 45 directly to the authenticating server.
  • the authenticating server may request, e.g., via MFA provider 46, proof of possession of at least one authentication factor from the user, as described above with reference to Fig. 2. Subsequently, in response to receiving the proof or confirmation from the MFA provider that the proof was received, the authenticating server may generate response 56 and then pass the response to the proxy server.
  • the proxy server In response to receiving the response, the proxy server causes the response to be passed to the RP. For example, as shown in Fig. 3, the proxy server may forward the response to the client such that the client then passes the response to the RP via the proxy server. Alternatively, the proxy may forward the response directly to the RP.
  • the authenticating server may pass response 56 directly to the client.
  • the client may then pass the response to the RP via the proxy server.
  • the authenticating server may pass the response directly to the RP.
  • the functionality of both the authenticating server and the proxy server may be performed by a single server.
  • the authenticating server may receive the challenge from the RP by proxying between the client and the RP.
  • the authenticating server may pass the challenge to the client, and then receive request 45 from the client.
  • the authenticating server may generate the response and then pass the response to the client.
  • the client may pass the response to the RP via the authenticating server.
  • the authenticating server may pass the response directly to the RP.
  • the proxy may serve as a gateway for access to network 30 (Fig. 1) from the LAN or cloud computing environment to which client 22 belongs.
  • the application such as the web browser, used by the client to request to authenticate to the RP may be configured to communicate with the RP via the proxy.
  • the client may be configured to use the proxy server for all outgoing connections to network 30 or for all outgoing Hypertext Transfer Protocol (HTTP) or HTTP Secure (HTTPS) traffic.
  • the proxy server typically uses a certificate signed by a certificate authority trusted by the client, such that the proxy server may decrypt the traffic received from the client.
  • Fig 4 is a schematic illustration of an example algorithm 58 for authenticating to RP 44 (Fig. 1), in accordance with some embodiments of the present invention.
  • Algorithm 58 is executed by client 22 (Fig. 1).
  • Algorithm 58 begins with an authentication-requesting step 60, at which the client requests to authenticate to the RP. Subsequently, at a challenge-receiving step 62, the client receives a challenge from the RP. In response thereto, the client, at a request-communicating step 64, communicates a request to sign the challenge to the authenticating server. Subsequently (provided the user is authenticated by the authenticating server), the client receives a response to the challenge at a first response-receiving step 66. Finally, the client communicates the response to the RP at a response-communicating step 68.
  • Fig. 5 is a schematic illustration of an example algorithm 90, executed by the authenticating server, for facilitating authentication to the RP, in accordance with some embodiments of the present invention.
  • Algorithm 90 begins with a first request-receiving step 92, at which the authenticating server receives, from the client, a request to sign a challenge.
  • the authenticating server decides, at a deciding step 94, whether authentication of the user is required. If not, the authenticating server generates a response to the challenge at a response- generating step 100, by using the appropriate key to sign the challenge.
  • the authenticating server causes the response to be passed to the RP, e.g., by passing the response to the client such that the client passes the response to the RP.
  • the authenticating server requests, at a proof -requesting step 96, that the user prove possession of at least one authentication factor. (This request may be performed using a third-party MFA provider, as described above with reference to Figs. 2-3.) Subsequently, at a checking step 98, the authenticating server checks whether the user proved possession of the authentication factor within a predefined period of time if yes, the authenticating server performs response-generating step 100 and first response-passing step 102, as described above. Otherwise, the authenticating server closes the connection with the client at a connection-closing step 104, or otherwise inhibits the client from authenticating to the RP.
  • Fig. 6 is a schematic illustration of an example algorithm 70 for proxying between the client, the authenticating server, and the RP, in accordance with some embodiments of the present invention.
  • Algorithm 70 begins with a second request-receiving step 72, at which the proxy server receives a request to authenticate to the RP from the client.
  • the proxy server passes tire request, at a first request-passing step 74, to the RP.
  • the proxy server receives a challenge with relevant code from the RP
  • the proxy server modifies the code at a code -modifying step 78, and then passes the challenge with the modified code to the client at a challenge-passing step 80.
  • the proxy server receives, from the client, a request to sign the challenge.
  • the proxy server passes the request to the authenticating server at a second request-passing step 84.
  • the proxy server receives a response to the challenge at a second response- receiving step 86.
  • the proxy server causes the response to be passed to the RP, e.g., by passing the response to the client such that the client passes the response, via the proxy server, to the RP.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)

Abstract

La présente invention concerne un système (22) qui contient une interface réseau (40) et un processeur (42). Le processeur est configuré pour recevoir, par l'intermédiaire de l'interface réseau, un défi (50) généré par une partie utilisatrice (RP) (44) conformément à un protocole nécessitant qu'une clé, qui est nécessaire pour signer le défi, soit fournie par un jeton associé au processeur, pour transmettre une demande (45) afin de signer le défi, sur un réseau (30), à un serveur d'authentification (28) qui possède la clé, pour recevoir, en provenance du serveur d'authentification, une réponse (56) au défi, qui a été générée par le serveur d'authentification en utilisant la clé pour signer le défi, et pour amener la réponse à être transmise à la RP. L'invention décrit également d'autres modes de réalisation.
PCT/IB2019/061083 2019-01-10 2019-12-19 Utilisation de jetons virtuels pour étendre des protocoles d'authentification WO2020144518A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201962790501P 2019-01-10 2019-01-10
US62/790,501 2019-01-10

Publications (1)

Publication Number Publication Date
WO2020144518A1 true WO2020144518A1 (fr) 2020-07-16

Family

ID=71520456

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2019/061083 WO2020144518A1 (fr) 2019-01-10 2019-12-19 Utilisation de jetons virtuels pour étendre des protocoles d'authentification

Country Status (1)

Country Link
WO (1) WO2020144518A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11997090B2 (en) 2021-11-29 2024-05-28 Cisco Technology, Inc. Systems and methods for WebAuthn transport via a WebAuthn proxy

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140157393A1 (en) * 2005-06-13 2014-06-05 Iamsecureonline, Inc. Proxy authentication network
US9191381B1 (en) * 2011-08-25 2015-11-17 Symantec Corporation Strong authentication via a federated identity protocol
US20160087957A1 (en) * 2013-04-26 2016-03-24 Interdigital Patent Holdings, Inc. Multi-factor authentication to achieve required authentication assurance level

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140157393A1 (en) * 2005-06-13 2014-06-05 Iamsecureonline, Inc. Proxy authentication network
US9191381B1 (en) * 2011-08-25 2015-11-17 Symantec Corporation Strong authentication via a federated identity protocol
US20160087957A1 (en) * 2013-04-26 2016-03-24 Interdigital Patent Holdings, Inc. Multi-factor authentication to achieve required authentication assurance level

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Imperial Violet Security Keys", IMPERIAL VIOLET, 27 March 2018 (2018-03-27), XP055725072, Retrieved from the Internet <URL:https://www.imperialviolet.org/2018/03/27/webauthn.html> *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11997090B2 (en) 2021-11-29 2024-05-28 Cisco Technology, Inc. Systems and methods for WebAuthn transport via a WebAuthn proxy

Similar Documents

Publication Publication Date Title
EP3378209B1 (fr) Systèmes et procédés d&#39;authentification d&#39;un utilisateur en ligne au moyen d&#39;un serveur d&#39;autorisation sécurisé
EP3756328B1 (fr) Architecture de système d&#39;une autorité de certification à base d&#39;identité
US9565212B2 (en) Secure mobile framework
EP2898441B1 (fr) Authentification par signature unique multi-facteur mobile
US8997196B2 (en) Flexible end-point compliance and strong authentication for distributed hybrid enterprises
US8532620B2 (en) Trusted mobile device based security
US20170244676A1 (en) Method and system for authentication
US11122047B2 (en) Invitation links with enhanced protection
US20140075513A1 (en) Device token protocol for authorization and persistent authentication shared across applications
US10681023B2 (en) Self-service portal for provisioning passwordless access
JP2015535984A5 (fr)
WO2021173264A1 (fr) Validation de jeton de sécurité à l&#39;aide de validations partielles de politique
JP5827680B2 (ja) ＩＰｓｅｃとＩＫＥバージョン１の認証を伴うワンタイム・パスワード
US11924211B2 (en) Computerized device and method for authenticating a user
US20230403155A1 (en) Whitelisting clients accessing resources via a secure web gateway with time-based one time passwords for authentication
WO2020144518A1 (fr) Utilisation de jetons virtuels pour étendre des protocoles d&#39;authentification
US11177958B2 (en) Protection of authentication tokens
Lazarev et al. Analysis of applicability of open single sign-on protocols in distributed information-computing environment
US11405379B1 (en) Multi-factor message-based authentication for network resources
Paul et al. UI Component and Authentication
CN114500074B (zh) 单点系统安全访问方法、装置及相关设备
CN115150831A (zh) 入网请求的处理方法、装置、服务器及介质
NL2010808C2 (en) System and method for remote access.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19909189

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19909189

Country of ref document: EP

Kind code of ref document: A1