(19) TEPZZ _6499B_T (11) EP 2 16 499 B1 (12) EUROPEAN PATENT SPECIFICATION (4) Date of publication and mention of the grant of the patent:.01.13 Bulletin 13/0 (21) Application number: 08762948.1 (22) Date of filing: 23.06.08 (1) Int Cl.: H04L 29/06 (06.01) G06F 21/00 (13.01) (86) International application number: PCT/IB08/001637 (87) International publication number: WO 09/001197 (31.12.08 Gazette 09/01) (4) A METHOD OF PREVENTING WEB BROWSER EXTENSIONS FROM HIJACKING USER INFORMATION VERFAHREN ZUR VERHINDERUNG, DASS WEB-BROWSER-ERWEITERUNGEN BENUTZERINFORMATIONEN STEHLEN PROCÉDÉ POUR EMPÊCHER DES EXTENSIONS DE NAVIGATEUR WEB À PARTIR DE PIRATAGE D INFORMATIONS D UTILISATEUR (84) Designated Contracting States: AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MT NL NO PL PT RO SE SI SK TR () Priority: 22.06.07 US 948 P (43) Date of publication of application: 24.03. Bulletin /12 (73) Proprietor: Gemalto SA 92197 Meudon Cedex (FR) (72) Inventors: LU, HongQian Karen F-92197 Meudon Cedex (FR) SACHDEVA, Kapil F-92197 Meudon Cedex (FR) ASAD, ALI F-92197 Meudon Cedex (FR) (74) Representative: Wlodarczyk, Lukasz Georges Kazimierz Gemalto SA Intellectual Property Department 6, rue de la Verrerie 92197 Meudon Cedex (FR) (6) References cited: WO-A-06/131897 US-A1-0 071 282 US-A1-06 294 023 URIEN P: "Internet card, a smart card as a true Internet node" COMPUTER COMMUNICATIONS, ELSEVIER SCIENCE PUBLISHERS BV, AMSTERDAM, NL, vol. 23, no. 17, 1 November 00 (00-11-01), pages 16-1666, XP004238469 ISSN: 01-3664 EP 2 16 499 B1 Note: Within nine months of the publication of the mention of the grant of the European patent in the European Patent Bulletin, any person may give notice to the European Patent Office of opposition to that patent, in accordance with the Implementing Regulations. Notice of opposition shall not be deemed to have been filed until the opposition fee has been paid. (Art. 99(1) European Patent Convention). Printed by Jouve, 7001 PARIS (FR)
Description 2 3 4 0 [0001] The invention relates to portable authentication tokens, systems comprising tokens, computers and servers, and methods for authenticating a user to a server with a token. [0002] Patent application US062923 discloses a portable secure network device and a method to operate such a device to provide secure login, secure online transactions, and to prevent online identity theft. An embodiment of the invention may be constructed by inserting a network smart card into a card reader, wherein either the card reader or the card itself has an output device and input device wherein the processor is programmed to execute according to instructions to cause the microprocessor: to produce a shared association secret; to display the shared association secret on the output device; and to transmit the shared association secret to the remote server; thereby ensuring that a user observing the output device and the remote server computer both possess the shared association secret. [0003] Patent application US0071282 discloses a system and a method for effecting secure transactions over a computer network in a manner designed to foil identity theft perpetrated from an untrusted computer. A connection from a client computer to the network wherein the client computer provides a user interface for a user, a connection from a server computer to the network, and a connection from a portable secure computing device to the network provides for secure transmission of private confidential user information from the user to a server. The private information is transmitted directly from the secure computing device to the server over the secure connection without possibility of capture on the computer with which the user is interacting. [0004] Patent Application W006/131897 discloses a network smart card used to connect seamlessly to a remote server and to provide login credentials of a user to said remote server. Non-patent literature document titled "Internet card, a smart card as a true Internet node" from P.Urien, also discloses an Internet smart card used to authenticate a user to a remote server. [000] In recent years the Internet and its usage have been rapidly expanding. Unfortunately online identity thefts and frauds are on the rise as well. Adversaries have found many different ways to steal online identities. Various spywares invade computers without users knowledge through email attachments or via a web page visited by the user. The attack techniques are becoming so sophisticated that even the tech-savvy users can become victims of online identity theft. To protect consumers and service providers, many software and hardware solutions have been proposed or developed. These methods in general enhance online authentications, but they implicitly assume that the web browser, the most prevalent tool for online activities, is secure. Unfortunately a malicious. Browser Helper Object (BHO), or in general a malicious browser extension, can break this assumption readily. Certain malicious BHOs can monitor or parse information passing through the browser, and steal or change such information. For example, some BHO could capture the usemame/ password embedded in a web login form, or change the destination URL to a malicious one. [0006] On personal computers running the Microsoft Windows operating systems, BHOs typically consist of a DLL which needs to be registered in the windows registry. In order to be installed on a computer, BHOs typically require administrative privilege on this computer. Therefore a hacker is not necessarily able to install it. But if the BHO masquerades as a legitimate tool, such as a popup blocker tool, the user may download it and install it himself, while in reality it is a rogue tool. Unfortunately, many BHOs are security tools and the user may be inclined to trust them. For example, There are various web browser extensions that help users to manage their passwords or to detect spoofed sites. Examples include PwdHash and PassPet. PwdHash is described in Ross, B., Jackson, C., Miyake, N., Boneh, D, and Mitchell, J.C., "Stronger Password Authentication Using Browser Extensions," USENIX Security Symposium 0, http://crypto-stanford.edu/pwdhash/pwdhash.pdf. PwdHash captures the user input to the password field, computes a hash value from the user password and the site domain name, and sends the hash value instead of the password. PassPet is described in Yee, K. and Sitaker, K, http://passpet.org/. PassPet generates a user password from user s master address, master secret, and site label, and fills in the password automatical when the user logs in to the site. It generates a different password for each site and the user does not need to know or remember them. However the automatically generated password or password hash is still in the web login form in the browser, and can be accessed by another, malicious, BHO. [0007] Different techniques have been devised to secure the authentication of a user to a server, however such techniques are prone to attack by rogue BHOs. [0008] On known technique consists of smart cards, which have been used to provide two factor authentications for Internet applications. The smart card may store the user s login credentials inside the card. Such cards may use middleware running on the PC to first authenticate a user through his PIN, and then get his account credentials for a selected site. The username and password may be automatically inserted into a form, which is then submitted to the remote server. One example is ID Vault from GuardID Systems, http://www.guardidsystems.com. The ID Vault requires client software and browser plug-ins installed on the user s computer. This kind of form filling method thwarts keystroke loggers, enables the user to create strong passwords, and is convenient to use. A smart card-based token is typically more secure than other flash memory based tokens due to the inherent security of smart card chips. However, the form filling approach itself leaves the login information in an unencrypted form in the web browser before being sent. The attacker 2
2 3 4 may hack the browser via a malicious BHO and steal the information. The method is also vulnerable to Phishing and Pharming attacks. [0009] Biometrics has also been used for user authentications. It brings in the third factor: who you are. One popular product is Microsoft s fingerprint reader with password saver described in "Microsoft Fingerprint Reader", http://www.microsoft.com/hardware/mouseandkeyboard/features/fingerprint.mspx. The user registers his usernames and passwords by entering them to his computer and swiping his finger through the fingerprint reader. The login credentials are stored on the user s computer. To login, the user selects the website and wipes his finger through the reader. The client software automatically fills up the login web form. From the security perspective, it is as vulnerable as other form fill methods, giving malicious BHOs opportunities to steal the information. [00] Another known technique is based on a portable authentication token known as the Network Identity Module (NIM). [0011] A known Network Identity Manager (NIM) consists of a smart card-based USB token. It provides a strong twofactor mutual authentication solution, which enables a user to login to remote servers. A NIM has a local agent (called card agent when the NIM is a smart card) and a host agent, as explained in particular in A. Ali, K. Lu, A. Vassilev and E. Dolph, "A Method of Using Smart Card Devices without Requiring Smart Card Infrastructure", US/788,0. Both agents reside on the smart card. The host agent runs on the host computer (for example, it may be visible on the PC through a mass storage interface which make the host agent appear to the PC just like an executable file on a CD ROM) while the card agent runs inside the card. [0012] For desktop applications, NIM is typically a USB token. The user plugs his NIM token into a USB port of a PC in order to use it. [0013] In the NIM, the host agent typically comprises a web server, NIM applications, and a web agent. The NIM web server may be accessible through an URL such as https://localhost:4116, which enables the user to access NIM and its services through a standard web browser on his PC. NIM applications provide services such as token registration, PIN management, and user authentication to remote websites. The web agent may connect to remote websites as a client to authenticate the sites legitimacy. [0014] The NIM typically stores confidential data of its holder - such as private keys and user login credentials - in its internal secure file system. The card agent runs inside the smart card and can access these private data. It also provides cryptographic functionalities related to the data. The card agent provides services to the host agent, for example, to validate the user PIN and to provide encrypted user login credential. [00] For secure login to a remote server, the NIM typically encrypts the user s login credential and some other information using the remote server s public key and signs the credential and the information using the NIM private key. The NIM may then send the resulting data blob to the remote server through the web browser, with which the user interacts. [0016] There are alternatives to the NIM, to which the invention applies as well, in particular TCP/IP smart cards that only have card software and do not rely on host software running on PC, or traditional smart cards that have embedded card software and rely on middleware (some sort of host agent) stored on the PC and running on PC. [0017] One problem with state of the art solution is therefore that they are extremely sensitive to attacks by rogue BHOs. For example, after a user enters his login credential (e.g. username and password) to the browser by typing in, via a hardware token, via a browser extension, or some other software, the browser sends the credential to the remote server. The server validates the credential and returns back a post-login page. However, if there is a malicious BHO in the browser, the BHO can intercept the user credential and send it to the attacker. The attacker now gets the user credential and can use it at least once or repeatedly. [0018] It is therefore an object of the invention to propose a token, a method and a system which make BHO attacks more difficult to carry out. The token according to claim 1, the method according to claim 12 and the system according to claim 29 solve this problem. [0019] The invention is advantageous, because for many malicious BHO, the "Post login page" comes back only to the original browser, and not to a client under the "Attacker" control. [00] The invention and its advantages will be explained more in details in the following specification referring to the appended drawings, in which: 0 Figure 1 represents a High level architecture of Network Access Card which is a type of NIM, Figure 2 represents an ideal login case in state of the art systems, that is a login which is not subject to an attack by a rogue BHO, Figure 3 represents how a BHO can intercept the login credential and sends them to an attacker with state of the art systems, Figure 4 is an overview of the out-of-band communication, Figure represents a normal remote server login operation using the NIM in an embodiment of the invention, Figure 6 represents one type of failed attack against the system according to the invention, based in rogue BHO, wherein the BHO intercepts the data blob from the browser, 3
Figure 7 represents a first variant of a second type of failed attack against the system according to the invention, based in rogue BHO, wherein the blob intercepted and sent by the attacker arrives first, Figure 8 represents a second variant of the second type of failed attack against the system according to the invention, based in rogue BHO, wherein the blob from the browser arrives first, Figure 9 shows a remote server login operation of an alternative embodiment of this invention, Figure depicts a failed attack against the alternative embodiment wherein the attacker s request is rejected because the blob and SAS were sent from different nodes. 2 [0021] In preferred embodiments, the authentication method provides secure online authentication by combining the credential protection method of Network Identity Manager (NIM) and a synchronized out-of-band communication to make it more difficult for malicious browser extensions to steal user information. The invention thwarts many online identity theft schemes, in particular currently existing malicious browser extension, keylogger, Trojan horse, Phishing, Pharming, password guessing, man-in-the-middle, eavesdropping, and replay attacks. [0022] For the convenience of the following descriptions, we assume a malicious browser extension is a Browser Helper Object (BHO). But the method applies to other browser extensions as well. NIM is used as an example. However, this method is not limited to the use of NIM. [0023] Preferred embodiments of the invention combine the NIM s credential protection method with an out-of-band communication to prevent malicious BHOs from stealing user information. The "out-of-band communication" generally refers to communication which bypasses the browser, since what happens in the browser is in general the easiest target for BHO attacks. Out-of-band communications are therefore outside the previously established communication method or channel. In the context invention, the user authentication is carried out through the browser, and the previously established communication channel is in particular between a web browser and a remote server. In preferred embodiments a direct end-to-end secure communication between NIM and the remote server is the "out-of-band" communication, and it does not flow through the web browser. [0024] The user typically interacts with his NIM token modified according to a preferred embodiment of the invention using a standard web browser on his computer. When the user wants to login to a remote server using NIM, the web browser sends a request to NIM. The NIM web server preferably generates a data blob using the user s login credential, an OTP value or some other counter or timestamp, and association data such as a shared association secret (SAS). The login credential may be username and password, or some other login information. The OTP, a counter, or a timestamp can prevent replay attack. The SAS is preferably randomly generated each time. The data blob may be generated by encrypting the data using the remote server s public key and signing the data using NIM s private key. The NIM token s certificate (which may be attached for easier retrieval by the server) lets the server validate the token signature. [002] The plaintext of the data blob may be: 3 4 0 [0026] The resulting Blob may then be represented as follows: (RSAencrypt(plaintext)remote_server_pub_key + RSAsign(plaintext)Token_priv_key + Token_Certificate} [0027] The NIM web server sends back a response containing the login data blob to the browser. With (or without) a user Interaction (mouse click), the browser redirects the data blob to the remote server. The remote server decrypts and validates the data blob. It also validates the user s login credential. To make it more difficult for a rogue BHO to simulate, that the data blob is sent from a computer to which the NIM is connected while it s not, the remote server preferably expects an out-of-band SAS. The NIM web server preferably established a secure SSL/TLS/IP SEC channel directly with the remote server and sends the SAS as illustrated in Figure 4. This is an out-of-band communication, which is outside of the normal communication channel between the web browser and the remote server. [0028] If the remote server finds that the SAS from a NIM token matches the one in a data blob, it grants the user login and returns a post-login page to the web browser. The remote server may, in addition, check if the SAS from a NIM and the corresponding data blob from a web browser are from the same network address. If these network addresses do not match the login request may be rejected (in some instances, matching addresses is not desirable, as will be seen below). All communications among NIM, the browser and the remote server are preferably secured using SSL/TLS. [0029] Through a malicious BHQ, the attacker might get the login data blob, but he cannot get the user s login credential from the blob if the plaintext was encrypted using the remote server s public key. It is harder for the attacker to do a replay attack because he does not know the SAS. [00] Figure illustrates the sequence of operations for remote server login operation according to a preferred embodiment of this invention. When the user wants to login to the remote server using NIM, the web browser sends a request to the NIM web server. The NIM server responds with a login blob as described earlier. The browser redirects 4
2 3 4 0 the blob to the remote server. [0031] In order to make it more difficult for a hacker to have the data blob sent from a browser of his choice, the remote server sends a partial response containing a JavaScript code to the browser of the user. This code loads a resource from the localhost:4116, which is the preferred URL of the NIM web server. When the partial response reaches the browser, the JavaScript interpreter sends a request to the NIM web server. The NIM server responds to the browser with an "empty" response. At the same time, NIM connects to the remote server directly via TLS connection and sends the same SAS as that in the data blob to the remote server. This is a direct connection between NIM and the remote server without going through the browser. A malicious BHO in the browser would have difficulties to intercept this outof-band communication, and cannot extract the contents of this out-of-band connection anyway. After the remote server receives the SAS, it finds the data blob with the same SAS. If the matching is successful and the remote server has validated the user s login credential, the server sends the rest of the post-login web page to the browser. [0032] Some web browsers, although unlikely, may have JavaScript disabled. In this case, the remote server s partial response can use the Image tag or other means of HTML to get a resource from localhost:4116 or whatever the URL of the NIM is. The remote server can detect if the client s JavaScript is enabled through various known mechanisms. For the partial response page, using JavaScript is advantageous because it can provide a richer and more intuitive user experience. [0033] Examples of attacks that are defeated by the invention are given below. Assume that there is a malicious BHO in the user s web browser. When NIM sends the login data blob to the browser, the BHO may redirects the blob to the attacker. The latter sends the blob to the remote server. If the remote server had not adopted the out-of-band method presented in this section, it would grant the login request as illustrated in Figure 3. With this invention, the remote server expects an out-of-band SAS sent directly from a NIM token. After receiving the data blob, the remote server sends a partial response requesting the NIM web server to send SAS. The attacker does not know the SAS and it is hard for him to devise an attack for sending back the correct SAS. Hence, the remote server wouldn t grant the login request (See Figure 6). [0034] Alternatively, the malicious BHO may let the login data blob be redirected by the browser to the remote server. The BHO may get its own copy of the blob and send it to the attacker. The latter, in turn, sends the blob to the remote server. The remote server would receive two identical login data blobs and must reject the second one. [003] Let s assume that the blob from the attacker arrives first. The remote server sends the partial response requesting the out-of-band SAS. The attacker does not have the SAS easily, hence the remote server denies the login request. The blob from the user s browser arrives later; the remote server rejects this second login request having an identical data blob as before (used blob), as illustrated on Figure 7. Once this behavior repeats, the user would probably guess that something is wrong. He should either remove malicious software from his computer or use another computer. [0036] Let s now assume that the blob from the user s browser arrives first. The remote server requests the out-ofband SAS. After matching SAS and validating the blob, the server grants the login request to the user s browser. On the other hand, the blob from the attacker arrives later. The remote server rejects this second login request with the identical blob (See Figure 8). [0037] Figure 9 illustrates the operations of an alternative embodiment of this invention for remote server login. When the user wants to login to the remote server using NIM, the web browser sends a request to the NIM web server. The NIM server responds with a login blob as described earlier. The browser redirects the blob to the remote server. The NIM server also establishes a secure and direct connection with the remote server, and sends SAS to the remote server. The remote server uses the received SAS to find the blob that contains the same SAS and makes sure they come from the same network address. If such a matching is found, the remote server grants the login request from the browser who sent the blob and returns a post-login page to the browser. If a login data blob does not have a matching SAS sent from a NIM directly or the blob and the out-of-band SAS come from different source, the remote server rejects the login request. [0038] A possible defeated attack against this alternative embodiment is as follow. Let s assume that there is a malicious BHO in the user s web browser. When NIM sends the login data blob to the browser, the BHO redirects the blob to the attacker. The latter sends the blob to the remote server. If the remote server had not adopted the out-of-band communication, it would grant the login request as illustrated in Figure 3. With the invention, the remote server expects an outof-band SAS sent directly from a NIM token. In this situation (Figure ), the blob and the SAS come from different network addresses. The remote server rejects the login request from the attacker. At the same time, the login request from the users browser would have probably expired (timeout). The user would know something is wrong, especially if this behavior repeats. He should either remove malicious software from his computer or use another computer. As described earlier, it s hard for the attacker to use the login data blob to gain access to Remote Server: [0039] Using the network address to ensure that the data blob and the SAS come from the same source is advantageous, because the attacker might forge the IP address. But it may cause some problems. With Network Address Translation (NAT) layer, firewalls, web proxies, anonymous proxies, and SSL/TLS, it is very difficult, if not impossible, for the attacker to find the final IP address of the payload that carries the login data blob. On the other hand, if the attacker
is an insider for example, in the same organization as the victim, the remote server might not be able to tell that the data blob and the SAS came from different source. If a user makes use of anonymous proxy services, the data blob and the SAS may end up with different IP addresses. In this case, the remote server could deny a legitimate user from login. [00] The user authentication means may further comprise at least one of the following user authentication techniques: regular password authentication, one Time Password authentication, Challenge Response authentication, Public Key Infrastructure authentication Claims 1. A portable authentication token comprising a. connection means for connecting to a computer, b. browser communication means for communicating with a browser running on the computer, c. user authentication means for authenticating a user of the token to a server, wherein the user authentication means are triggered via the browser communication means when the user connects to the server from the browser of the computer, wherein the user authentication means are set to authenticate the user by communicating with the server through the browser, wherein the portable authentication device further comprises out-of-band token communication means set to validate user authentication by establishing a communication channel between the token and the server, the communication channel bypassing the browser, characterized in that: 2 j the user authentication means are set: to send a data blob to the server through the browser, the data blob being signed by an asymmetric private key stored in the token and/or encrypted with an asymmetric public key of the server, the data blob comprising d. user identification data, e. authentication data, f. a token identifier, g. anti-replay data against replay attacks, and h. association data, 3 the out-of-band token communication means are set to send the same association data to the server. 2. The portable authentication token according to claim 1, wherein the browser communication means comprise a local agent and a host agent, wherein the local agent is set to be executed by the token while the host agent is set to be executed by the computer. 3. The portable authentication token according to claim 2, wherein the host agent comprises a web server. 4 4. The portable authentication token according to claim 2 or 3, wherein the communication channel comprises a connection between the local agent and the host agent, and a TCP/IP connection between the host agent and the server. 0. The portable authentication token according to any previous claim, wherein the out-of-band token communication, means are set to encrypt at least part of the communications with the server in order that only the server can decrypt said part. 6. The portable authentication token according to claim, wherein the communications between the token and the server comprise using an IPSEC, or an SSL, or a TLS protocol. 7. The portable authentication token according to claim 1, wherein association data are generated by the token and comprise a random number. 8. The portable authentication token according to any previous claim, wherein the user authentication means comprise at least one of the following user authentication techniques: regular password authentication, One Time Password 6
authentication, Challenge Response authentication, PKI authentication. 9. The portable authentication token according to any previous claim, wherein user identification data consist of a username, authentication data consist or a user password, and anti-replay data consist of a one time password and/or a counter and/or a timestamp.. The portable authentication token according to any previous claim, wherein the connection means comprise a USB connector. 11. The portable authentication token according to any previous claim, wherein the token is or comprises a smart card. 12. A method for authenticating a user to a server, the user connecting to the server from a browser running on a computer, the user being equipped with a portable authentication token, the token comprising 2 3 a. connection means for connecting to the computer, b. browser communication means for communicating with the browser, c. user authentication means for authenticating the user of the token to the server, wherein the user authentication means are triggered via the browser communication means when the user connects to the server, wherein the user authentication means are set to authenticate the user by communicating with the server through the browser, wherein the method further comprises validating the user authentication by establishing a communication channel between the token and the server, the communication channel bypassing the browser, characterized in that: j the user authentication means are set to send a data blob to the server through the browser, the data blob being signed by an asymmetric private key stored in the token and/or encrypted with an asymmetric public key of the server the data blow comprising d. user identification data, e. authentication data, f. a token identifier, g. anti-replay data against replay attacks, and h. association data, j the out-of-band token communication means are set to send the same association data to the server. 13. The method according to claim 12, wherein the browser communication means comprise a local agent and a host agent, wherein the local agent is set to be executed by the token while the host agent is set to be executed by the computer. 14. The method according to claim 13, wherein the host agent comprises a web server. 4. The method according to claim 13 or 14, wherein the communication channel comprises a connection between the local agent and the host agent, and a TCP/IP connection between the host agent and the server. 16. The method according to claim 12, wherein the token encrypts at least part of the communications on the communication channel, in order that only the server can decrypt said part. 0 17. The method according to claim 16, wherein the communications on the communication channel comprise using an IPSEC, an SSL or a TLS protocol. 18. The method according to claim 12, wherein association data are generated by the token and comprise a random number. 19. The method according to claim 12, wherein user authentication is triggered by the user, who, after connecting to the server, instructs the browser to authenticate him with the token. 7
. The method according to claim 12, wherein the user authentication is triggered automatically by the server, after the user connects to the server. 21. The method according to claim 12, wherein the token establishes the communication channel automatically after the user authentication means have authenticated the user to the server. 22. The method according to claim 12, wherein the token establishes the communication channel upon instruction of the server, after the server has authenticated the user with the user authentication means of the token. 23. The method according to claim 22, wherein the server instructs the token to establish the communication channel by sending a javascript code to the browser. 24. The method according to claim 12, wherein the user authentication means comprise at least one of the following user authentication techniques: regular password authentication, One Time Password authentication, Challenge Response authentication, PKI authentication. 2. The method according to claim 12, wherein user identification data consist of a username, authentication data consist of a user password, and anti-replay data consist of a one time password and/or a counter and/or a timestamp. 26. The method according to claim 12, wherein the data blob is signed by an asymmetric private key stored in the token and/or encrypted with an asymmetric public key of the server. 27. The method according to claim 12, wherein the connection means comprise a USB connector. 2 28. The method according to claim 12, wherein the token is or comprises a smart card. 29. A system comprising a portable authentication token, a server, and a computer running a browser, the token comprising 3 a. connection means for connecting to the computer, b. browser communication means for communicating with the browser, c. user authentication means for authenticating a user of the token to the server, wherein the user authentication means are triggered via the browser communication means when the user connects to the server from the browser of the computer, wherein the user authentication means are set to authenticate the user by communicating with the server through the browser, wherein the portable authentication device further comprises out-of-band token communication means set to validate user authentication by establishing a communication channel between the token and the server, the communication channel bypassing the browser, characterized in that: 4 0 j the user authentication means are set to send a data blob to the server through the browser, the data blob being signed by an asymmetric private key stored in the token and/or encrypted with an asymmetric public key of the server the data blob comprising d. user identification data, e. authentication data, f. a token identifier, g. anti-replay data against replay attacks, and h. association data, j the out-of-band token communication means are set to send the same association data to the server. Patentansprüche 1. Ein mobiles Security-Token zur Authentifizierung mit folgenden Mitteln: 8
a. Ein Mittel für den Anschluss an einen Rechner, b. Ein Browser-Mittel für die Kommunikation mit einem Browser auf dem Rechner, c. Ein Mittel zur Authentifizierung eines Benutzers des Tokens bei einem Server, wobei die Authentifizierungsmittel des Benutzers über das Browser-Kommunikationsmittel ausgelöst werden, wenn sich der Benutzer ab dem Browser des Rechners an den Server anschließt, wobei die Authentifizierungsmittel eines Benutzers so eingestellt sind, dass sie den Benutzer identifizieren, indem sie durch den Browser mit dem Server kommunizieren, wobei die mobile Authentifizierungsvorrichtung ferner Out-of-band Kommunikationsmittel des Tokens umfasst, die für die Bestätigung der Authentifizierung des Benutzers eingestellt sind, indem sie einen Kommunikationskanal zwischen dem Token und dem Server herstellen, wobei der Kommunikationskanal den Browser übergeht, dadurch gekennzeichnet, dass: Die Authentifizierungmittel des Benutzers so eingestellt sind, dass sie Datenmaterial durch den Browser an den Server schicken, wobei das Datenmaterial von einem im Token gespeicherten asymmetrischen privaten Schlüssel signiert und/oder mit einem asymmetrischen öffentlichen Schlüssel des Servers verschlüsselt wird, wobei das Datenmaterial folgendes umfasst d. Daten zur Identifizierung des Benutzers, e. Authentifizierungsdaten, f. Eine Identifikationsnummer des Tokens, g. Anti-Replay Daten gegen Replay-Angriffe, h. Assoziationsdaten, IrDA, 2 Die Out-of-band Kommunikationsmittel des Tokens sind so eingestellt, dass sie die gleichen IrDA an den Server schicken. 2. Das mobile Security-Token zur Authentifizierung nach Anspruch 1, dadurch gekennzeichnet, dass die Browser- Mittel für die Kommunikation ein lokales Prüfmittel und ein Host-Mittel umfassen, wobei das lokale Prüfmittel vom Rechner ausgeführt werden soll. 3. Das mobile Security-Token zur Authentifizierung nach Anspruch 2, dadurch gekennzeichnet, dass das Host-Mittel einen Webserver umfasst. 3 4. Das mobile Security-Token zur Authentifizierung nach Anspruch 2 oder 3, dadurch gekennzeichnet, dass der Kommunikationskanal eine Verbindung zwischen dem lokalen Prüfmittel und dem Host-Mittel umfasst und eine TCP/IP Verbindung zwischen dem Host-Mittel und dem Server.. Das mobile Security-Token zur Authentifizierung nach einem beliebigen der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Out-of-band Kommunikationsmittel so eingestellt sind, dass sie zumindest einen Teil der Kommunikationen mit dem Server verschlüsseln, so dass nur der Server den besagten Teil entschlüsseln kann. 4 6. Das mobile Security-Token zur Authentifizierung nach Anspruch, dadurch gekennzeichnet, dass die Kommunikationen zwischen dem Token und dem Server die Benutzung eines IPSEC oder eines SSL oder eines TLS Protokolls beinhalten. 7. Das mobile Security-Token zur Authentifizierung nach Anspruch 1, dadurch gekennzeichnet, dass IrDA vom Token erzeugt werden und eine beliebige Zahl beinhalten. 0 8. Das mobile Security-Token zur Authentifizierung nach einem beliebigen der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Authentifizierungsmittel eines Benutzers zumindest eine der nachstehenden Authentifizierungstechniken eines Benutzers beinhalten: regelmäßige Passwort-Authentifizierung, One-Time-Passwort Authentifizierung (OTP), Challenge-Response-Authentifizierung, PKI Authentifizierung. 9. Das mobile Security-Token zur Authentifizierung nach einem beliebigen der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Daten zur Benutzeridentifizierung aus einem Benutzerpasswort bestehen, die Authentifizierungsdaten bestehen aus einem Benutzerpasswort, und Anti-Replay Daten bestehen aus einem Einmalpasswort und/oder einem Zähler und /oder einem Zeitstempel. 9
. Das mobile Security-Token zur Authentifizierung nach einem beliebigen der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Verbindungsmittel einen USB-Verbinder umfassen. 11. Das mobile Security-Token zur Authentifizierung nach einem beliebigen der vorstehenden Ansprüche, dadurch gekennzeichnet, dass das Token eine Smartcard ist oder umfasst. 12. Ein Verfahren zur Authentifizierung eines Benutzers gegenüber einem Server, wobei sich der Benutzer über einen auf einem Rechner laufenden Browser an den Server anschließt, wobei der Benutzer mit einem mobilen, Security- Token ausgerüstet ist und das Token folgendes umfasst: a. Mittel für den Anschluss an den Rechner, b. Browser-Mittel für die Kommunikation mit dem Browser, c. Mittel zur Authentifizierung eines Benutzers des Tokens bei einem Server, wobei die Authentifizierungsmittel des Benutzers über das Browser-Kommunikationsmittel ausgelöst werden, wenn sich der Benutzer an den Server anschließt, wobei die Authentifizierungsmittel des Benutzers so eingestellt sind, dass sie den Benutzer identifizieren, indem sie durch den Browser mit dem Server kommunizieren, wobei das Verfahren ferner die Bestätigung der Authentifizierung des Benutzers durch die Herstellung eines Kommunikationskanals zwischen dem Token und dem Server umfasst, wobei der Kommunikationskanal den Browser übergeht, dadurch gekennzeichnet, dass: 2 Die Authentifizierungmittel so eingestellt sind, dass sie Datenmaterial durch den Browser an den Server schicken, wobei das Datenmaterial von einem im Token gespeicherten asymmetrischen privaten Schlüssel signiert und/oder mit einem asymmetrischen öffentlichen Schlüssel des Servers verschlüsselt wird, wobei das Datenmaterial folgendes umfasst d. Daten zur Identifizierung des Benutzers, e. Authentifizierungsdaten, f. eine Identifikationsnummer des Tokens, g. Anti-Replay Daten gegen Replay-Angriffe, h. Assoziationsdaten, IrDA 3 Die Out-of-band Kommunikationsmittel sind so eingestellt, dass sie die gleichen IrDA an den Server schicken. 13. Das Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass die Browser-Mittel für die Kommunikation ein lokales Prüfmittel und ein Host-Mittel umfassen, wobei das lokale Prüfmittel vom Token ausgeführt werden soll, während das Host-Mittel vom Rechner ausgeführt werden soll. 14. Das Verfahren nach Anspruch 13, dadurch gekennzeichnet, dass das Host-Mittel einen Webserver umfasst. 4. Das Verfahren nach Anspruch 13 oder 14, dadurch gekennzeichnet, dass der Kommunikationskanal eine Verbindung zwischen dem lokalen Prüfmittel und dem Host-Mittel umfasst und eine TCP/IP Verbindung zwischen dem Host-Mittel und dem Server. 0 16. Das Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass das Token zumindest einen Teil der Kommunikationen auf dem Kommunikationskanal verschlüsselt, so dass nur der Server den besagten Teil entschlüsseln kann. 17. Das Verfahren nach Anspruch 16, dadurch gekennzeichnet, dass die Kommunikationen auf dem Kommunikationskanal die Benutzung eines IPSEC, eines SSL oder eines TLS Protokolls beinhalten. 18. Das Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass IrDA vom Token erzeugt werden und eine beliebige Zahl beinhalten. 19. Das Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass die Authentifizierung eines Benutzers durch den Benutzer ausgelöst wird, der nach Anschluss an den Server den Browser anweist, ihn mit dem Token zu
authentifizieren.. Das Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass die Authentifizierung eines Benutzers automatisch durch den Server ausgelöst wird, nachdem der Benutzer sich an den Server anschließt. 21. Das Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass das Token den Kommunikationskanal automatisch erstellt, nachdem die Authentifizierungsmittel des Benutzers den Benutzer beim Server authentifiziert haben. 22. Das Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass das Token den Kommunikationskanal nach Anwendung des Servers erstellt, nachdem der Server den Benutzer mit dem Authentifizierungsmittel für den Benutzer des Tokens authentifiziert hat. 2 23. Das Verfahren nach Anspruch 22, dadurch gekennzeichnet, dass der Server das Token anweist, den Kommunikationskanal zu erstellen, indem er einen Javascript-Code an den Browser schickt. 24. Das Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass die Authentifizierungsmittel des Benutzers zumindest eine der nachstehenden Authentifizierungstechniken eines Benutzers beinhalten: regelmäßige Passwort- Authentifizierung, One-Time-Passwort Authentifizierung (OTP), Challenge-Response-Authentifizierung, PKI Authentifizierung. 2. Das Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass die Daten zur Benutzeridentifizierung aus einem Benutzernamen bestehen, die Authentifizierungsdaten bestehen aus einem Benutzerpasswort, und Anti-Replay Daten bestehen aus einem Einmalpasswort und/oder einem Zähler und /oder einem Zeitstempel. 26. Das Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass das Datenmaterial von einem im Token gespeicherten asymmetrischen privaten Schlüssel signiert und/oder mit einem asymmetrischen öffentlichen Schlüssel des Servers verschlüsselt wird. 27. Das Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass die Verbindungsmittel einen USB-Verbinder umfassen. 28. Das Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass das Token eine Smartcard ist oder umfasst. 3 29. Ein System mit einem mobilen Security-Token, einem Server und einem Rechner mit einem Browser, wobei das Token folgendes umfasst: 4 a. Ein Mittel für den Anschluss an einen Rechner, b. Ein Browser- Mittel für die Kommunikation mit dem Browser, c. Mittel zur Authentifizierung eines Benutzers des Tokens beim Server, wobei die Authentifizierungsmittel des Benutzers über das Browser-Kommunikationsmittel ausgelöst werden, wenn sich der Benutzer ab dem Browser des Rechners an den Server anschließt, wobei die Authentifizierungsmittel eines Benutzers so eingestellt sind, dass sie den Benutzer identifizieren, indem sie durch den Browser mit dem Server kommunizieren, wobei die mobile Authentifizierungsvorrichtung ferner Out-of-band Kommunikationsmittel des Tokens umfasst, die für die Bestätigung der Authentifizierung des Benutzers eingestellt sind, indem sie einen Kommunikationskanal zwischen dem Token und dem Server herstellen, wobei der Kommunikationskanal den Browser übergeht, dadurch gekennzeichnet, dass: 0 Die Authentifizierungmittel des Benutzers so eingestellt sind, dass sie Datenmaterial durch den Browser an den Server schicken, wobei das Datenmaterial von einem im Token gespeicherten asymmetrischen privaten Schlüssel signiert und/oder mit einem asymmetrischen öffentlichen Schlüssel des Servers verschlüsselt wird, wobei das Datenmaterial folgendes umfasst d. Daten zur Identifizierung des Benutzers, e. Authentifizierungsdaten, f. Eine Identifizierungsnummer des Tokens, g. Anti-Replay Daten gegen Replay-Angriffe, h. Assoziationsdaten, IrDA 11
Die Out-of-band Kommunikationsmittel des Tokens sind so eingestellt, dass sie die gleichen IrDA an den Server schicken. Revendications 1. Jeton d authentification portable comprenant : a. des moyens de connexion pour une connexion à un ordinateur, b. des moyens de communication avec un navigateur pour communiquer avec un navigateur s exécutant sur l ordinateur, c. des moyens d authentification d utilisateur pour authentifier un utilisateur du jeton auprès du serveur, dans lequel les moyens d authentification d utilisateur sont déclenchés par l intermédiaire des moyens de communication avec un navigateur lorsque l utilisateur se connecte au serveur à partir du navigateur de l ordinateur, dans lequel les moyens d authentification d utilisateur sont définis pour authentifier l utilisateur en communiquant avec le serveur par l intermédiaire du navigateur, dans lequel le dispositif d authentification portable comprend en outre des moyens de communication de jeton hors bande définis pour valider l authentification d utilisateur en établissant un canal de communication entre le jeton et le serveur, le canal de communication contournant le navigateur, caractérisé en ce que : 2. les moyens d authentification d utilisateur sont définis pour envoyer un bloc de données au serveur par l intermédiaire du navigateur, le bloc de données étant signé par une clé privée asymétrique mémorisée dans le jeton et/ou chiffré au moyen d une clé publique asymétrique du serveur, le bloc de données comprenant : d. des données d identification d utilisateur, e. des données d authentification, f. un identifiant de jeton, g. des données anti-rejeu contre des attaques de rejeu, et h. des données d association, 3. les moyens de communication de jeton hors bande sont définis pour envoyer les mêmes données d association au serveur. 2. Jeton d authentification portable selon la revendication 1, dans lequel les moyens de communication avec un navigateur comprennent un agent local et un agent d hôte, dans lequel l agent local est défini de manière à être exécuté par le jeton alors que l agent d hôte est défini de manière à être exécuté par l ordinateur. 3. Jeton d authentification portable selon la revendication 2, dans lequel l agent d hôte comprend un serveur Web. 4. Jeton d authentification portable selon la revendication 2 ou 3, dans lequel le canal de communication comprend une connexion entre l agent local et l agent d hôte et une connexion TCP/IP entre l agent d hôte et le serveur. 4. Jeton d authentification portable selon l une quelconque des revendications précédentes, dans lequel les moyens de communication de jeton hors bande sont définis pour chiffrer au moins une partie des communications avec le serveur afin que seul le serveur puisse déchiffrer ladite partie. 0 6. Jeton d authentification portable selon la revendication, dans lequel les communications entre le jeton et le serveur comprennent l utilisation d un protocole IPSEC, ou SSL, ou TLS. 7. Jeton d authentification portable selon la revendication 1, dans lequel les données d association sont générées par le jeton et comprennent un nombre aléatoire. 8. Jeton d authentification portable selon l une quelconque des revendications précédentes, dans lequel les moyens d authentification d utilisateur comprennent au moins l une des techniques d authentification d utilisateur suivantes : une authentification par mot de passe classique, une authentification par mot de passe à usage unique, une authentification par défi-réponse, une authentification PKI. 12
9. Jeton d authentification portable selon l une quelconque des revendications précédentes, dans lequel les données d identification d utilisateur consistent en un nom d utilisateur, les données d authentification consistent en un mot de passe d utilisateur, et les données anti-rejeu consistent en un mot de passe à usage unique et/ou en un compteur et/ou en un horodatage.. Jeton d authentification portable selon l une quelconque des revendications précédentes, dans lequel les moyens de connexion comprennent un connecteur USB. 11. Jeton d authentification portable selon l une quelconque des revendications précédentes, dans lequel le jeton est ou comprend une carte à puce. 2 12. Procédé pour authentifier un utilisateur auprès d un serveur, l utilisateur se connectant au serveur à partir d un navigateur s exécutant sur un ordinateur, l utilisateur étant équipé d un jeton d authentification portable, le jeton comprenant : a. des moyens de connexion pour une connexion à l ordinateur, b. des moyens de communication avec un navigateur pour communiquer avec le navigateur, c. des moyens d authentification d utilisateur pour authentifier l utilisateur du jeton auprès du serveur, dans lequel les moyens d authentification d utilisateur sont déclenchés par l intermédiaire des moyens de communication avec un navigateur lorsque l utilisateur se connecte au serveur, dans lequel les moyens d authentification d utilisateur sont définis pour authentifier l utilisateur en communiquant avec le serveur par l intermédiaire du navigateur, dans lequel le procédé consiste en outre à valider l authentification d utilisateur en établissant un canal de communication entre le jeton et le serveur, le canal de communication contournant le navigateur, caractérisé en ce que :. les moyens d authentification d utilisateur sont définis pour envoyer un bloc de données au serveur par l intermédiaire du navigateur, le bloc de données étant signé par une clé privée asymétrique mémorisée dans le jeton et/ou chiffré au moyen d une clé publique asymétrique du serveur, le bloc de données comprenant : 3 d. des données d identification d utilisateur, e. des données d authentification, f. un identifiant de jeton, g. des données anti-rejeu contre des attaques de rejeu, et h. des données d association 4. les moyens de communication de jeton hors bande sont définis pour envoyer les mêmes données d association au serveur. 13. Procédé selon la revendication 12, dans lequel les moyens de communication avec un navigateur comprennent un agent local et un agent d hôte, dans lequel l agent local est défini de manière à être exécuté par le jeton alors que l agent d hôte est défini de manière à être exécuté par ordinateur. 14. Procédé selon la revendication 13, dans lequel l agent d hôte comprend un serveur Web.. Procédé selon la revendication 13 ou 14, dans lequel le canal de communication comprend une connexion entre l agent local et l agent d hôte et une connexion TCP/IP entre l agent d hôte et le serveur. 0 16. Procédé selon la revendication 12, dans lequel le jeton chiffre au moins une partie des communications sur le canal de communication, afin que seul le serveur puisse déchiffrer ladite partie. 17. Procédé selon la revendication 16, dans lequel les communications sur le canal de communication comprennent l utilisation d un protocole IPSEC, SSL ou TLS. 18. Procédé selon la revendication 12, dans lequel les données d association sont générées par le jeton et comprennent un nombre aléatoire. 13
19. Procédé selon la revendication 12, dans lequel l authentification d utilisateur est déclenchée par l utilisateur, qui, après la connexion au serveur, ordonne au navigateur de l authentifier avec le jeton.. Procédé selon la revendication 12, dans lequel l authentification d utilisateur est déclenchée automatiquement par le serveur, après que l utilisateur s est connecté au serveur. 21. Procédé selon la revendication 12, dans lequel le jeton établit le canal de communication automatiquement après que les moyens d authentification d utilisateur ont authentifié l utilisateur auprès du serveur. 22. Procédé selon la revendication 12, dans lequel le jeton établit le canal de communication sur une instruction du serveur, après que le serveur a authentifié l utilisateur avec les moyens d authentification d utilisateur du jeton. 23. Procédé selon la revendication 22, dans lequel le serveur ordonne au jeton d établir le canal de communication en envoyant un code JavaScript au navigateur. 24. Procédé selon la revendication 12, dans lequel les moyens d authentification d utilisateur comprennent au moins l une des techniques d authentification d utilisateur suivantes : une authentification par mot de passe classique, une authentification par mot de passe à usage unique, une authentification par défi-réponse, une authentification PKI. 2. Procédé selon la revendication 12, dans lequel les données d identification d utilisateur consistent en un nom d utilisateur, les données d authentification consistent en un mot de passe d utilisateur, et les données anti-rejeu consistent en un mot de passe à usage unique et/ou en un compteur et/ou en un horodatage. 2 26. Procédé selon la revendication 12, dans lequel le bloc de données est signé par une clé privée asymétrique mémorisée dans le jeton et/ou chiffré au moyen d une clé publique asymétrique du serveur. 27. Procédé selon la revendication 12, dans lequel les moyens de connexion comprennent un connecteur USB. 28. Procédé selon la revendication 12, dans lequel le jeton est ou comprend une carte à puce. 29. Système comprenant un jeton d authentification portable, un serveur et un ordinateur exécutant un navigateur, le jeton comprenant : 3 4 0 a. des moyens de connexion pour une connexion à l ordinateur, b. des moyens de communication avec un navigateur pour communiquer avec le navigateur, c. des moyens d authentification d utilisateur pour authentifier un utilisateur du jeton auprès du serveur, dans lequel les moyens d authentification d utilisateur sont déclenchés par l intermédiaire des moyens de communication avec un navigateur lorsque l utilisateur se connecte au serveur à partir du navigateur de l ordinateur, dans lequel les moyens d authentification d utilisateur sont définis pour authentifier l utilisateur en communiquant avec le serveur par l intermédiaire du navigateur, dans lequel le dispositif d authentification portable comprend en outre des moyens de communication de jeton hors bande définis pour valider une authentification d utilisateur en établissant un canal de communication entre le jeton et le serveur, le canal de communication contournant le navigateur, caractérisé en ce que :. les moyens d authentification d utilisateur sont définis pour envoyer un bloc de données au serveur par l intermédiaire du navigateur, le bloc de données étant signé par une clé privée asymétrique mémorisée dans le jeton et/ou chiffré au moyen d une clé publique asymétrique du serveur, le bloc de données comprenant : d. des données d identification d utilisateur, e. des données d authentification, f. un identifiant de jeton, g. des données anti-rejeu contre des attaques de rejeu, et h. des données d association. les moyens de communication de jeton hors bande sont définis pour envoyer les mêmes données d association au serveur. 14
16
17
18
REFERENCES CITED IN THE DESCRIPTION This list of references cited by the applicant is for the reader s convenience only. It does not form part of the European patent document. Even though great care has been taken in compiling the references, errors or omissions cannot be excluded and the EPO disclaims all liability in this regard. Patent documents cited in the description US 062923 A [0002] US 0071282 A [0003] WO 06131897 A [0004] US 7880 A [0011] Non-patent literature cited in the description ROSS, B. ; JACKSON, C. ; MIYAKE, N. ; BONEH, D; MITCHELL, J.C. Stronger Password Authentication Using Browser Extensions. USENIX Security Symposium, 0, http://crypto-stanford.edu/pwd- Hash/pwdhash.pdf [0006] 19