System and method for protection against malicious program code injection

Abstract

[0006] Systems, apparatus, methods, and machine-readable media for preventing malicious code injection are described. For example, one embodiment of the apparatus includes: a processor that executes an application for accessing web pages on the Internet in response to user input, the web pages having one or more resource descriptors and / or code descriptors associated with the one or more resource descriptors; an authenticator engine that validates the web pages based at least in part on the resource descriptors and / or code descriptors by connecting to a trusted entity, the trusted entity configured to generate a signature on a cryptographic assertion that includes one or more resource descriptor objects associated with the one or more resource descriptors and / or one or more code descriptor objects associated with the one or more code descriptors.

Description

Technical Field

[0001] The present invention generally relates to the field of data processing systems. More specifically, the present invention relates to systems and methods for protecting against malicious program code injection such as JavaScript injection.

Background Art

[0002] FIG. 1 shows an exemplary client 120 having a biometric device 100. During normal operation, the biometric sensor 102 reads raw biometric data from the user (e.g., captures the user's fingerprint, records the user's voice, takes a snapshot of the user, etc.), and the feature extraction module 103 extracts specified characteristics of the raw biometric data (e.g., focuses on specific regions of the fingerprint, specific facial features, etc.). The matching module 104 compares the extracted feature 133 with the biometric reference data 110 stored in the secure storage of the client 120 and generates a score based on the similarity between the extracted feature and the biometric reference data 110. The biometric reference data 110 is generally the result of a registration process in which the user registers a fingerprint, voice sample, image, or other biometric data with the device 100. Next, the application 105 may use the score to determine whether the authentication was successful (e.g., whether the score exceeds a specific specified threshold).

[0003] The system shown in FIG. 1 is biometric-oriented, but various other or additional authentication techniques may be employed on the exemplary client 120. For example, the client-side authentication unit may be based on a PIN or other secret code (e.g., password) entered by the user and / or may be initiated based on the presence of the user (e.g., a button the user presses to verify presence).

[0004] The system is designed to provide secure user authentication on a network using biometric sensors. In such a system, scores and / or other authentication data generated by an application may be sent over the network for the remote server to authenticate the user. For example, U.S. Patent Application Publication No. 2011 / 0082801 (“the ‘801 application”) describes a framework for user registration and authentication on a network that provides strong authentication (e.g., protection against identity theft and phishing), secure transactions (e.g., protection against “malware-in-the-browser” and “man-in-the-middle” attacks on transactions), and registration / management of client authentication tokens (e.g., fingerprint readers, face recognition devices, smart cards, trusted platform modules, etc.).

[0005] The assignee of this patent application has developed various improvements to the authentication framework described in the '801 application. Some of these improvements are described in the following group of U.S. patent applications (the "co-pending applications") that were assigned to the assignee of this application on December 29, 2012, and are incorporated herein by reference: U.S. Patent Application No. 13 / 730,761, Query System and Method to Determine Authentication Capabilities; U.S. Patent Application No. 13 / 730,776, System and Method for Efficiently Enrolling, Registering, and Authenticating With Multiple Authentication Devices; U.S. Patent Application No. 13 / 730,780, System and Method for Processing Random Challenges Within an Authentication Framework; U.S. Patent Application No. 13 / 730,791, System and Method for Implementing Privacy Classes Within an Authentication Framework; U.S. Patent Application No. 13 / 730,795, System and Method for Implementing Transaction Signaling Within an Authentication Framework.

[0006] Put simply, a co-pending application describes an authentication technique that a user registers with an authentication device (or authentication unit) such as a biometric device (e.g., a fingerprint sensor) on a client device. When the user is registered by the biometric device, biometric reference data is captured (e.g., by swiping a finger, taking a photo, recording a voice, etc.). The user then registers the authentication device with one or more servers on the network (e.g., a website or other relying party equipped with a secure transaction service as described in the co-pending application) and can then authenticate with those servers using data exchanged during the registration process (e.g., an encryption key provisioned to the authentication device). Once authenticated, the user is permitted to execute one or more online transactions with the website or other relying party. In the framework described in the co-pending application, confidential information, such as fingerprint data and other data that can be used to uniquely identify the user, may be locally retained on the user's authentication device to protect the user's privacy.

[0007] A better understanding of the present invention can be obtained from the following detailed description in conjunction with the following drawings.

Brief Description of the Drawings

[0008]

Figure 1

[0009]

Figure 2A

Figure 2B

[0010]

Figure 2C

[0011]

Figure 3A

Figure 3B

[0012]

Figure 4

[0013]

Figure 5A

Figure 5B

[0014]

Figure 6

[0015]

Figure 7

Figure 8

[0016]

Figure 9

[0017]

Figure 10

[0018]

Figure 11

[0019]

Figure 12

[0020]

Figure 13

[0021]

Figure 14

[0022]

Figure 15

[0023]

Figure 16

DETAILED DESCRIPTION OF THE INVENTION

[0024] The following describes embodiments of apparatuses, methods, and machine-readable media for implementing advanced authentication techniques and related applications. Throughout the description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one of ordinary skill in the art that the present invention may be practiced without some of these specific details. In other instances, well-known structures and devices are not shown or are shown in block diagram form to avoid obscuring the basic principles of the present invention.

[0025] The embodiments of the present invention to be considered below involve client devices with authentication capabilities such as biometric devices or PIN entry. These devices may be referred to herein as "tokens", "authentication devices", or "authentication units". Certain embodiments focus on face recognition hardware / software (e.g., a camera and associated software for recognizing a user's face and tracking the user's eye movements), and some embodiments can utilize additional biometric devices including, for example, fingerprint sensors, voice recognition hardware / software (e.g., a microphone and associated software for recognizing a user's voice), and optical recognition functions (e.g., an optical scanner and associated software for scanning a user's retina). The authentication capabilities can also include non-biometric devices such as trusted platform modules (TPMs) and smart cards.

[0026] In the implementation of mobile biometrics, the biometric device may be remote from the relying party. As used herein, the term "remote" means that the biometric device is not part of the security boundary of the computer to which it is communicatively coupled (e.g., not embedded within the same physical housing as the relying party computer). As an example, the biometric device can be coupled to the relying party via a network (e.g., the Internet, a wireless network link, etc.) or via a peripheral input such as a USB port. Under these conditions, there may be no way for the relying party to know whether the device has been authenticated by the relying party (e.g., providing an acceptable level of authentication and integrity protection) and / or whether the biometric device has been compromised by a hacker. The reliability in a biometric device depends on the specific implementation of the device.

[0027] However, as will be described below, authentication techniques used to authenticate a user can include non-location components such as communication via a network with a remote server and / or other data processing devices. Further, while specific embodiments (such as ATMs and retail stores) are described herein, it should be noted that the basic principles of the present invention may be implemented within the context of any system in which a transaction is initiated locally or remotely by an end user.

[0028] The term "relying party" is used herein to refer not only to an entity attempting to execute a user transaction (e.g., a website or online service that executes a user transaction), but also to a secure transaction server implemented on behalf of that entity that may execute the basic authentication techniques described herein. A secure transaction server providing remote authentication capabilities may be owned and / or under the control of the relying party, or may be under the control of a third party that provides secure transaction services to the relying party as part of its business configuration.

[0029] The term "server" is used herein to refer to software that runs on a hardware platform (or across multiple hardware platforms) that receives requests from a client via a network, performs one or more operations in response, and typically sends a response including the result of the operation to the client. A server responds to a client's request so as to provide or assist in providing a network "service" to the client. Importantly, a server is not limited to a single computer (e.g., a single hardware device running server software), but in fact may potentially span multiple hardware platforms at multiple geographical locations.

[0030] Embodiments of the invention described herein include techniques for authenticating a user to initiate a transaction through a secure transaction device. As an example, the transaction may be a refund, a transfer, or other user-initiated action, and the transaction device may be an automatic teller machine (ATM), a point-of-sale (PoS) transaction device dedicated to a sales floor, or other device capable of executing a transaction on behalf of a user. The transaction may be accompanied by, for example, completion of payment for the purchase of goods or services at a retail store or other retail location equipped with the device, refund of funds via the device, performance of maintenance on the device, or any other transaction that requires user authentication.

[0031] One embodiment of the invention provides techniques for locally authenticating (i.e., verifying) a user even in situations where the device is offline (i.e., not connected to a backend authentication server) or semi-offline (i.e., connected to the backend authentication server only periodically). In one embodiment, the user's client device has the ability to cache authentication requests generated by a backend authentication server (operating, for example, on behalf of a relying party), and the device includes data necessary to verify an authentication response transmitted from the user's client device to the device.

[0032] Before discussing the details of these embodiments, an overview of remote user authentication techniques is provided. These and other remote user authentication techniques are assigned to the assignee of this application and are described in co-pending applications incorporated herein by reference. Remote User Authentication Techniques

[0033] Figures 2A and 2B show two embodiments of a system architecture with client - side and server - side components for remotely authenticating a user. The embodiment shown in Figure 2A uses a browser - plugin - based architecture to communicate with a website, while the embodiment shown in Figure 2B does not require a browser. The various authentication techniques and related applications described herein may be implemented in either of these system architectures. For example, the authentication engine within the client device described herein may be implemented as part of a Secure Transaction Service 201 that includes an interface 202. However, it should be noted that the above - described embodiments may be realized using hardware and software logical configurations other than those shown in Figures 2A - B.

[0034] Referring to Figure 2A, the illustrated embodiment includes a client 200 equipped with one or more authentication devices 210 - 212 for registering and authenticating an end - user. As described above, the authentication devices 210 - 212 may include biometric devices such as fingerprint sensors, voice recognition hardware / software (e.g., a microphone and related software for recognizing the user's voice), face recognition hardware / software (e.g., a camera and related software for recognizing the user's face), and optical recognition capabilities (an optical scanner and related software for scanning the user's retina), as well as non - biometric devices such as a Trusted Platform Module (TPM) and a smart card. The user can register with a biometric device by providing biometric data (e.g., swiping a finger on a fingerprint authentication device) that the Secure Transaction Service 201 can store as biometric template data in the Secure Storage 220 (via the interface 202).

[0035] Although the secure storage 220 is shown outside the secure peripheral devices of the authentication devices 210-212, in one embodiment, each authentication device 210-212 may have its own integrated secure storage. In addition, each authentication device 210-212 may cryptographically protect (e.g., wrap the data record to secure the storage 220) the biometric reference data record.

[0036] The authentication devices 210-212 are communicatively coupled to the client through an interface 202 (e.g., an application programming interface, i.e., API (application programming interface)) exposed by the secure transaction service 201. The secure transaction service 201 is a secure application that communicates with one or more secure transaction servers 232-233 over a network and interfaces with a secure transaction plugin 205 executed within the context of a web browser 204. As shown, the interface 202 may also provide secure access to the secure storage device 220 of the client 200 that stores information regarding each of the authentication devices 210-212, such as a device identification code (authenticator attestation ID, AAID), a user identification code, user registration data (e.g., a scanned fingerprint or other biometric data), and a key used to execute the secure authentication techniques described herein. For example, as described in detail later, a unique key may be stored in each authentication device and then used when communicating with the server 230 over a network such as the Internet.

[0037] As described below, certain types of network transactions are supported by a secure transaction plugin 205, such as an HTTP or HTTPS transaction with website 231 or another server. In one embodiment, the secure transaction plugin is initiated in response to a specific HTML tag inserted into the HTML code of a web page by a web server 231 (sometimes simply referred to as "server 230") within a secure enterprise or web destination 230. In response to detecting such a tag, the secure transaction plugin 205 can transfer the transaction to the secure transaction service 201 for processing. Further, for certain types of transactions (e.g., secure key exchange, etc.), the secure transaction service 201 can open a direct communication channel with an on-premises transaction server 232 (i.e., located at the same location as the website) or an off-premises transaction server 233.

[0038] The secure transaction servers 232-233 are coupled to a secure transaction database 240 that stores user data, authentication device data, keys, and other secure information necessary to support the secure authentication transactions described below. However, it should be noted that the basic principles of the present invention do not require the separation of the logical components within the secure enterprise or web destination 230 shown in FIG. 2A. For example, website 231 and secure transaction servers 232-233 may be implemented on a single physical server or separate physical servers. Further, website 231 and transaction servers 232-233 may be implemented within an integrated software module executed on one or more servers to perform the functions described below.

[0039] As described above, the basic principle of the present invention is not limited to the browser-based architecture shown in FIG. 2A. FIG. 2B shows an alternative implementation where a stand-alone application 254 authenticates a user on the network using the functions provided by the secure transaction service 201. In one embodiment, the application 254 is designed to establish a communication session with one or more network services 251 that depend on secure transaction servers 232-233 for performing user / client authentication techniques described in detail later.

[0040] In either of the embodiments shown in FIGS. 2A-2B, the secure transaction servers 232-233 may generate keys that are then securely transmitted to the secure transaction service 201 and stored in an authentication device within the secure storage 220. In addition, the secure transaction servers 232-233 manage a server-side secure transaction database 240.

[0041] Figure 2C shows a series of transactions for registering an authentication device. As described above, during registration, the key is shared between the authentication device and one of the secure transaction servers 232-233. The key is stored in the secure storage 220 of the client 200 and in the secure transaction database 220 used by the secure transaction servers 232-233. In one embodiment, the key is a symmetric key generated by one of the secure transaction servers 232-233. However, in another embodiment described below, an asymmetric key may be used. In this embodiment, the public key may be stored by the secure transaction servers 232-233, and the second related private key may be stored in the client's secure storage 220. Further, in another embodiment, the key may be generated on the client 200 (e.g., by the authentication device or authentication device interface rather than the secure transaction servers 232-233). The basic principle of the present invention is not limited to any particular type of key or key generation method.

[0042] Secure key provisioning protocols such as the Dynamic Symmetric Key Provisioning Protocol (DSKPP) may be used to share keys between the client and the secure communication channel (see, for example, Request for Comments (RFC) 6063). However, the basic principle of the present invention is not limited to any particular key provisioning protocol.

[0043] Referring to the specific details shown in FIG. 2C, when user registration or user verification is completed, the server 230 generates a random generated challenge (e.g., an encryption nonce) that must be presented by the client during device registration. The random challenge can be valid for a limited period of time. The secure transaction plugin detects the random challenge and transfers it to the secure transaction service 201. In response, the secure transaction service initiates an out-of-band session (e.g., an out-of-band transaction) with the server 230 and communicates with the server 230 using a key provisioning protocol. The server 230 verifies the user's location using the username, activates the random challenge, activates the authentication code (e.g., AAID) if it is sent, and creates a new entry for the user in the secure transaction database 220. Also, a key or a public / private key pair may be generated, the key may be written to the database 220, and the key may be returned to the secure transaction service 201 using the key provisioning protocol. When completed, the authentication device and the server 230 share the same key if a symmetric key is used, and different keys if an asymmetric key is used.

[0044] FIG. 3A shows the verification of a secure transaction for a browser-based implementation. Although a browser-based implementation is shown, the same basic principle may be implemented using a stand-alone application or a mobile device application.

[0045] Secure transaction confirmation is designed to provide stronger security for certain types of transactions (e.g., financial transactions). In the illustrated embodiment, the user confirms each transaction before entrusting the transaction. Using the illustrated technique, the user accurately confirms what he or she wants to accomplish and accurately accomplishes seeing what is displayed in window 301 of the graphical user interface (GUI). In other words, this embodiment ensures that the transaction text is not modified by a "man-in-the-middle" (MITM) or "man-in-the-browser" (MITB) in order to complete a transaction that the user did not confirm.

[0046] In one embodiment, the secure transaction plugin 205 displays window 301 within the browser context to show the details of the transaction. The secure transaction server 201 periodically (e.g., at random intervals) verifies that the text shown in the window has not been tampered with by anyone (e.g., by generating a hash / signature over the displayed text). In different embodiments, the authentication device has a trusted user interface (e.g., provides an API that conforms to GlobalPlatform's TrustedUI).

[0047] The following example helps to highlight the operation of this embodiment. The user selects the item to purchase from the merchant site and selects "checkout". The merchant site sends the transaction to a service provider (e.g., PayPal) that has one or more of the embodiments of the invention described herein implemented as secure transaction servers 232-233. The merchant site authenticates the user and completes the transaction.

[0048] The secure transaction servers 232-233 receive the transaction details (TD), place a "secure transaction" request in an HTML page, and send it to the client 200. The secure transaction request includes the transaction details and a random challenge. The secure transaction plugin 205 detects a request for a transaction confirmation message and forwards all data to the secure transaction service 201. In embodiments that do not use a browser or plugin, the information may be sent directly from the secure transaction server to the secure transaction service on the client 200.

[0049] For browser-based implementations, the secure transaction plugin 205 displays a window 301 with the transaction details to the user (e.g., within the browser context) and prompts the user to provide authentication to confirm the transaction. In embodiments that do not use a browser or plugin, the secure transaction service 201, application 254 (Figure 2B), or authentication device 210 may display the window 301. The secure transaction service 201 starts a timer and verifies the content of the window 301 displayed to the user. The verification period may be randomly selected. The secure transaction service 201 ensures that the user is viewing valid transaction details within the window 301 (e.g., by generating a hash for the details and comparing it to the hash of the exact content to verify that the content is accurate). If it detects that the content has been tampered with, it prevents the generation of a confirmation token / signature.

[0050] After the user provides valid verification data (e.g., by swiping a finger on a fingerprint sensor), the authentication device verifies the user and generates an encrypted signature (which may be referred to as a "token") based on the transaction details and a random challenge (i.e., the signature is calculated over the transaction details and a nonce). This enables the secure transaction servers 232-233 to ensure that the transaction details have not been modified between the server and the client. The secure transaction service 201 sends the generated signature and the username to the secure transaction plugin 205, and the plugin forwards the signature to the secure transaction servers 232-233. The secure transaction servers 232-233 identify the user by the username and verify the signature. If the verification is successful, a confirmation message is sent to the client and the transaction is processed.

[0051] One embodiment of the present invention implements a query policy in which a secure transaction server sends a server policy indicating the authentication capabilities allowed by the server to the client. Next, the client analyzes the server policy to identify a subset of the authentication capabilities that the server policy supports and / or that the user desires to use. Next, the client registers and / or authenticates the user using a subset of the authentication tokens that match the provided policy. Thus, the client is not required to send comprehensive information regarding authentication capabilities (e.g., all of its authentication devices), or other information that may be used to uniquely identify the client, so there is less impact on the client's privacy.

[0052] By way of example and not limitation, the client may include many user verification capabilities, such as, for example, a fingerprint sensor, voice recognition ability, face recognition ability, eye / optical recognition ability, PIN verification, etc. However, for privacy reasons, the user may not wish to disclose to the requesting server details regarding all of those capabilities. Thus, using the techniques described herein, the secure transaction server may send to the client a server policy indicating, for example, support for fingerprint, optical, or smart card authentication. The client may then compare the server policy against its own authentication capabilities and select one or more of the available authentication options.

[0053] One embodiment of the invention uses transaction signing in a secure transaction server such that no transaction state needs to be maintained on the server to maintain a session with the client. In particular, transaction details, such as the transaction text displayed within window 301, may be sent to the client signed by the server. The server may then verify that the signed transaction response received by the client is valid by verifying the signature. The server does not need to persistently store the content of the transaction, thereby consuming a significant amount of storage space for a large number of clients and opening the possibility of denial of service type attacks against the server.

[0054] FIG. 3B shows a website or other network service 311 that initiates a transaction with client 200, in accordance with one embodiment of the invention. For example, the user may be selecting items to purchase on a website and may be ready to check out and pay. In the illustrated example, the website or service 311 hands off the transaction to a secure transaction server 312 that includes signature processing logic 313 for generating and verifying signatures (as described herein) and authentication logic for performing client authentication 314 (using, for example, the authentication techniques described above).

[0055] In one embodiment, the authentication request sent from the secure transaction server 312 to the client 200 includes a random challenge such as an encryption nonce (as described above), transaction details (e.g., a specific text presented to complete the transaction), and a signature generated by the signature processing logic 313 through the random challenge and transaction details using a private key (known only to the secure transaction server).

[0056] When the above information is received by the client, the user may receive an indication that user authentication is required to complete the transaction. In response, the user may, for example, swipe a finger across a fingerprint scanner, snap an image, speak into a microphone, or perform any other type of authentication permitted for a given transaction. In one embodiment, when the user is successfully authenticated by the authentication device 210, the client returns to the server: (1) the random challenge and transaction text (both previously provided to the client by the server), (2) authentication data proving that the user has successfully completed the authentication, and (3) the signature.

[0057] Next, the authentication module 314 on the secure transaction server 312 may confirm that the user is properly authenticated, and the signature processing logic 313 regenerates the signature through the random challenge and transaction text using the private key. If the signature matches the one sent by the client, the server can verify that the text of the transaction is the same as when it was first received from the website or service 311. Since the secure transaction server 312 does not need to persistently store the text of the transaction (or other transaction data) in the secure transaction database 120, storage and processing resources are conserved. System and method for authenticating a client for an offline device or a device with limited connectivity

[0058] As described above, one embodiment of the present invention includes techniques for locally authenticating (i.e., verifying) a user even when the user device and the device are in an offline (i.e., not connected to the relying party's backend authentication server) or semi - offline (i.e., the user device is not connected to the relying party, but the device is connected) situation. FIG. 4 shows one such configuration where a client 400 previously registered with a relying party 451 on an authentication device establishes a secure channel with a transaction device 450 to complete a transaction. By way of example and not limitation, the transaction device may be an ATM, a point - of - sale (PoS) transaction device in a retail location, an Internet of Things (IoT) device, or any other device capable of establishing a channel with the client 400 and enabling the user to execute a transaction. The channel may be implemented using any wireless communication protocol, including by way of example and not limitation, near field communication (NFC) and Bluetooth (e.g., Bluetooth Low Energy (BTLE) as described in Bluetooth Core Specification Version 4.0). Of course, the basic principles of the present invention are not limited to any particular communication standard.

[0059] As indicated by the dotted arrows, the connection between the client 400 and the relying party 451, and / or the connection between the transaction device 450 and the relying party 451, may be sporadic or may not exist. Real-world applications in the payment field often rely on such "offline" usage examples. For example, a user using the client 400 (e.g., a smartphone) may not have connectivity to the relying party 451 at the time of a transaction, but may want to authenticate a transaction (e.g., a payment) by authenticating the transaction device 450. However, in some embodiments of the present invention, the client 400 and / or the transaction device 450 exchange some information with the relying party 451 (although not necessarily during the authentication or transaction confirmation processes described herein).

[0060] Conventionally, user verification has been achieved using secrets such as personal identification numbers (PINs) captured by a device (e.g., a PoS transaction device or an ATM). Next, the device creates an online connection to the relying party to verify the secret or requests the user's authentication component (e.g., an EMV bank card) to verify the PIN. Such implementations have several disadvantages. It may require an online connection, which may not always be available when needed. Also, the user has to enter a secret that may not be trusted on a device for a long period of time, thereby exposing it to shoulder surfing and other attacks. In addition, it is essentially tied to a particular user verification method (e.g., PIN in this case). Finally, the user has to remember a secret such as a PIN, which can be inconvenient for the user.

[0061] The authentication technology described in this specification provides significant flexibility in terms of user verification methods and security, as users can rely on the authentication capabilities of their own clients. In particular, in one embodiment, while the client is connected to the relying party, the mobile application on the user's client caches the authentication requests provided by the relying party. The authentication requests may include the same (or similar) information as the above-described authentication requests (e.g., the nuances and public keys associated with the authentication department), as well as a signature, verification key, and potentially additional information indicating the timing data for the period during which the authentication request remains valid (or conversely, the time after the expiration of the authentication request) for the authentication request (at least a part of it) generated by the relying party. In one embodiment, the mobile application may cache multiple such connection requests (e.g., one for each transaction device or each type of transaction device).

[0062] In one embodiment, the cached authentication requests may then be used for transactions with the transaction device in situations where the client / mobile application cannot connect to the relying party. In one embodiment, the mobile application initiates the creation of an authentication response based on the cached authentication requests, including the serverData and additional data received from the transaction device. The authentication response is then sent to the transaction device, which then verifies the authentication response using the verification key from the relying party (e.g., during the time the transaction device is connected to the relying party). In particular, the transaction device may verify the signature for the serverData included in the authentication response using the key provided by the relying party. In one embodiment, the signature is generated by the relying party using a secret relying party verification key, and the transaction device verifies the signature using the corresponding public relying party verification key (provided to the transaction device by the relying party).

[0063] When the transaction device verifies the serverData extracted from the authentication response, it may verify the authentication response generated by the client / mobile application using the public key (e.g., Uauth.pub) extracted from the authentication request (e.g., in the same or a similar way as the verification by the relying party described above when the client directly authenticates the relying party).

[0064] In an alternative embodiment described below, the relying party provides the authentication request directly to the transaction device (rather than through the mobile application on the client device). In this embodiment, when the transaction device receives a request to complete a transaction from the mobile application on the client, it may request an authentication request from the relying party. Having the authentication request, the request and the authentication response may be validated as described above (e.g., by generating a signature and comparing it with an existing signature).

[0065] FIG. 5A is a transaction diagram showing the interaction between a client 400, a transaction device 450, and a relying party in an embodiment where the client 400 caches the authentication request. This embodiment is sometimes referred to as a "fully offline" embodiment because the transaction device 450 does not need to have an existing connection with the relying party.

[0066] At 501, the client requests a cacheable authentication request from the relying party. At 502, the relying party generates a cacheable authentication request. At 503, the authentication request is sent to the client. At 504, the client puts the authentication request into the cache. In one embodiment, the authentication request includes a public key (Uauth.pub) associated with the authentication component used for authentication, and a signature generated using the relying party verification key (RPVerifyKey) for the public key and a random nonce. When an asymmetric key is used, the RPVerifyKey used by the relying party to generate the signature is a private key with the corresponding public RPVerifyKey that the relying party provided to the transaction device (potentially long before processing the user authentication request).

[0067] In one embodiment, the authentication request also includes timing information indicating the length of time (e.g., MaxCacheTime) for which the authentication request is valid. In this embodiment, the signature for the cacheable authentication request may be generated for the combination of the public authentication key, the nonce, and MaxCacheTime (e.g., ServerData = Uauth.pub|MaxCacheTime|serverNonce|Sign(RPVerifyKey,Uauth.pub|MaxCacheTime|serverNonce)). In one embodiment, the authentication response includes more than one authentication key (e.g., one for each authentication component that can authenticate the user), and the signature may be generated for all of these keys (e.g., along with the nonce and MaxCacheTime).

[0068] As described above, the public RPVerifyKey needs to be known by the transaction device 450, or any device intended to perform offline verification of authentication requests / responses. Since the transaction device has no knowledge of the authentication keys registered with the relying party (i.e., there is no established relationship between the user device and the transaction device), this extension is required. As a result, the relying party must communicate with the transaction device (or other device) in a secure manner in which the key is used for authentication response verification. The transaction device verifies the MaxCacheTime to determine whether the cached authentication request is still valid (to comply with the relying party's policy regarding how long the cached authentication request can be used).

[0069] At 505, the client establishes a secure connection to the transaction device and initiates a transaction. For example, if the transaction device is a PoS transaction device, the transaction may involve a debit or credit transaction. If the transaction device is an ATM, the transaction may involve a cash withdrawal or maintenance operation. The basic principle of the present invention is not limited to any particular type of key or key generation method. Additionally, at 505, the client may send the cached authentication request to the transaction device.

[0070] In response, at 506, the transaction device may send device identification information (e.g., transaction device identification code), a random challenge (nonce), and optionally transaction text of a defined syntax to complete the transaction. The random challenge / nonce is then cryptographically bound to the authentication response. This mechanism enables the device to verify that the user verification is new and not cached / reused.

[0071] To support transaction confirmation such as those described above (see, e.g., FIGS. 3A - B and the related text), the transaction device may be required to create a standardized human - readable representation of the transaction. "Standardized", as used herein, means a format that can be parsed by the relying party (e.g., for final verification as shown in operation 511 below) and / or the transaction device. Since transaction confirmation requires the authentication portion to be displayed on the secure display of the client 400, it needs to be human - readable. An example of such encoding can be XML, in which case XSLT is used for visualization.

[0072] At 507, to generate an authentication response, an authentication user interface is displayed that instructs the user to perform authentication on the client using a specific authentication portion (e.g., swiping a finger on a fingerprint sensor, entering a PIN code, speaking towards a microphone, etc.). When the user provides authentication, the client's authentication engine verifies the user's personal information (e.g., comparing the authentication data collected from the user with the user verification criteria data stored in the secure storage of the authentication portion) and uses the private key associated with the authentication device to encrypt and / or generate a signature for a random challenge (and potentially also the transaction device ID and / or the transaction text). Next, the authentication response is sent to the transaction device at 508.

[0073] At 509, if the signature for the serverData (received at 505) has not yet been verified, the transaction device uses the public RPVerifyKey to perform the verification. Once the serverData is verified, the public key (Uauth.pub) associated with the authentication part used for authentication becomes known. This key is used to verify the authentication response. For example, the public authentication key may be used to decrypt or verify the signature generated for the nonce and any other relevant information (such as the transaction text, transaction device ID, etc.). When the transaction confirmation is executed by the transaction device, at 508, the transaction text displayed to the client may be verified by validating the signature generated for the transaction text and included in the authentication response. Instead of having an encrypted secure serverData structure, the transaction device may also use the connection to verify the unsigned serverData if an online connection to the relying party is available (semi - offline case).

[0074] At 510, depending on whether the authentication was successful or not, an indicator of success or failure is sent to the client. If successful, the transaction device permits the transaction (e.g., debit / credit the account to complete a purchase, make an automatic cash payment, perform accounting operations, etc.). If not successful, the transaction is rejected and / or additional authentication is requested.

[0075] If there is a connection to the relying party, at 511, the transaction device may send the authentication response to the relying party and / or the transaction text (assuming the relying party is the entity responsible for verifying the transaction text). The record of the transaction may be recorded at the relying party and / or the relying party may verify the transaction text and confirm the transaction (not shown).

[0076] Figure 5B is a transaction diagram showing the interaction among the client 400, the transaction device 450, and the relying party in an embodiment where the transaction device has a connection with the relying party and receives an authentication request therefrom. In this embodiment, since the client does not have a connection to the relying party but the transaction device 450 does, it is sometimes referred to as a "semi-offline" embodiment.

[0077] At 521, the client initiates a transaction and establishes a secure connection with a transaction device (e.g., NFC, Bluetooth, etc.). At 522, the transaction device requests an authentication request for the relying party as a response. At 523, the relying party generates an authentication request, and at 524, the authentication request is sent to the transaction device. As in the embodiment shown in Figure 5A, the authentication request may include a public key (Uauth.pub) associated with the authentication part of the client used for authentication, and a signature generated using the RPVerifyKey for the relying party authentication key with respect to the public key and the random nonce. When an asymmetric key is used, the RPVerifyKey used by the relying party to generate the signature is a private key that has a corresponding public RPVerifyKey provided by the relying party to the transaction device (potentially, long before processing the user authentication request). Instead of having an encrypted secure serverData structure, the transaction device may also use the connection to verify unsigned serverData if an online connection to the relying party is available (in the semi-offline case).

[0078] In one embodiment, serverData also includes timing information indicating the length of time (e.g., MaxCacheTime) for which the authentication request is valid. In this embodiment, the signature for serverData may be generated for a combination of the public authentication key, the nonce, and MaxCacheTime (e.g., ServerData = Uauth.pub|MaxCacheTime|serverNonce|Sign(RPVerifyKey,Uauth.pub|MaxCacheTime|serverNonce)). In one embodiment, the authentication response includes one or more authentication keys (e.g., one for each authentication part), and the signature may be generated for all of these keys (e.g., along with the nonce and MaxCacheTime).

[0079] In one embodiment, the remainder of the transaction diagram of FIG. 5B operates substantially as shown in FIG. 5A. At 525, the transaction device may send identification information (e.g., a transaction device identification code), a random challenge (nonce), and a transaction text in an optionally defined syntax to complete the transaction. The random challenge / nonce is then cryptographically bound to the authentication response. This mechanism enables the device to verify that the user authentication is new and not cached / reused.

[0080] To support transaction confirmation such as that described above (see, e.g., FIGS. 3A - B and the related text), the transaction device may be required to create a standardized human-readable representation of the transaction. "Standardized" as used herein means a form that can be parsed by the relying party (e.g., for final verification as shown in operation 511 below) and / or the transaction device. Since transaction confirmation requires the authentication part to be displayed on the secure display of client 400, it needs to be human-readable. An example of such an encoding can be XML, in which case XSLT is used for visualization.

[0081] At 526, to generate an authentication response, an authentication user interface is displayed that instructs the user to perform authentication on the client using a specific authentication component (e.g., swiping a finger across a fingerprint sensor, entering a PIN code, speaking towards a microphone, etc.). When the user provides authentication, the client's authentication engine verifies the user's personal information (e.g., compares the authentication data collected from the user with the user verification criteria data stored in the secure storage of the authentication component), and uses the private key associated with the authentication device to encrypt and / or generate a signature for a random challenge (and potentially, the transaction device ID and / or transaction text). Next, the authentication response is sent to the transaction device at 527.

[0082] At 528, the transaction device uses the public RPVerifyKey to verify the signature for the serverData (received at 524) if the verification has not already been performed. When the serverData is verified, the public key (Uauth.pub) associated with the authentication component used for authentication becomes known. This key is used to verify the authentication response. For example, the public authentication key may be used to decrypt or verify the signature generated for the nonce and any other relevant information (e.g., transaction text, transaction device ID, etc.). When transaction confirmation is performed by the transaction device, at 528, the transaction text displayed to the client may be verified by validating the signature generated for the transaction text and included in the authentication response. Instead of having an encrypted secure serverData structure, the transaction device may also, when an online connection to the relying party is available (semi-offline case), use that connection to verify the unsigned serverData.

[0083] At 529, depending on whether the authentication was successful or not, an indicator of success or failure is sent to the client. If successful, the transaction device permits the transaction (e.g., debit / credit to an account to complete a purchase, automatic payment of cash, execution of accounting operations, etc.). If not successful, the transaction is rejected and / or additional authentication is requested.

[0084] At 530, the transaction device may send an authentication response to the relying party and / or a transaction text (assuming the relying party is the entity responsible for verification of the transaction text). The record of the transaction may be recorded at the relying party, and / or the relying party may verify the transaction text and confirm the transaction (not shown).

[0085] As shown in FIG. 6, in one embodiment, the mobile application 601, in combination with an authentication client 602 (which may be the secure transaction service 201 and interface 202 shown in FIG. 2B), is executed on the client to perform the operations described herein. In particular, the mobile application 601 may open a secure channel to the web application 611 executed on the transaction device 450 using Transport Layer Security (TLS) or other secure communication protocol. The web server 612 of the transaction device may also open a secure channel to communicate with the relying party 451 (e.g., to obtain an authentication request and / or provide an update to the relying party 451 as described above). The authentication client 602 may communicate directly with the relying party 451, for example, to obtain a cacheable authentication request (as described in detail above).

[0086] In one embodiment, the authentication client 602 may identify the relying party and any authenticated mobile application 601 using an "AppID", which is a unique code associated with each application made available by the relying party. In some embodiments where the relying party provides multiple online services, a user may have multiple AppIDs with a single relying party (one for each service provided by the relying party).

[0087] In one embodiment, any application identified by an AppID may have multiple "facets" that identify an acceptable mechanism for connecting to the relying party and / or the application type. For example, a particular relying party may enable access via a web service and also via mobile applications dedicated to different platforms (e.g., Android applications, iOS applications, etc.). These may each be identified using different "FacetIDs" that may be provided to the authentication engine as illustrated by the relying party.

[0088] In one embodiment, the calling mobile application 601 passes its AppID to an API published by the authentication client 602. On each platform, the authentication client 602 identifies the calling application 601 and determines its FacetID. The AppID is then decomposed and it is checked whether the FacetID is included in the TrustedApps list provided by the relying party 451.

[0089] In one embodiment, the cacheable authentication request described above may be realized using a bearer token as shown in FIGS. 7 and 8. In the embodiments of the invention described herein, the token recipient (transaction device 450) needs to be able to verify the token, the authentication response, and the binding of the token to the authentication response without requiring another "online" connection to the token issuer (relying party).

[0090] Two classifications of bearer tokens should be distinguished.

[0091] 1. Tokens that must exist between token issuance and token verification and are only verifiable by a recipient (e.g., transaction device 450) using a different channel for the issuer (e.g., relying party 451). This classification of tokens is referred to herein as "unsigned tokens".

[0092] 2. Tokens verifiable by a recipient by including a digital signature that can be verified using data received from the token issuer, by means of a cryptographic structure, e.g., potentially well before a particular token is issued. This classification of tokens is referred to herein as "signed tokens".

[0093] The term "signed token structure" is used herein to refer to both signed tokens containing the Uauth.pub key and signed structures containing tokens. Combining a signed token with an authentication key

[0094] As shown in FIG. 7, in one embodiment, to combine a signed token with an authentication key, the token issuer (e.g., relying party 451): (a) adds the authentication public key (Uauth.pub) 702 to the signature pending portion 701 of the signature pending token; (b) includes the signed token in the signature pending portion of the authentication response. By doing so, the token recipient (e.g., transaction device 450) can verify the token by validating the signature 703 (e.g., the public RPVerifyKey described above). If the verification is successful, as described above, the public key (Uauth.pub) can be extracted and used to verify the authentication response. Combining an unsigned token with an authentication key

[0095] As shown in FIG. 8, in one embodiment, to bind an unsigned token 802 to an authentication key, the token issuer (e.g., relying party 451) creates a signed structure that encompasses (at least) the original token 802 and the signature-pending data 801 that includes the authentication public key (Uauth.pub). The signed structure can be verified by validating the signature 803 using the public key associated with the private signature key (e.g., the RPVerifyKey pair described above). This public signature key needs to be shared with the token recipient (e.g., transaction device 450). The sharing can occur after the signature key pair is generated and potentially well before the first signed structure is even generated.

[0096] The techniques described herein support both “fully offline” implementations (i.e., at the time of the transaction, the transaction device 450 has no connection to the relying party 451), as well as “semi-offline” implementations (i.e., at the time of the transaction, the transaction device has a connection to the relying party 451, but the client does not).

[0097] Even in the fully offline case, the transaction device 450 is still expected to be connected to the relying party 451 via the host from time to time. For example, the host may collect all responses stored on the transaction device 450 and send them to the relying party, and may also update (if necessary) a list of revoked Uauth keys (e.g., public authentication keys that have been revoked since the last connection).

[0098] Some embodiments also support pure (session) authentication as well as transaction confirmation. Even in the case of transaction confirmation, the relying party 451 can verify the transaction if the transaction device 450 submits the transaction text along with the authentication response to the relying party 451.

[0099] There are several different use cases / applications for the technology described in this specification. Example:

[0100] 1. Payment. The user has registered a payment service provider (PSP) with their authentication device (e.g., smartphone). The user wants to authenticate a payment at a merchant using a point-of-sale (PoS) device dedicated to the merchant and authenticated by the PSP, but the PoS does not have a reliable permanent online connection to the PSP (e.g., is located on a bus). In this example, to enable a transaction despite the lack of a reliable permanent connection, as described above, the PoS may be implemented as the transaction device 450, and the PSP may be implemented as the relying party 451.

[0101] 2. Internet of Things. A company has installed several embedded devices (e.g., in factories, buildings, etc.). Maintenance of such devices is performed by technicians hired by the contracting party. To perform maintenance, the technician must authenticate to the device to prove their suitability for the task. The following assumptions are made (based on the actual configuration conditions). a. The technician cannot perform registration for each such device (because there are too many devices). b. The number of technicians is too large and the variation among such technicians is too great to carefully maintain a list of qualified technicians for each device. c. Neither the devices nor the technician's computer has a reliable network connection at the time of maintenance.

[0102] Using the technology described above, the company can inject a trust anchor (e.g., a public RPVerifyKey) into all devices at once (e.g., at installation time). Each technician then registers with the contracting party (e.g., the relying party 451, which may be the technician's employer). Using the technology described above, the technician can authenticate each device.

[0103] Any of the embodiments of the present invention described above may be implemented in a system where a client having authentication capabilities registers a dependent party, and the authentication operation is performed between this client and a device that (a) acts as an agent for the dependent party and (b) is offline at the time of the transaction (i.e., does not have a reliable network connection to the original server of the dependent party registered by the client). In such an example, the client receives a cacheable authentication request from the original server and caches it. When requested, the client calculates an authentication response and sends it to the device.

[0104] In another embodiment, the client adds channel binding data (received in the authentication request) to the response in an encrypted and secure manner. By doing so, the original server of the dependent party can verify that the request was received by a legitimate client (rather than some intermediary).

[0105] In one embodiment, the dependent party adds additional authenticated data, such as a Uauth.pub key, to the response that enables the device to verify the authentication or transaction confirmation response without the need for the dependent party to contact the dependent party server to obtain the permitted Uauth.pub key. In another embodiment, the dependent party requires the user of the client to perform a successful authentication before issuing a "cacheable" authentication request (to prevent denial of service attacks). In one embodiment, the dependent party requires the client to indicate whether the request is cacheable. If it is cacheable, the dependent party may request additional authentication data in the response (e.g., MaxCacheTime as described above).

[0106] In one embodiment, a device such as the transaction device 450 does not have a direct network connection to the relying party and is "synchronized" to the relying party using a separate computer (sometimes referred to herein as a "host"). This host obtains all the collected authentication responses from the device and forwards them to the relying party. In addition, the host may also copy the list of revoked Uauth keys to the device to ensure that none of the revoked keys are used in the authentication response.

[0107] In one embodiment, a device such as the transaction device 450 sends a random value (e.g., a nonce) to the client, and the client cryptographically adds this random value as an extension to the pre-signature authentication response. This signed random value serves as proof of freshness for the device.

[0108] In one embodiment, the client's authentication part adds the current time Ta as an extension to the pre-signature authentication response. The device / transaction device compares that time with the current time Td and may accept the response only if the difference between Ta and Td is acceptable (e.g., if the difference is less than 2 minutes (abs(Td - Ta) < 2 minutes)).

[0109] In one embodiment, the relying party adds an expiration date for the authenticated (i.e., signed) request that can be cached. As described above, the device / transaction device accepts the response as valid only if it is received before the expiration date.

[0110] In one embodiment, the relying party adds an authenticated (i.e., signed) data block (e.g., the "signed token structure" described above) that includes additional information for cacheable requests, such as a public key, an expiration date, a maximum transaction value (e.g., a Security Assertion Markup Language (SAML) assertion, an OAuth token, a JSON Web Signature (JWS) object, etc., but not limited thereto). The device / transaction device may positively verify the signed data block and allow the response as valid only if the content is acceptable.

[0111] In one embodiment, the relying party adds only the signed token to the cacheable authentication request, but the transaction device has an online connection to the relying party at the time of the transaction. The transaction device uses the online connection to the relying party at the time of the transaction to verify the trustworthiness of the unsigned token.

[0112] Figure 9 shows exemplary "offline" and "semi - offline" authentication scenarios according to an embodiment of the present invention. In this embodiment, a user having a computer device 910 has an established relationship with a relying party 930 and can authenticate the relying party. However, in some situations, the user desires to perform a transaction (e.g., authenticate a transaction confirmation) using a device 970 that has an established relationship with the relying party 930 but not necessarily with the user's computer device 910. For this embodiment, a transaction is referred to as "fully offline" if the connections 920 and 921 do not exist or are not stable at the relevant point in time (e.g., when authenticating the user's computer device 910 with respect to the device 970 or during a transaction between the user's computer device 910 and the device 970). For this embodiment, a transaction is "semi - offline" if the connection 920 between the user's computer device 910 and the relying party 930 is not stable, but the connection 921 between the device 970 and the relying party 930 is stable. Note that in this embodiment, the connection 922 between the user's computer device 910 and the device 970 needs to be stable at the relevant point in time. It is also anticipated that the authentication unit is connected to the user's computer device 910. The connection 922 can be realized using any type of communication channel / protocol including, but not limited to, Bluetooth, Bluetooth Low Energy (BTLE), Near Field Communication (NFC), Wifi, General Packet Radio Service (GSM), Universal Mobile Telecommunications System (UTMS), Long Term Evolution (LTE) (e.g., 4G LTE), and TCP / IP. Exemplary data processing device

[0113] FIG. 10 is a block diagram illustrating an exemplary client and server that can be used in some embodiments of the present invention. Although FIG. 10 illustrates various components of a computer system, it should be understood that such details are not appropriate for the present invention and are not intended to represent any particular architecture or method of interconnecting the components. It will be appreciated that other computer systems with fewer components or multiple components may also be used by the present invention.

[0114] As shown in FIG. 10, a computer system 1000 in the form of a data processing system includes one or more buses 1050 coupled to a processing system 1020, a power supply 1025, a memory 1030, and a non-volatile memory 1040 (e.g., a hard drive, flash memory, phase change memory (PCM), etc.). The bus(es) 1050 can be interconnected with each other via various bridges, controllers, and / or adapters as is well known in the art. The processing system 1020 can obtain instructions from the memory 1030 and / or the non-volatile memory 1040 and execute instructions for performing operations as described above. The bus 1050 integrally interconnects the above components and also interconnects those components to an optional dock 1060, a display controller and a display device 1070, an input / output device 1080 (e.g., a NIC (network interface card), cursor control (e.g., a mouse, touch screen, touch pad, etc.), a keyboard, etc.) and an optional wireless transceiver(s) 1090 (e.g., Bluetooth, WiFi, infrared, etc.).

[0115] FIG. 11 is a block diagram illustrating an exemplary data processing system that may be used in some embodiments of the present invention. For example, data processing system 190 can be a handheld computer, a personal digital assistant (PDA), a cellular phone, a portable game system, a portable media player, a tablet, or a handheld computing device that can include a cellular phone, a media player, and / or a game system. As another example, data processing system 1100 can be an embedded processing device within a network computer or another device.

[0116] According to one embodiment of the present invention, an exemplary architecture of data processing system 1100 can be used for the portable devices described above. Data processing system 1100 includes a processing system 1120 that can include one or more microprocessors and / or systems on an integrated circuit. Processing system 1120 is coupled to a memory 1110, a power supply 1125 (including one or more batteries), an audio input / output 1140, a display controller and display device 1160, an optional input / output 1150, an input device(s) 1170, and a wireless transceiver(s) 1130. Additional components not shown in FIG. 11 may also be part of data processing system 1100 in certain embodiments of the present invention, and it will be understood that in certain embodiments of the present invention, fewer components than those shown in FIG. 11 may be used. Further, it will be understood that one or more buses not shown in FIG. 11 can be used to interconnect the various components as is well known in the art.

[0117] Memory 1110 can store data and / or programs for execution by data processing system 1100. Audio input / output 1140 can include, for example, a microphone and / or speaker for playing music, and / or can provide a telephone function via the speaker and microphone. Display controller and display device 1160 can include a graphical user interface (GUI). A wireless (e.g., RF) transceiver 1130 (e.g., a WiFi transceiver, an infrared transceiver, a Bluetooth transceiver, a wireless cellular phone transceiver, etc.) can be used to communicate with other data processing systems. One or more input devices 1170 enable a user to provide input to the system. These input devices can be a keypad, a keyboard, a touch panel, a multi-touch panel, etc. Optional other input / output 1150 can be a dock connector. Apparatus and method for preventing program code injection

[0118] Existing web integrity protection methods such as content security policy (CSP) and subresource integrity (SRI) can protect the integrity of external elements referenced by the main hypertext markup language (HTML) page. However, they only work if supported by the client, and the main HTML page was not subject to a man-in-the-middle (MITM) attack during loading. Existing protection techniques such as public key pinning, certificate transparency, and further token binding do not provide complete protection against such attacks.

[0119] When submitting a FIDO / Web Authentication response, techniques such as token binding are required, which allows the server to verify that the resulting authentication session will be owned by the client connected to the authenticator and not by some third party such as a MITM attacker.

[0120] Malicious JavaScript is often injected as a result of a man-in-the-middle attack, which causes the browser to fetch a modified resource from a malicious server instead when it tries to fetch a resource from a specific URL. Figure 12 shows an example where MITM 1211 intercepts the communication between client / browser 1210 and server 1212.

[0121] The browser uses the Domain Name Service (DNS) to resolve the server name to an IP address, uses Transport Layer Security (TLS) to authenticate the server, and encrypts the traffic exchanged between the client and the server. The server is authenticated using a TLS server certificate issued by a trusted TLS Certificate Authority (CA) from the client. Unfortunately, TLS CAs may issue certificates maliciously to attackers, and sometimes attackers may be able to obtain the TLS certificate private key of the relying party. For example, as shown in Figure 12, MITM 1211 may use a maliciously issued certificate for server.com, or a certificate and private key stolen from server.com.

[0122] Public key pinning is designed to protect against maliciously issued TLS server certificates, but has some drawbacks and has not yet been widely adopted. To address these drawbacks, certificate transparency has been proposed, but it is not yet widely supported and has some weaknesses.

[0123] In contrast to public key pinning (PKP) and certificate transparency (CT), the token binding approach enables the server to learn whether the client is communicating with the correct entity. In the case of PKP and CT, the server has to trust the client that implements support for that approach. Unfortunately, token binding alone is not sufficient to effectively provide MITM protection. For example, a typical web page contains JavaScript code from potentially multiple sources (e.g., Google's IMA SDK, Google Analytics, etc.), and the token binding data is only checked when receiving the authentication response. Access to the sign-in page is always possible without user authentication.

[0124] FIDO and Web Authentication provide an easy and secure way to authenticate users in web environments (and other environments). The Web Authentication specification includes support for token binding (RFC8471) to add robust protection against the export and replay of security / session tokens by man-in-the-middle (MITM) attackers.

[0125] Figure 13 is a diagram showing the sequence of a typical web site load process. When the client selects a link to server 1311, it loads the main HTML file. Then, the main JavaScript file is loaded. Next, the client sends an authentication response, and the server returns protected (e.g., data accessible only if authentication is successful) content.

[0126] In reality, a typical web page consists of more than two elements loaded by client 1310. There is only one piece of token binding data included in the Web Authentication assertion, which is related to the connection when sending the authentication response.

[0127] As shown in Figure 14, this means that when loading the main HTML file or when loading the main JS file (both when the unauthenticated client is available), the MITM 1412 attack is not detected by server 1311 when verifying the token binding data in the web authentication response. As a result, the attacker can inject malicious JavaScript code and / or tamper with potential integrity protection policies.

[0128] The risk of loading tampered external objects has been identified by the web application security community, and two main approaches have been developed for these types of attacks.

[0129] One approach is Subresource Integrity (SRI), which enables the specification of the expected hash value for external resources within HTML code using the "integrity" attribute. Under the assumption that the main web page is loaded without being tampered with, SRI gives the browser the possibility to reject and notify the server if the subresources required by this web page are loaded after being tampered with. Currently, many browsers support SRI. Unfortunately, there is no secure way for client 1310 to notify server 1311 about the implemented SRI support, and there is also no way for client 1310 to notify server 1311 about the received SRI "integrity" attribute when loading the main HTML page. The reason is that malicious JavaScript can always trigger the same notification call. As a result, the MITM attacker 1412 can modify the SRI "integrity" attribute when loading the main HTML page.

[0130] Another approach is the Content Security Policy (CSP), which is specified in the HTTP header and allows the relying party to specify a list of trusted sources for external objects such as Javascript code. It is also possible to specify hash values of such code. Unfortunately, no method is provided to protect against a MITM attack on the policy itself. If the loading of the main HTML file is already the target of a MITM attack, the content security policy may be maliciously weakened. Additional weaknesses in CSP have also been revealed.

[0131] A generally disadvantage of CSP, SRI, and similar approaches is that the server 1311 cannot learn (1) whether the client 1310 actually supports these concepts and verifies the content, and (2) whether the fetched main web page (potentially fetched via MITM1412) contains the correct integrity protection policy.

[0132] Note that even when the client loads the main HTML page with full CSP and SRI support, token binding support is still required for web authentication to provide robust MITM protection. Referring to FIG. 15, when MITM 1512 targets the transmission of the authentication response from client 1310, MITM 1512 will then own the authenticated session. Such an attack does not rely on modified HTML code, modified CSP or SRI policies, or modified JS code. DNS poisoning and access to the private key of the stolen TLS server certificate (if there is certificate transparency support) or access to a TLS server certificate maliciously issued to MITM 1412 for the server's domain (if there is no certificate transparency support) is sufficient. Unfortunately, token binding support in web browsers is rare. As a result, it is not currently realistic to reach authentication assurance levels such as AAL3 (NIST 800-63) in web applications.

[0133] A further challenge for entities that require high security is that they usually must be able to control the computing environment as much as possible. This also means that the (uncompromised) client 1310 needs to recognize whether security measures are implemented, and they usually require a contractual relationship with all parties involved. It seems rather unrealistic to conclude bilateral contracts with each TLS certificate authority or browser vendor that defines an acceptable list of TLS certificate authorities.

[0134] Referring to FIG. 16, to address these limitations, one embodiment of server 1611 includes a client evaluator 1650 for evaluating the security characteristics of dynamically loaded code executed at client 1610. One embodiment implements the following countermeasures to address the above limitations. First, client evaluator 1650 determines the integrity protection means supported by client 1610. In addition, web page evaluator 1652 determines the integrity protection policy (e.g., CSP or SRI) imposed by the web page and evaluates the web page to determine whether the web page has been tampered with. In addition, the web page evaluator is provided with access to and / or can determine the hash values of all external objects associated with the web page, which is relevant in the absence of CSP and SRI support.

[0135] One embodiment implements token binding support that enables server 1611 to verify whether an authentication response was received directly from client 1610, which includes authentication unit 1630, or indirectly via some form of MITM. Here, details of client 1610 and server 1611 are provided in accordance with embodiments of the present invention. I. Client 1610

[0136] One embodiment of the authentication engine 1613 of client 1610 includes an extension to a token binding extension that includes a web authentication data (WAD) dictionary 1620 (e.g., the CollectedClientData dictionary within an existing web authentication specification) or a list of supported integrity protection features 1620A and associated version numbers (e.g., CSP, SRI, certificate transparency, token binding, etc.). In addition, one embodiment of WAD dictionary 1620 includes a list of resource descriptors 1620B associated with the loading of a web page, where each resource descriptor includes one or more of the following elements. a. A sequence number related to the processing order of the corresponding resource. For example, the main HTML page can have a sequence number of 1, and the first external resource to be processed will have a sequence number of 2. b. The URL where the resource was loaded (e.g., "https: / / www.rp.com / index.html", "https: / / panopticum.com / tracker.js", etc.). c. The hash value of potential integrity policy instructions included in the HTTP header (e.g., of the CSP policy). d. The type of the element associated with the resource (e.g., Javascript, HTML, image, WebAssembly, etc.). e. The actual hash of the entire element / file calculated by the client, including from the first byte to the last byte. f. The expected hash of the element (e.g., as specified using the SRI "integrity" attribute). g. The list of code descriptors 1620C can also potentially include, for each resource descriptor 1620B, one entry for each JavaScript / WebAssembly code fragment within this object, each of which can include one or more of the following elements. 1. The actual hash of the element calculated by the client (e.g.: <script>タグと< / script> The hash of the actual code between tags, or the entire code string if assigned to an attribute). 2. The tag is associated with each code fragment. (For example, if the code is included in a script tag, such tags as "script", "body", "frame", "img", "input", etc., and the code is included in the attributes of such tags). 3. The "ID" related to the tag when the tag is specified. 4. The related attribute when the code is specified with such an attribute (e.g., the "onload" attribute, the "onclick" attribute, etc.).

[0137] In one embodiment, all code loaded in the context of the web page is included for evaluation by the authentication engine 1613 and the server-side authentication engine 1650. For example, it may include all HTML elements and code fragments processed (but not necessarily executed) at the time of a "get" / "create" call. Sometimes, code may be loaded dynamically, such as when the user clicks on an element. In one embodiment, such code fragments are only included if they were loaded at the time of a "get" / "create" call.

[0138] In some cases, existing JavaScript code dynamically adds new JavaScript code elements, and these dynamically added elements are also included as entries in the list of code descriptors 1620C. These code descriptors for code dynamically generated on the client side relate to a dedicated resource descriptor with an empty URL (since the resource was dynamically generated and not loaded directly from a remote source). II. SERVER 1611

[0139] As shown in FIG. 16, the authentication engine 1650 on the server 1611 can authenticate a client using any part of the extended WAD dictionary 1620 that includes integrity protection capabilities 1620A, resource descriptors 1620B, and / or code descriptors 1620C. The integrity protection capabilities 1620A can be evaluated by the client engine evaluator component 1651 of the authentication engine 1650, and the resource descriptors 1620B and code descriptors 1620C can be evaluated by the web page evaluator component 1652. For example, in one embodiment, the web page evaluator 1652 maintains a set of data related to the expected resource descriptor 1652B and the expected code descriptor 1652C. The authentication engine 1650 on the server 1611 can then compare the authentication data received from the client 1610 (e.g., a signature, hash value, etc. based on the resource descriptor 1620B and / or code descriptor 1620C) with its own data associated with the expected resource descriptor 1652B and code descriptor 1652C. Entities interested in this additional security layer can implement different approaches to verify the accuracy of the loaded (JavaScript) code.

[0140] When the authentication engine 1650 on the server 1611 implements a "strict" approach, all expected entries of the resource descriptors 1620B and code descriptors 1620C can be determined and compared. The Javascript code can be restricted to a well-defined number of external files with a given hash value. This approach can be implemented by entities with high security requirements and by servers that implement the specification in a straightforward manner.

[0141] The machine learning approach is used in one embodiment of the authentication engine 1650. For example, a machine learning-based authentication engine 1650 may check for support of integrity protection measurements 1620A, check the integrity of integrity protection policy instructions associated with those measurements, and / or check whether pairs of file names and associated hash values in the list of code descriptors 1620C occur for the first time or very rarely (e.g., this may indicate a spear phishing attack). These situations may be processed in a manner similar to the analysis of virus patterns by current antivirus scanners. That is, the transaction is flagged as "high risk," triggering the authentication engine to implement additional protective measures.

[0142] One advantage of the above is that this approach does not penalize / harm relying parties who are not interested in such a level of security. These relying parties will simply ignore the additional data elements. These embodiments are also compatible with current web practices such as loading third-party Javascript code from other URLs. These third parties do not need to add code signatures or modify their code. Relying parties that require a high level of security can use the above embodiments and perform rigorous checks limited to applications / web pages that require such a level of protection.

[0143] Relying parties interested in the machine learning-based approach can still utilize existing third-party Javascript modules without expecting additional security levels to be implemented by partners in such an ecosystem. The expected hash values of such modules do not need to be directly included in the file (and thus require dynamic generation). Instead, verification can be performed by the FIDO server when verifying the authentication response.

[0144] This approach is also compatible with dynamically generated HTML because it does not require validating the entire (potentially dynamically generated) HTML object. If unmodified JavaScript is executed, the security - related parts of the resulting Document Object Model (DOM) tree can be dynamically verified by the JavaScript.

[0145] The approach described above also leverages the cryptographic signature feature of the authentication unit 1613 of the client 1610. This is a way for the client 1610 to provide the server 1611 with proof of which web pages were loaded and rendered (since the client itself does not have a cryptographic secret that can be used to authenticate any information returned for providing to the server).

[0146] This approach also takes privacy into account. The additional data elements do not contain the user's personal information or personally identifiable information. They contain only data related to the content of the loaded web page. No additional data elements are displayed on those web pages that do not require user authentication, and those web pages that require user authentication can use additional data elements to verify the integrity of the loaded web page.

[0147] One embodiment of the present invention includes a tool that periodically analyzes a web page given a set of sign - in URLs, creates a list of expected code fragments and their hash values, and creates a proposed Content Security Policy (CSP).

[0148] In one embodiment, a repository of known - good JavaScript URLs and hash values is provided first. Code fragments and values that appear on the Internet can be synchronized with this repository to maintain a "known - good" state. One embodiment includes JavaScript code that verifies the security - related parts of the Document Object Model based on the web page that is periodically analyzed.

[0149] In one embodiment, the JavaScript SecureLoad function is provided in the form of a Software Development Kit (SDK). This SecureLoad function verifies the loaded object against the expected hash value provided as a parameter. Such a function simplifies a secure approach for dynamically loading external resources (e.g., images, text, JS, ...) using JavaScript functions.

[0150] These embodiments of the present invention can also be extended to other areas where the client device is assumed to be secure and does not directly support authentication. The client device is also assumed to have access to a module / device (such as a FIDO authentication unit or TPM) that can generate encryption assertions and enable the execution of any code loaded from various sources that may potentially be infected / modified. An example is an IoT device that supports the execution of custom code.

[0151] One embodiment of the present invention includes a client having a web browser or other software that loads content and program code from a web server or other external entity. The client / browser interfaces with a trusted entity that can sign an encryption assertion (e.g., a FIDO authentication unit) that includes one or more resource descriptor 1620B and / or code descriptor 1620C objects in an encryption calculation. For example, one embodiment includes the encrypted hash value of such resource descriptor(s) / code descriptor(s) within the object to be signed.

[0152] In addition, one embodiment includes a server-side component such as a FIDO server that verifies the encryption assertion and verifies that the encryption assertion contains only those resource descriptors 1620B and / or code descriptors 1620C specified as the expected resource descriptors. The authentication engine can return a risk score indicating the likelihood that malicious resource descriptors and / or code descriptors have been found.

[0153] In one embodiment, a server-side software component such as an authentication engine 1650 (e.g., a FIDO server) verifies an encrypted assertion, and verifies that the encrypted assertion contains only resource descriptor(s) / code descriptor(s) that the server has already seen multiple times from a previously trusted location (e.g., using machine learning to determine what "multiple times" is and what "trusted location" is). The software component may return a risk score indicating the likelihood that a malicious resource descriptor / code descriptor has been found.

[0154] One embodiment of the present invention includes a software tool that loads a relevant web page via an internal channel protected from MITM attacks (e.g., those used for sign-in) and learns what resources and code fragments are normally used. This software tool automatically supplies a database that clarifies the relevant source code in addition to the expected resource descriptor / expected code descriptor for web sites that can be used by the server-side authentication engine.

[0155] A JavaScript function can be included in a web site executed by a client to verify that security-related parts of the DOM tree have not been modified by an attacker (e.g., whether the "Buy Now" button still exists and is the only element with a given ID, whether elements indicating the content of a transaction exist in the DOM tree and are visible to the user, whether dynamically generated JavaScript code follows a specific pattern, etc.). Any of the above techniques can be used to verify JavaScript code.

[0156] In one embodiment, a feedback function is implemented in the server-side authentication engine, which updates the resource descriptor / code descriptor of the JavaScript code found to be malicious on the web to a central server that maintains a list of malicious resource descriptors / code descriptors.

[0157] In one embodiment, it includes a software tool that analyzes a list of malicious resource descriptors / code descriptors (e.g., collected as described above) to create a "pattern" that can help identify similar (i.e., not exactly the same) code fragments (e.g., a portion of a rendered internal variable, a slight modification of an internal order or structure, etc.). The software tool can analyze the list of resource descriptors / code descriptors, load the source code related to a given URL into those resource descriptors / code descriptors, and verify whether such code matches one or more patterns.

[0158] One embodiment also includes a software SDK that enables safely loading external resources such as images, text, or code (e.g., Javascript, WebAssembly,... etc.). This SDK receives a URL and the expected hash value of its resource. Alternatively or in addition, the SDK receives a URL and a trust anchor (e.g., a signature certificate, the code of a CA certificate, or a root certificate) to verify the code signature of the loaded external resource.

[0159] As described above, embodiments of the present invention may include various steps. The steps may be embodied in machine-executable instructions that cause a general-purpose or special-purpose processor to execute specific steps. Alternatively, these steps can be executed by specific hardware components that include hardwired logic for executing the steps, or by any combination of programmed computer components and custom hardware components.

[0160] The elements of the present invention can also be provided as a machine-readable medium storing machine-executable program code. Examples of the machine-readable medium include, but are not limited to, floppy disks, optical disks, CD-ROMs, magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, or other types of media / machine-readable media suitable for storing electronic program code.

[0161] Throughout the above description, for purposes of explanation, numerous specific details have been set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that the present invention may be practiced without some of these specific details. For example, it will be readily apparent to those skilled in the art that the functional modules and methods described herein may be implemented as software, hardware, or any combination thereof. Further, although some embodiments of the present invention are described herein in the context of a mobile computing environment, the basic principles of the present invention are not limited to mobile computing implementations. Substantially any type of client or peer data processing device can be used in some embodiments, including, for example, desktop or workstation computers. Accordingly, the scope and spirit of the present invention should be determined from the perspective of the following claims.

[0162] As described above, embodiments of the present invention may include various operations. The operations may be embodied in machine-executable instructions that cause a general purpose or special purpose processor to perform the particular operations. Alternatively, these operations may be performed by specific hardware components that include hardwired logic for performing the operations, or by any combination of programmed computer components and custom hardware components.

Claims

Claim 1 An apparatus comprising: a processor that executes an application to access a web page on the Internet in response to a user input, wherein the web page has one or more resource descriptors and / or code descriptors associated with the one or more resource descriptors; an authentication engine that verifies the web page at least partially based on the one or more resource descriptors and / or code descriptors by connecting to a trusted entity; wherein the trusted entity is configured to generate a signature for an encrypted assertion using a first key of the trusted entity, the encrypted assertion being generated by the authentication engine based on the web page, the encrypted assertion including one or more resource descriptor objects associated with the one or more resource descriptors and / or one or more code descriptor objects associated with the one or more code descriptors; using a second key of the trusted entity corresponding to the first key, comparing data in the encrypted assertion with data associated with one or more expected resource descriptors and / or one or more expected code descriptors of the web page, and verifying the signature to at least partially verify the web page; the apparatus wherein the web page is verified by using machine learning to verify that the encrypted assertion includes only determined previously observed resource descriptors and / or code descriptors from a set of determined trusted locations, the machine learning being to be executed to continuously update the set of determined previously observed times and the set of trusted locations. Claim 2 The apparatus according to claim 1, wherein the signature includes an encrypted hash value of the one or more resource descriptors and / or code descriptors. Claim 3 The apparatus according to claim 1, wherein the server-side authentication engine performs verification of the encrypted assertion, including verification that the encrypted assertion includes only one or more resource descriptors and / or code descriptors designated as expected resource descriptors and / or code descriptors. Claim 4 The apparatus according to claim 3, wherein the server-side authentication engine generates, as a response, a risk score indicating the possibility that a malicious resource descriptor and / or code descriptor has been identified.

5. The apparatus according to claim 1, wherein the processor executes program code including functions included in the web page to verify that one or more security-related parts of a Document Object Model (DOM) tree have not been modified, and the program code is verified using the signature.

6. A server device, an interface for receiving an authentication request from a client that has received a web page, the authentication request including an encrypted assertion generated beyond an encrypted assertion using a first key, and one or more resource descriptor objects associated with one or more resource descriptors of the web page and / or one or more code descriptor objects associated with one or more code descriptors of the web page, a storage device for storing one or more expected resource descriptors and / or one or more expected code descriptors associated with the web page, an authentication engine that uses a second key corresponding to the first key to compare the data in the encrypted assertion with the data associated with the web page and the associated one or more expected resource descriptors and / or one or more expected code descriptors, and verifies the signature to at least partially verify the web page, The server device, wherein the web page is verified by using machine learning to verify that the encrypted assertion includes only resource descriptors and / or code descriptors that have been previously observed a determined number of times from a determined set of trusted locations, and the machine learning is to be executed to continuously update the determined number of times and the set of trusted locations.

7. The server device according to claim 6, wherein the signature includes an encrypted hash value of the one or more resource descriptors and / or code descriptors.

8. The authentication engine is configured to perform verification of the encrypted assertion, including verification that the encrypted assertion contains only one or more resource descriptors and / or code descriptors specified as the expected resource descriptor and / or code descriptor. The server device according to claim 6.

9. The authentication engine generates, as a response, a risk score indicating the possibility that malicious resource descriptors and / or code descriptors have been identified. The server device according to claim 8.

10. The client includes a processor that executes program code including functions included in the web page to verify that one or more security-related portions of the Document Object Model (DOM) tree have not been modified, and the program code is verified using the signature. The server device according to claim 6.

11. A method comprising: Receiving an authentication request from a client that has received a web page; Identifying a signature generated on an encrypted assertion using a first key, the encrypted assertion being generated by the client based on the web page, the encrypted assertion including one or more resource descriptor objects associated with one or more resource descriptors of the web page and / or one or more code descriptor objects associated with the one or more code descriptors of the web page; Identifying and storing one or more expected resource descriptors and / or one or more expected code descriptors at least partially associated with the web page; Using a second key corresponding to the first key, comparing the data in the encrypted assertion with data associated with one or more expected resource descriptors and / or one or more expected code descriptors associated with the web page, and verifying the web page by verifying the signature; The web page is verified by using machine learning to verify that the encrypted assertion contains only resource descriptors and / or code descriptors that have been previously observed a determined number of times from a determined set of trusted locations, and the machine learning is to be executed to continuously update the determined number of times and the set of trusted locations. A method.

12. The method according to claim 11, wherein the signature includes an encrypted hash value of the one or more resource descriptors and / or code descriptors.

13. The method according to claim 11, further comprising verifying that the encrypted assertion includes only one or more resource descriptors and / or code descriptors specified as expected resource descriptors and / or code descriptors.

14. The method according to claim 13, further comprising generating a risk score indicating a likelihood that a malicious resource descriptor and / or code descriptor has been identified.

15. The method according to claim 11, wherein the client comprises a processor that executes program code including functions included in the web page to verify that one or more security-related portions of a document object model (DOM) tree have not been modified, and the program code is verified using the signature.

Images