US20110302627A1 - User authenticaton - Google Patents

User authenticaton Download PDF

Info

Publication number
US20110302627A1
US20110302627A1 US13/201,694 US200913201694A US2011302627A1 US 20110302627 A1 US20110302627 A1 US 20110302627A1 US 200913201694 A US200913201694 A US 200913201694A US 2011302627 A1 US2011302627 A1 US 2011302627A1
Authority
US
United States
Prior art keywords
mobile terminal
service
key
identifier
method
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
US13/201,694
Other versions
US8875232B2 (en
Inventor
Rolf Blom
Luis Barriga
Karl Norrman
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Priority to PCT/SE2009/050182 priority Critical patent/WO2010095988A1/en
Assigned to TELEFONAKTIEBOLAGET L M ERICSSON (PUBL) reassignment TELEFONAKTIEBOLAGET L M ERICSSON (PUBL) ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BARRIGA, LUIS, BLOM, ROLF, NORRMAN, KARL
Publication of US20110302627A1 publication Critical patent/US20110302627A1/en
Application granted granted Critical
Publication of US8875232B2 publication Critical patent/US8875232B2/en
Application status is Active legal-status Critical
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements, e.g. access security or fraud detection; Authentication, e.g. verifying user identity or authorisation; Protecting privacy or anonymity ; Protecting confidentiality; Key management; Integrity; Mobile application security; Using identity modules; Secure pairing of devices; Context aware security; Lawful interception
    • H04W12/06Authentication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0492Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload by using a location-limited connection, e.g. near-field communication or limited proximity of entities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/18Network architectures or network communication protocols for network security using different networks or paths for security, e.g. using out of band channels
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/04Network-specific arrangements or communication protocols supporting networked applications adapted for terminals or networks with limited resources or for terminal portability, e.g. wireless application protocol [WAP]

Abstract

A method of authenticating access to a service comprises: a) receiving at a mobile terminal, over a bi-directional near-field communication channel between the mobile terminal and a browser, at least part of the identifier of a service; b) comparing, at the mobile terminal, at least part of the identifier received at the mobile terminal with a set of identifiers stored in the mobile device; and c) authenticating access to the service on the basis of whether at least part of the identifier received at the mobile terminal matches an identifier in the set. The mobile terminal may stored a set of URLs, and may compare a received URL (or part URL) with the set of stored URLs. It may generate an alert to the user if at least part of the URL received at the mobile terminal does not match a stored URL. User names and keys are not required to be stored on the web-browser, so the web-browser does not need to maintain a password database. This improves security, since a password database would be vulnerable to malicious code.

Description

    FIELD OF THE INVENTION
  • The present invention relates to secure access to a service from a client, comprising filtering of service identifier and generation of a key to allow for secure communication between the server and the client.
  • BACKGROUND TO THE INVENTION
  • Many web-sites require that a user provides evidence of their identity before they can access the web-site. This process is generally referred to as “user authentication”, and typically requires that a user enter a username and a key that (supposedly) is known only to the user and to the administrator of the web-site. The key may be a static key that is valid indefinitely or it may be a one-time key that can be used only once. A key may be, for example a password or passphrase, or a personal identification number (PIN) and, in general terms, may be any string of letters, numerals and/or other characters such as spaces and punctuation marks.
  • User authentication when logging in to web-pages and applications on the web is cumbersome, particularly if a user wishes to log-in to a number of different web-pages and/or applications. The user has to check the URL or other non-comprehensive security indicators of the web-page being accessed to make sure that he sends his username and password to the intended server/application. The transmission to the server is usually protected by TLS (transport layer security).
  • If one time passwords are used, they may exhibit the nice feature that the user has to enter a PIN to generate a password. This is good as the authentication cannot take place without explicit user interaction. There are however several known problems with this solution.
  • The user may have to remember many different usernames and passwords to ensure security separation between services. This can be difficult. It is known for a user to use the same password for more than one service to reduce the number of keys that they have to remember, but this may lead to a loss of security.
  • Often users can be fooled to submit their username and password to a server emulating the service or when connecting to a “phishing” site. This is in particular a problem, since manual verification of URLs or security indicators such as certificate owners is very difficult for most users, and it is difficult even for a knowledgeable user if, e.g., internationalized domain names are used.
  • Desktop browsers and mobile browsers implement today a so-called “password management” function that detects sites requesting authentication and store the user-provided username and password with the corresponding URL, to avoid the user having to remember all their passwords and usernames. However, the stored information can only be used for the browser itself, and it can't be used across other external browsers. In addition, the password manager keeps the passwords stored on the device, and if any malicious code should invade the device it may be able to get access to the password database and thereby lead to loss of security.
  • The GBA process is a key generation/distribution function that is standardised in 3GPP and 3GPP2. The main application is to provide keys that can be used for user authentication and set-up of protected connections between a mobile telephone and a service in the operator network.
  • The triggering of the key generation is controlled by the mobile telephone, and the server can only obtain a key after being contacted by the mobile telephone.
  • For completeness, a brief description of GBA will be included herein. This is taken from the 3GPP specification 3GPP TS 33.220.
  • FIG. 4 shows a simple network model of the entities involved in the bootstrapping approach, and the reference points used between them.
  • A generic bootstrapping server function (BSF) 7 and the user equipment (UE) 8 mutually authenticate using the AKA protocol, and agree on session keys that are afterwards applied between the UE 8 and a network application function (NAF) 9. The BSF 7 shall restrict the applicability of the key material to a specific NAF by using a well-defined key derivation procedure, which includes among other entities the “name” of the NAF 9. The key derivation procedure may be used with multiple NAFs during the lifetime of the key material. The lifetime of the key material is set according to the local policy of the BSF 7.
  • The basis of the key generation is the UMTS AKA mechanism which, from a RAND with the help of user unique functions, derives two keys, Ck and Ik. The concatenation of these keys into a 256 bit entity is denominated Ks.
  • The BSF 7 retrieves an authentication vector from the HSS 10 and generates the key material Ks by concatenating Ck and Ik. A key identifier B-TID is generated in the format of a NAI by taking the base64 encoded RAND value and the BSF server name, i.e. as base64encode(RAND)@BSF_servers_domain_name.
  • The UE 8 authenticates itself towards the BSF 7 b according to the http digest AKA specification (RFC 3310). In this protocol the BSF 7 sends a RAND and the corresponding AUTN to the UE 8. The UE 8 responds with a digest based on the RES from the AKA procedure. At the same time the Ck and Ik keys are generated.
  • The BSF 7 shall be able to acquire the GBA user security settings (GUSS) from the HSS 10.
  • After the bootstrapping has been completed, the UE 8 and a NAF 9 can run an application specific protocol where the authentication of messages will be based on those session keys generated during the mutual authentication between the UE 8 and the BSF 7.
  • General assumptions for the functionality of a NAF are:
      • there is no previous security association between the UE 8 and the NAF 9;
      • the NAF shall be able to locate and communicate securely with the subscriber's BSF;
      • the NAF shall be able to acquire a shared key material established between UE and the BSF during the run of the application-specific protocol;
      • the NAF shall be able to acquire zero or more application-specific USSs from the HSS via the BSF;
      • the NAF shall be able to set the local validity condition of the shared key material according to the local policy;
      • the NAF shall be able to check lifetime and local validity condition of the shared key material.
    SUMMARY OF THE INVENTION
  • A first aspect of the present invention provides a method of authenticating access to a service. The method comprises receiving at a mobile terminal, over a bi-directional near-field communication channel between the mobile terminal and a browser, at least part of the identifier of a service. At least part of the identifier received at the mobile terminal is compared with a set of identifiers stored in the mobile device. Access to the service is authenticated on the basis of whether the at least part of the identifier received at the mobile terminal matches an identifier in the set. (The match may be an exact match or a partial match.)
  • Access to the service may be authenticated if the at least part of the identifier received at the mobile terminal matches an identifier in the set. For example, the set may be a set of service identifiers of that are known to be genuine.
  • Alternatively, access to the service may not be authenticated if the at least part of the identifier received at the mobile terminal matches an identifier in the set. In this example, the set may be a set of “forbidden” service identifiers, for example service identifiers that are know to be fake (eg known to be “phishing” sites) or that relate to undesirable content.
  • The method may further comprise, if the at least part of the identifier received at the mobile terminal matches an identifier in the set, generating a key for authenticating access to the service.
  • The term “key” as used herein is intend to include a password or passphrase, or a personal identification number (PIN) and, in general terms, may be any string of letters, numerals and/or other characters such as spaces and punctuation marks.
  • The method may further comprise providing the browser and a server hosting the service with the key or with information from which they may obtain the key.
  • The method may also comprise establishing secure communication between the browser and the server hosting the service using the key. It may comprise establishing secure communication using a pre-shared key protocol.
  • The method may further comprise generating, at the mobile terminal, a visual, audible or tactile indication if the at least part of the identifier received at the mobile terminal matches an identifier in the set.
  • The method may further comprise obtaining the user's consent before generating the key for accessing the service.
  • The mobile terminal may generate a one-time key.
  • Obtaining the key may comprise: obtaining a first key shared with a network entity; and generating, at the mobile terminal, a second key from the first key.
  • The method may further comprise transmitting the second key to the browser.
  • Generating the second key may further comprise generating, at the mobile terminal, a key reference associated with the second key.
  • The method may comprise transmitting the key reference to the server hosting the service.
  • 13. A method as claimed in claim 12, and comprising the server hosting the service transmitting the key reference to the network entity and receiving in response the second key from the network entity.
  • The method may further comprise establishing the bi-directional near-field communication channel between the browser and the mobile terminal in response to receipt of the service identifier from the server.
  • The method may further comprise, if the at least part of the identifier received at the mobile terminal matches an identifier in the set, informing the user of the identity of the service.
  • Authenticating access to the service may comprise, if the at least part of the identifier received at the mobile terminal does not match an identifier in the set, generating an alert.
  • A server hosting the service may identify to the browser at least one of (1) an authentication method to be used and (2) authentication methods available for use.
  • The method may further comprise informing the mobile terminal of at least one of (1) an authentication method to be used and (2) authentication methods available for use.
  • A second aspect of the invention provides a mobile terminal, comprising a receiver for receiving, over a bi-directional near-field communication channel between the mobile terminal and a web-browser, at least part of the identifier of a service; and a comparator for comparing the at least part of the identifier received at the mobile terminal with a set of identifiers stored in the mobile device. The mobile terminal is adapted to authenticate access to the service on the basis of whether the at least part of the identifier received at the mobile terminal matches an identifier in the set.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The present invention will be described by way of illustrative example with reference to the accompanying drawings in which:
  • FIG. 1 is a schematic illustration of a first method of the present invention;
  • FIG. 2 is a schematic illustration of a second method of the present invention;
  • FIG. 3 is a schematic illustration of a third method of the present invention; and
  • FIG. 4 illustrates key generation according to the general bootstrap approach (GBA).
  • DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
  • The general concept of the present invention is to use a mobile terminal, such as a mobile telephone, as a security token. The invention will be described with reference to a user using a client attempting to communicate with a server offering a service, but the invention is in principle not limited to this scenario but applies to general client server based applications.
  • In order to implement the invention, a user requires a computer terminal such as a desktop or laptop computer that is equipped with a near field communication (NFC) device and a browser. It is assumed that the user is attempting to communicate with a server, and that the server is capable of implementing a back-end interface towards an user authentication system e.g. a GBA BSF, AAA server, or OTP-server
  • It is further assumed that the user has a mobile telephone (or other mobile device) that is equipped with a NFC device that allows communication with the NFC device of the user's computer terminal. Furthermore, the user's mobile terminal is capable of key establishment, for example using GBA, OTP or a challenge response method. (The GBA (generic bootstrapping) method of key establishment is described with reference to FIG. 4 of the present application, for completeness.)
  • It is further assumed that the user has pre-stored in their mobile telephone a table in which each row has space for a tuple of the form:
      • <service-alias, service identifier, [authentication method], [user ID], [Keying-ID], [key], [key lifetime], [usage policies] [other optional parameters]>, where:
      • “service-alias” is a user-defined name for a particular service;
      • “service identifier” is an identifier holding e.g. the complete or parts of the address of a (secure) service. The service identifier holds the same type of information as a password manager in a web browser holds to enable it to recognize specific web sites and link them to associated username-password pairs (in a case where multiple services are hosted by the same domain and the rest of the parameters in the tuple are the same for all services in that domain, the identifier may contain only the domain part which is the same for all the services);
      • the optional field “authentication method” is a field indicating the authentication method to use if more than one authentication method is supported by the mobile telephone;
      • the optional field “User ID” is the identity used to log on to that service;
      • the optional field “Keying-ID” could be an identifier of the users base key Ks in GBA (BTID), or could be the identifier for a base key used in a OTP system;
      • the optional field “Key” is a container for a PSK-TLS GBA-based NAF secret key (Ks-NAF);
      • the optional field “key lifetime” gives the expiry time of the Key;
      • the optional field “usage policies” describes how the telephone should behave when an authentication to a service is initiated—for example, whether any user authorisation (i.e. human interaction) is needed (i.e. if the user has to interact with the mobile telephone) to complete the authentication process; and other optional parameters.
  • It should be noted that, in an embodiment that uses GBA, Ks and the corresponding NAF-key may be reused during its lifetime and in this case there is a need to include the B-TID in the set. However, if desired it could be a policy that authentication should always start with an unused NAF-key.
  • It should also be noted that the description of the invention assumes that the user is authorised to access the service. Determination of whether a user is authorised to access the service is a separate matter from the present invention, and will not be described herein.
  • FIG. 1 illustrates the principal steps of a method according to a first embodiment, relying on GBA, of the present invention.
  • Step 1 When the user behind their desktop/laptop computer connects to a server that implements the method of the present invention (and the server may indicate this to a user, for example by showing a certain login banner), the client 1 of the user's computer terminal notices that the server supports the invention (for example by means of a special header page that is returned by the server hosting the service, or by special decorators contained in the address or identifier for the service (e.g. a URL of a web-page)). Another option is that the server displays the different authentication options it supports and the user selects which one to use; as a further option the server may provide the client 1 with an indication of which authentication option(s) it supports. When the client notices this, it activates the near field device of the user's computer terminal, thereby enabling bi-directional communication with the user's mobile telephone 2 or other mobile device. The client may then inform the user that near field communication is enabled and can be used.
  • As a further option the server indicates in an HTTP-header, not visible to the user, that the authentication service is available. When the browser reads this header it can generate a pop-up window informing the user about it.
  • Step 2 The user then places their mobile telephone 2 over or in close proximity to the near field communication device of their desktop/laptop computer, to allow communication between the client 1 and the mobile telephone 2 over the near field communication channel.
  • The near field communication device of the user's desktop/laptop computer may detect the proximity of the mobile telephone in any suitable way (suitable ways include, but are not limited to, optical, mechanical and/or magnetic methods). If the mobile telephone is not active when placed near the near field communication device of the user's desktop/laptop computer, the near field communication device may advantageously, be arranged to “wake-up” the mobile telephone by any suitable means and then establish the near field communication channel.
  • Step 3 When the user places their mobile telephone 2 over or in close proximity to the NFC device of their desktop/laptop computer, the client 1 senses the presence of the telephone and sends the service identifier, which in this embodiment is in the form of a fully qualified domain name (as required by GBA), of the server on which the requested service is located to the mobile telephone over the near field communication channel. The client may also send the mobile telephone an indication of the authentication method to be used if known at this stage or, if the server supports more than one authentication method, may send an indication of which authentication options the server supports. This is shown as “a” in FIG. 1.
  • Step 4 When the mobile telephone 2 receives a service identifier from the client 1, it compares it with the service identifiers that the user has pre-stored in the mobile telephone. The comparison process is shown as “b” in FIG. 1. If the received service identifier does not match any of the stored service identifiers, the mobile telephone 2 warns the user of this, as this might indicate that the user is attempting to access a fake service rather than a genuine service. The user may be warned via a mobile telephone and/or by sending a message to the client over the near field communication link for display on the user's computer.
  • If, on the other hand, the received service identifier is found to match, at least partially, one of the service identifiers pre-stored by the user in the form of elements of the tuples and the usage policies require it, the mobile telephone 2 displays the service-alias contained in that tuple, and possibly also displays the service identifier. This provides the user with confirmation of the service that they are attempting to access. The mobile telephone then preferably requests consent from the user to proceed with the establishment of a key. Requiring user interaction in the process of establishing a key has the advantage of helping to prevent automated attacks, for example in the event that malicious code has taken control of the user's client (or is running in the background in the users mobile phone 2).
  • Step 5 In a method in which the user is required to give their consent to key establishment, this may be done in any suitable way. For example, the user may be required to depress a particular key on the keypad of their mobile telephone, they may be required to enter a PIN that identifies the user, etc.
  • Step 6 Once the user has given their consent, the mobile telephone 2 proceeds with the step of key establishment for the requested service. The key establishment comprises the steps of deriving the Ks_NAF key for the requested service. If there is no Ks available in the user's terminal equipment, the key establishment may comprise establishing a key via a GBA bootstrapping process with a bootstrapping server function BSF (this is denoted by a broken line in FIG. 1).
  • Key establishment and the setting up of a secure communications channel in this embodiment will be described, by way of example, with reference to the PSK-TLS protocol.
  • The mobile telephone 2 then generates a PSK-TLS NAF-key for the service of the selected server. (A PSK-TLS key denotes a pre-shared key for use with transport layer security.) This NAF-key is generated from the Ks key, the fully qualified domain name of the server hosting the service and other information as specified by GBA.
  • Step 7 The mobile telephone 2 sends the NAF-key to the browser 1 over the near field communication path. The keying ID, in form of a B-TID, from the stored tuple relating to the required service identity is also transferred to the client over the NFC. This is shown as “c” in FIG. 1.
  • If the authentication process in the mobile phone was initiated without an indication of a specific authentication method to be used, the mobile phone has to also inform the client of the authentication method to be used. This information may be transferred for information in other cases.
  • Step 8 Upon receipt of the key and the keying ID, the client 1 starts the process of setting up secure PSK-TLS communication with the server 3 hosting the service requested by the user. The steps of setting up the secure communication are not shown in full in FIG. 1 but will, in general, consist of one or more introductory messages described generally in FIG. 1 as “PSK-TLS handshake” (shown as “d”), including sending the keying ID to the server 3 (shown as “e”) of FIG. 1.
  • Step 9 When the server 3 has received the keying ID identifier (B-TID), it can transmit this to the bootstrapping server function (BSF) 4 (shown as T). The BSF 4 will respond by sending the user ID and the NAF-key for the selected service identifier to the server 3 (shown as “g”). The server 3 is now able to complete the establishment of secure communication with the client 1 according to a shared key protocol (e.g., PSK-TLS), using the NAF-key as the key for securing the communication between the server and the client. Provided that the process has been correctly completed, the server and the client are both now in possession of the same key, the NAF-key, and so can encipher and integrity protect communications between them using this key (or keys derived from said key).
  • The establishment of secure PSK communication between the server 3 and the client 1 is shown as “ ”h in FIG. 1; this may also be referred to as establishing a “PSK-TLS tunnel” between the client and the server.
  • In the method of FIG. 1, the user identity for logging on to the server, “user ID”, can be provided by the BSF to the server. It is therefore not necessary for the “user ID” to be contained in the tuples stored in the mobile telephone 2. Furthermore, the key NAF-key can be retrieved from the stored GBA base key Ks and so need not be stored in the mobile telephone. This requires that the base key, Ks, is stored in the telephone (unless a new Ks is used for every authentication).
  • In the present invention, the user is not required to remember their logon identity “user ID” for the service (although a user may of course choose to remember their logon identity), as this is stored in the mobile telephone 2 or may be obtained from the BSF 4. User names and keys are not stored on the client, so that the invention does not require that the client maintains a password database that is vulnerable to malicious code. Furthermore, the step of comparing the service identity supplied by the client to the mobile telephone with the service identities stored in the mobile telephone, and alerting the user if the received service identity does not match any of the stored service identities, makes it less likely that a user will be fooled into providing their user name and/or password to a fake service that is emulating a genuine service.
  • The invention may be applied in many ways other than the embodiment shown in FIG. 1. For example, although the above description refers to the PSK protocol, It will be clear to the man skilled in the art that protecting the communication channel between the mobile telephone and the server can be accomplished by other pre-shared key protocols than PSK-TLS. For example, the pre-shared key (Ks_NAF in case of GBA) can be used to set up an IPsec tunnel at step h. The pre-shared key would in this case be used in IKEv1 or IKEv2 (where IKEv1 and IKEv2 are Internet Key Exchange protocols). If a pre-shared key protocol other than PSK-TLS is used, it may be necessary to ensure key freshness, for example by use of a nonce to prevent replay attacks.
  • Furthermore use of HTTP digest for authentication is also possible, and this may be with or without a TLS tunnel, although this has the possible disadvantage that there is then no connection between the authentication and the (protected) communication with the server. However, use of HTTP digest may be useful for legacy nodes that do not support a PSK-based secure tunnel.
  • Moreover, although the above embodiment uses GBA-based key establishment the invention is not limited to this. FIG. 2 shows a second embodiment of a method according to the present invention in which the mobile telephone generates a one-time password (OTP) rather than using GBA-based key management. Use of a OTP may provide further security, since each key is used only once and so cannot be re-used by a third party.
  • The method of FIG. 2 proceeds initially according to steps 1-5 of the method of FIG. 1, and further description of these steps will not be repeated.
  • Step 6a This embodiment of the present invention requires that the mobile telephone 2 has a one-time password generator. Once the user has given their consent to the key generation, the one-time password generator in the mobile telephone 2 generates a base key. Preferably, this base key is then transformed to depend upon the service identity of the requested service in a way similar to how it is done in the GBA based embodiment, for example by performing a hash function of the base key generated by the OTP generator with the service identifier, although the invention may be performed even if this transformation is omitted. The resultant key will be used for pre-shared key secured communication between the server and the client.
  • Step 7a The key obtained from the key generated by the OTP generator and the service identity is referred to as the key NAF-key, and is transferred from the mobile telephone 2 to the client 1 as step c in FIG. 2. In the method of FIG. 2, the mobile telephone 2 should also provide the client 1 with the user identity (which, in this embodiment, is pre-stored in the mobile telephone together with the table of tuples of authorised service identities.
  • Step 8a The client 1 then starts the process of setting up a secure communication path with the hosting server 3 that hosts the service requested by the user and, as in FIG. 1, this is shown by the step of “PSK-TLS handshake” (step d). As part of the signalling messages involved in setting up the secure communication path, the client includes the user ID in one of the handshake messages in the PSK-TLS set-up of step d.
  • Step 9a The server requests the key from a OTP server 5, as step e, and the OTP server 5 provides the key NAF-key to the server 4 as step f. The server and the client are both now in possession of the key NAF-key, and a secure communication channel using a pre-shared key may now be established as indicated at step g. In this embodiment, there might be a need to authenticate the user before the set-up of the PSK-TLS tunnel is completed, and there are several ways in which this may be done. For example, the one-time password generator might generate two entities, one of which is used as a password and one of which is used as a key The server forwards the password to the OTP which then, if the password is verified, can be assured that the user trying to login is an authentic user and isn't a server which tries to obtain keys for a given user or launch a denial of service attack by getting the users OTP generator out of synch with the OTP server. Another possibility would be to forward a cryptographic hash of the key from the client 1 to the server 3 and having the server forward the hash to the OTP server. (This step may also be usefully employed in the method of FIG. 1, to avoid certain denial of service attacks.) Another option is that the server performs the comparison between the password/hash of the key received from the client and from the OTP server. This would allow the server to reject the connection before actually establishing the PSK-TLS connection, but would not allow the OTP server to block delivery of passwords and keys to the server.
  • Providing a cryptographic hash of the key or a password from the client via the server to the OTP server has the further advantage that it allows synchronization of the one-time password generator in the mobile telephone 2 and the one-time password generator in the OTP server 5. Although these are intended to be synchronised with one another, they might in practice be slightly out of synchronisation with one another. If there is a lack of synchronisation between the two one-time password generators, the OTP server needs to be able to determine which one-time password key the mobile telephone has generated.
  • If it were desired to minimise the change required to normal web-servers in order to implement the present invention, it would be possible to set-up a TLS tunnel based on server certificates between the web-server and the web-browser, and then run an authentication protocol inside the TLS tunnel to authenticate the user to the server. Typical examples of suitable authentication protocols would be HTTP basic authentication or digest, where the password would be the key obtained above (by performing the hash of the original key and the URL described at step 6a, or it could be based on the OTP base key), or HTTP digest based on the same key. This would avoid the need for the web-server to implement PSK-TLS but would suffer from the drawback that the communications security is independent of the user authentication.
  • FIG. 3 illustrates a method according to a third embodiment of the present invention. This embodiment relates to a challenge response-based method.
  • The method of FIG. 3 initially proceeds in the manner described above with reference to steps 1 to 4 of the method of FIG. 1, and the description of these steps will therefore not be repeated.
  • Step 5b The client 1 then sends the user ID to the server 3 hosting the service requested by the user, and requests a challenge for authentication purposes. This is step c of FIG. 3.
  • Step 6b The client 1 also sends the user ID to a challenge response server (CR server) 6, and requests an authentication vector containing a key that preferably has been transformed to be dependent on the service identity of the requested service, for example using a cryptographic hash function. The authentication vector also contains at least a challenge and an expected response. After the server 3 has received the authentication vector from the CR server 6 (step e), it sends the challenge, possibly together with anti-replay information, to the client 1 (step f).
  • Step 7b The client 1 then forwards the challenge to the mobile telephone 2 (step g).
  • Step 8b Upon receipt of the challenge, the mobile telephone 2 calculates a key and an authentication response. The key preferably depends on the service identity of the requested service, and may be generated by performing a hash function of an initially-generated key and the service identity. The key and the authentication response are then sent back to the client 1, as step h.
  • Step 9b The client 1 then starts setting-up a secure PSK communication path to the server 3, and this is denoted generally as step j in FIG. 3. As part of the set-up signalling, the client 1 forwards the authentication response to the server 3, as step k.
  • Step 10b The server 3 checks the authentication response received from the client 1 with the corresponding entity received in the authentication vector from the CR server 6 and, if it matches, proceeds with the set-up of the PSK communication path, shown generally as step 1.
  • In the method of FIG. 3 it is not necessary for the CR server 6 to generate an authentication response and send it to the server 3, as it could be replaced by a hash of the key generated.
  • In certain implementations it may be possible to piggyback or include some of the messages in the challenge response exchange in/onto the PSK-TLS set-up signalling.
  • The methods of the present invention may be implemented in any suitable manner. For example, communication between the client 1 and the mobile telephone 2 over the NFC may be carried out by any suitable method. For example, to allow use of the currently available systems, the client may write the information to an active tag, and the mobile telephone would then read that tag.
  • To obtain the highest level of security in an embodiment where a web browser is used as client 1, the web browser should have an internal trusted function, ie a part of its core functionality, supporting the interactions with the mobile telephone 2 over the NFC channel and performing the set-up of the PSK-TLS tunnel. This means that the browser 1 should hand over the service identifier (e.g. URL) of the (web-) server which requires user authentication to the mentioned internal functionality. This internal function would then perform all communication with the mobile telephone, would perform the PSK-TLS set-up to the web-server 3 serving the URL it received, and when that is done would hand over the “handle” to the secure connection to the “web-page”. The “internal functionality” may be part of the browser, but may also be a privileged process run by the OS. In the later case, the web-browser acting as the client 1 would be completely decoupled from the key management. This has several benefits, in that the privileged process may implement a standardized interface and would not be tied to a particular browser brand.
  • The client and the operating systems of the desktop/laptop preferably does not allow that scripts or similar programs downloaded from the server are executed from or initiated by the browser can perform the functions related to key management and authentication.
  • When the mobile telephone 2 compares the received service identity with the pre-stored one, it is preferred that it display the web-site alias instead of displaying the service identifier of the requested service, as this may be more convenient for the user. However, the method may provide for the received service identifier to be additionally displayed, or to be displayed upon a request from the user.
  • Furthermore, the tuple stored in the mobile phone, as described above, may be extended to further contain a user-defined tactile, audible or visual feedback. Thus, the user may associate an icon, a sound or a certain vibration to a given service identity stored in the mobile telephone 2 so that, when the mobile telephone 2 receives that service identity from the web-browser 1, it may display the icon or emit the sound or vibration as well as displaying the alias of the service identifier to indicate that the received service identifier is on the set of “trusted” web-sites pre-stored in the mobile telephone.
  • In further embodiments of the invention, which are particularly suitable for low entry telephones, the telephone may only indicate to the user that the service identifier is on the trusted set, without handling the subsequent key generation.
  • Another additional value in each tuple pre-stored in the mobile telephone 2 may be used to indicate whether user consent is required for authentication. This value could be part of the usage policies.
  • The set of service identifiers for which the system should work could be checked and updated over the Internet, ie when the user enters new service identifiers this service identifier could be checked against a blacklist server on the Internet. This could of course also happen on-line at the time of authentication, be carried out at regular intervals, and/or be carried out by user request. At the same time the user may define a service alias and indicate if user interaction is required or not. Changing the service alias or other equivalent representation of the service identifier in the telephone can of course also be done by the user at a later stage.
  • In many cases it is not essential that the login user ID identifies the user. On the contrary, it might be preferred that the user ID gives some privacy protection. One way of achieving this would be to use a hash of the user ID used in the underlying authentication system (GBA, one-time password generation system, challenge response system) with the service identifier.
  • If the user needs more than one user ID for one and the same service, additional parameters can be added as input to the hashing function generating the user name.
  • For users that have multiple accounts for a given service, the telephone preferably displays all associated user identities, for example in a scroll down window, so the user can choose the desired one for this particular session.
  • The way that the user identity is generated, and parameters not available from context, has of course to be transferred from the telephone 2 to the server 3.
  • In the method of FIG. 1, the functionality of the BSF 4 could be extended in such a way that it doesn't return the real user identity but instead returns an identity which is derived with the help of additional parameters like the service identifier (NAF FQDN).
  • It should be noted that the present invention is not limited to the above embodiments, but may be applied in other ways. For example, the invention may be used to provide one party with control over the services that may be accessed by a second party (for example, to allow a parent to control the services that may be accessed by a child). To do this, the first party would pre-store, in the mobile device of the second party, the set of service identifier of services that may be accessed. When the second party (eg child) attempts to access a service, they would be allowed to access the requested service if the first party (eg parent) had pre-stored the service identifier in the mobile device, and the service would be accessed as described above. If the first party (eg parent) had not pre-stored the service identifier of this service in the second party's mobile device, access to the service would be denied at step 4. Using Ks_int for key generation assures that second party (eg the child) cannot manipulate the set to gain access to pages that are not allowed by the first party.
  • In the embodiments described above, the mobile telephone contains a pre-stored set of identifiers of services that may be accessed, and a request to access a service is allowed if the service identifier received by the mobile telephone matches (at least partially) one of the identifiers in the pre-stored set. In principle, however, the invention could be alternatively be implemented by the mobile telephone containing a pre-stored set of identifiers of services that may not be accessed with a request to access a service being disallowed if the service identifier received by the mobile telephone matches (at least partially) one of the identifiers in the pre-stored set.
  • It should be noted that, for the purposes of matching the received service identifier with the set of stored service identifiers, it may not be necessary to send the entire service identifier of the requested service to the mobile telephone 2, and in some cases it may be sufficient to send only a part of the service identifier to the mobile telephone. For example, if certain services hosted by one server are to be treated in the same way, it would be sufficient, for the purposes of matching the received service identifier with the set of stored service identifiers, to send only that part of the service identifier that identifies the group of services. However, the key establishment may require the entire service identifier of the requested service to be provided, depending on the method used to establish the key. For example, if a GBA-based method is used for key establishment, an entire service identifier such as a fully-qualified domain name is required.

Claims (27)

1. A method of authenticating access to a service, comprising:
a) receiving at a mobile terminal, over a bi-directional near-field communication channel between the mobile terminal and a client, at least part of the identifier of a service;
b) comparing, at the mobile terminal, at least part of said identifier received at the mobile terminal with a set of identifiers stored in the mobile device; and
c) authenticating access to the service on the basis of whether the at least part of the identifier received at the mobile terminal matches an identifier in the set.
2. The method of claim 1, wherein the step of authenticating access to the service comprises generating a key for authenticating access to the service if the at least part of the identifier received at the mobile terminal matches an identifier in the set.
3. The method of claim 2, further comprising
providing the client and a server hosting the service with the key or with information from which the key may be obtained.
4. The method of claim 3, further comprising establishing secure communication between the client and the server hosting the service using the key.
5. The method of claim 4, further comprising establishing secure communication between the client and the server hosting the service using a pre-shared key protocol.
6. The method of claim 1, further comprising generating, at the mobile terminal, a visual, audible or tactile indication if the at least part of the identifier received at the mobile terminal matches an identifier in the set.
7. The method of claim 2, further comprising obtaining the user's consent before generating the key for accessing the service.
8. The method of claim 2, wherein the mobile terminal generates a one-time key.
9. The method of claim 5, further comprising
obtaining a first key shared with a network entity; and generating, at the mobile terminal, a second key from the first key.
10. The method of claim 9, further comprising transmitting the second key to the client.
11. The method of claim 9, wherein generating the second key further comprises generating, at the mobile terminal, a key reference associated with the second key.
12. The method of claim 11, further comprising transmitting the key reference to the server hosting the service.
13. The method of claim 12, further comprising the server hosting the service transmitting the key reference to the network entity and receiving in response the second key from the network entity.
14. The method of claim 1, further comprising establishing the bi-directional near-field communication channel between the client and the mobile terminal in response to receipt of the service identifier from the server.
15. The method of claim 1, further comprising, if the at least part of the identifier received at the mobile terminal matches an identifier in the set, informing the user of the identity of the service.
16. The method of claim 1, wherein authenticating access to the service comprises, if the at least part of the identifier received at the mobile terminal does not match an identifier in the set, generating an alert.
17. The method of claim 1, wherein a server hosting the service identifies to the client at least one of (1) an authentication method to be used and (2) authentication methods available for use.
18. The method of claim 1, further comprising informing the mobile terminal of at least one of (1) an authentication method to be used and (2) authentication methods available for use.
19. A mobile terminal, comprising:
a receiver for receiving, over a bi-directional near-field communication channel between the mobile terminal and a web client, at least part of the identifier of a service; and
a comparator for comparing the at least part of the identifier received at the mobile terminal with a set of identifiers stored in the mobile device, wherein
the mobile terminal is adapted to authenticate access to the service on the basis of whether the at least part of the identifier received at the mobile terminal matches an identifier in the set.
20. The mobile terminal of claim 19, wherein the mobile terminal is adapted to authenticate the access to the service by generating a key for authenticating access to the service if the at least part of the identifier received at the mobile terminal matches an identifier in the set.
21. The mobile terminal of claim 20, wherein the mobile terminal is adapted to provide the client and a server hosting the service with the key or with information from which they may obtain the key.
22. The mobile terminal of claim 19, wherein the mobile terminal is adapted to generate a visual, audible or tactile indication if the at least part of the identifier received matches an identifier in the set.
23. The mobile terminal of claim 20, wherein the mobile terminal is adapted to obtain the user's consent before generating the key for accessing the service.
24. The mobile terminal of claim 20, wherein the mobile terminal is adapted to generate a one-time key.
25. The mobile terminal of claim 19, wherein the mobile terminal is adapted to establish the bi-directional near-field communication channel with the client in response to receipt of the service identifier from the server.
26. The mobile terminal of claim 19, wherein the mobile terminal is adapted to, if the at least part of the identifier received matches an identifier in the set, inform the user of the identity of the service.
27. The mobile terminal of claim 19, wherein the authenticating access to the service comprises, if the at least part of the identifier received does not match an identifier in the set, generating an alert.
US13/201,694 2009-02-18 2009-02-18 User authentication Active 2029-10-04 US8875232B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/SE2009/050182 WO2010095988A1 (en) 2009-02-18 2009-02-18 User authentication

Publications (2)

Publication Number Publication Date
US20110302627A1 true US20110302627A1 (en) 2011-12-08
US8875232B2 US8875232B2 (en) 2014-10-28

Family

ID=42634091

Family Applications (1)

Application Number Title Priority Date Filing Date
US13/201,694 Active 2029-10-04 US8875232B2 (en) 2009-02-18 2009-02-18 User authentication

Country Status (3)

Country Link
US (1) US8875232B2 (en)
EP (1) EP2399376A1 (en)
WO (1) WO2010095988A1 (en)

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100250818A1 (en) * 2009-03-27 2010-09-30 Qualcomm Incorporated System and method of providing wireless connectivity between a portable computing device and a portable computing device docking station
US20110035768A1 (en) * 2009-08-07 2011-02-10 Telefonaktiebolaget Lm Ericsson (Publ) Method and Arrangements for Control of Consumption of Content Services
US20110061095A1 (en) * 2008-04-28 2011-03-10 The Ice Organisation Secure Web Based Transactions
US20110252229A1 (en) * 2010-04-07 2011-10-13 Microsoft Corporation Securing passwords against dictionary attacks
US20110289315A1 (en) * 2010-05-18 2011-11-24 Nokia Corporation Generic Bootstrapping Architecture Usage With WEB Applications And WEB Pages
US20120072979A1 (en) * 2010-02-09 2012-03-22 Interdigital Patent Holdings, Inc. Method And Apparatus For Trusted Federated Identity
US20120254997A1 (en) * 2011-04-01 2012-10-04 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatuses for avoiding damage in network attacks
US8396452B1 (en) 2012-05-04 2013-03-12 Google Inc. Proximity login and logoff
US8566910B2 (en) 2010-05-18 2013-10-22 Nokia Corporation Method and apparatus to bind a key to a namespace
US20130311768A1 (en) * 2012-05-21 2013-11-21 Klaus S. Fosmark Secure authentication of a user using a mobile device
US20150189507A1 (en) * 2012-07-02 2015-07-02 Orange Implementing a Security Association During the Attachment of a Terminal to an Access Network
US9128669B2 (en) 2009-03-27 2015-09-08 Qualcomm Incorporated System and method of managing security between a portable computing device and a portable computing device docking station
US9152196B2 (en) 2009-03-27 2015-10-06 Qualcomm Incorporated System and method of managing power at a portable computing device and a portable computing device docking station
US9201593B2 (en) 2009-03-27 2015-12-01 Qualcomm Incorporated System and method of managing displays at a portable computing device and a portable computing device docking station
EP3017586A1 (en) * 2013-07-01 2016-05-11 Telefonaktiebolaget LM Ericsson (publ) User consent for generic bootstrapping architecture
US20160142412A1 (en) * 2013-06-17 2016-05-19 Thinkat Co., Ltd Method and system for preventing information leakage based on telephone
US20160155109A1 (en) * 2013-11-19 2016-06-02 Wayne Fueling Systems Llc Systems and Methods for Convenient and Secure Mobile Transactions
US20160191478A1 (en) * 2014-12-31 2016-06-30 Motorola Solutions, Inc Method and computing device for integrating a key management system with pre-shared key (psk)-authenticated internet key exchange (ike)
US9430630B2 (en) * 2014-07-31 2016-08-30 Textpower, Inc. Credential-free identification and authentication
US9521548B2 (en) 2012-05-21 2016-12-13 Nexiden, Inc. Secure registration of a mobile device for use with a session
US10339285B2 (en) * 2015-06-03 2019-07-02 Fuji Xerox Co., Ltd. Authentication selection for information processing apparatus, information processing method, and non-transitory computer readable medium

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120297187A1 (en) 2011-05-17 2012-11-22 Google Inc. Trusted Mobile Device Based Security
US9858583B2 (en) 2011-09-01 2018-01-02 Avery Dennison Retail Information Services, Llc Apparatus, system and method for tracking consumer product interest using mobile devices
KR20140095523A (en) * 2011-10-31 2014-08-01 노키아 코포레이션 Security mechanism for external code
US8630908B2 (en) 2011-11-02 2014-01-14 Avery Dennison Corporation Distributed point of sale, electronic article surveillance, and product information system, apparatus and method
WO2013089777A1 (en) * 2011-12-16 2013-06-20 Intel Corporation Login via near field communication with automatically generated login information
CN102801698B (en) * 2011-12-20 2015-01-07 北京安天电子设备有限公司 Uniform resource locator (URL) request time sequence-based detection method and system for malicious codes
US20130343542A1 (en) * 2012-06-26 2013-12-26 Certicom Corp. Methods and devices for establishing trust on first use for close proximity communications
BR112014011243A2 (en) 2012-09-10 2017-05-09 Avery Dennison Corp method to prevent unauthorized diversion of near field communication (nfc) tags
US9767329B2 (en) 2012-11-19 2017-09-19 Avery Dennison Retail Information Services, Llc NFC tags with proximity detection
US9942750B2 (en) * 2013-01-23 2018-04-10 Qualcomm Incorporated Providing an encrypted account credential from a first device to a second device
EP3320708A1 (en) * 2015-07-06 2018-05-16 Telefonaktiebolaget LM Ericsson (publ) Facilitating secure communcation between a client device and an application server
US10129235B2 (en) 2015-10-16 2018-11-13 Qualcomm Incorporated Key hierarchy for network slicing
CN108702615A (en) * 2016-02-12 2018-10-23 瑞典爱立信有限公司 Protection interface and process for establishing secure communications links

Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040128509A1 (en) * 2001-02-16 2004-07-01 Christian Gehrmann Method and system for establishing a wireless communication link
US20040147246A1 (en) * 2003-01-14 2004-07-29 Samsung Electronics Co., Ltd. Secure communication system and method for integrated mobile communication terminals comprising a short-distance communication module
US20040255119A1 (en) * 2003-03-26 2004-12-16 Masaharu Ukeda Memory device and passcode generator
US20050076198A1 (en) * 2003-10-02 2005-04-07 Apacheta Corporation Authentication system
US20060104234A1 (en) * 2003-12-08 2006-05-18 Huawei Technologies Co., Ltd. Method for establishment of a service tunnel in a WLAN
US20060178110A1 (en) * 2005-02-09 2006-08-10 Nokia Corporation System and method for interacting with an entity by means of a mobile station via a user-wearable terminal
US20060253597A1 (en) * 2005-05-05 2006-11-09 Mujica Technologies Inc. E-mail system
US20080289030A1 (en) * 2007-05-17 2008-11-20 United States Cellular Corporation User-friendly multifactor mobile authentication
US20090047964A1 (en) * 2007-08-17 2009-02-19 Qualcomm Incorporated Handoff in ad-hoc mobile broadband networks
US20090172402A1 (en) * 2007-12-31 2009-07-02 Nguyen Tho Tran Multi-factor authentication and certification system for electronic transactions
US20090227226A1 (en) * 2007-11-29 2009-09-10 Jasper Wireless, Inc. Enhanced manageability in wireless data communication systems
US20090249457A1 (en) * 2008-03-25 2009-10-01 Graff Bruno Y Accessing secure network resources
US7627341B2 (en) * 2005-01-31 2009-12-01 Microsoft Corporation User authentication via a mobile telephone
US20100274859A1 (en) * 2007-05-24 2010-10-28 Asim Bucuk Method And System For The Creation, Management And Authentication Of Links Between Entities

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7784684B2 (en) 2002-08-08 2010-08-31 Fujitsu Limited Wireless computer wallet for physical point of sale (POS) transactions
KR20040089279A (en) 2003-04-11 2004-10-21 주식회사 팬택앤큐리텔 APPARATUS AND ITS METHOD FOR PROVIDING OPENING/CLOSING FUNCTION USING IrDA AND FINGER PRINT IDENTIFICATION
WO2008042302A2 (en) 2006-09-29 2008-04-10 Narian Technologies Corp. Apparatus and method using near field communications
KR100858871B1 (en) 2007-04-25 2008-09-17 주식회사 하이스마텍 Card immediate generation system using nfc terminal and method of it
US20090018964A1 (en) * 2007-07-13 2009-01-15 Sony Ericsson Mobile Communications Ab Methods, systems, and computer program products for performing a transaction in which a certifier provides identification information for authenticating a customer at the point of sale

Patent Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040128509A1 (en) * 2001-02-16 2004-07-01 Christian Gehrmann Method and system for establishing a wireless communication link
US20040147246A1 (en) * 2003-01-14 2004-07-29 Samsung Electronics Co., Ltd. Secure communication system and method for integrated mobile communication terminals comprising a short-distance communication module
US20040255119A1 (en) * 2003-03-26 2004-12-16 Masaharu Ukeda Memory device and passcode generator
US20050076198A1 (en) * 2003-10-02 2005-04-07 Apacheta Corporation Authentication system
US20060104234A1 (en) * 2003-12-08 2006-05-18 Huawei Technologies Co., Ltd. Method for establishment of a service tunnel in a WLAN
US7627341B2 (en) * 2005-01-31 2009-12-01 Microsoft Corporation User authentication via a mobile telephone
US20060178110A1 (en) * 2005-02-09 2006-08-10 Nokia Corporation System and method for interacting with an entity by means of a mobile station via a user-wearable terminal
US20060253597A1 (en) * 2005-05-05 2006-11-09 Mujica Technologies Inc. E-mail system
US20080289030A1 (en) * 2007-05-17 2008-11-20 United States Cellular Corporation User-friendly multifactor mobile authentication
US20100274859A1 (en) * 2007-05-24 2010-10-28 Asim Bucuk Method And System For The Creation, Management And Authentication Of Links Between Entities
US20090047964A1 (en) * 2007-08-17 2009-02-19 Qualcomm Incorporated Handoff in ad-hoc mobile broadband networks
US20090227226A1 (en) * 2007-11-29 2009-09-10 Jasper Wireless, Inc. Enhanced manageability in wireless data communication systems
US20090172402A1 (en) * 2007-12-31 2009-07-02 Nguyen Tho Tran Multi-factor authentication and certification system for electronic transactions
US20090249457A1 (en) * 2008-03-25 2009-10-01 Graff Bruno Y Accessing secure network resources

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Remedios et al., NFC Technologies in Mobile Phones and Emerging Applications, January 2006, Springer IFIP, Volume 220, pp. 425-434 *

Cited By (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110061095A1 (en) * 2008-04-28 2011-03-10 The Ice Organisation Secure Web Based Transactions
US8621575B2 (en) * 2008-04-28 2013-12-31 Ice Organisation Ltd Secure web based transactions
US20120282858A1 (en) * 2009-03-27 2012-11-08 Qualcomm Incorporated System and Method of Providing Wireless Connectivity Between a Portable Computing Device and a Portable Computing Device Docking Station
US9201593B2 (en) 2009-03-27 2015-12-01 Qualcomm Incorporated System and method of managing displays at a portable computing device and a portable computing device docking station
US9152196B2 (en) 2009-03-27 2015-10-06 Qualcomm Incorporated System and method of managing power at a portable computing device and a portable computing device docking station
US9128669B2 (en) 2009-03-27 2015-09-08 Qualcomm Incorporated System and method of managing security between a portable computing device and a portable computing device docking station
US20100250818A1 (en) * 2009-03-27 2010-09-30 Qualcomm Incorporated System and method of providing wireless connectivity between a portable computing device and a portable computing device docking station
US20110035768A1 (en) * 2009-08-07 2011-02-10 Telefonaktiebolaget Lm Ericsson (Publ) Method and Arrangements for Control of Consumption of Content Services
US20120072979A1 (en) * 2010-02-09 2012-03-22 Interdigital Patent Holdings, Inc. Method And Apparatus For Trusted Federated Identity
US8533803B2 (en) * 2010-02-09 2013-09-10 Interdigital Patent Holdings, Inc. Method and apparatus for trusted federated identity
US20110252229A1 (en) * 2010-04-07 2011-10-13 Microsoft Corporation Securing passwords against dictionary attacks
US9015489B2 (en) * 2010-04-07 2015-04-21 Microsoft Technology Licensing, Llc Securing passwords against dictionary attacks
US10027631B2 (en) 2010-04-07 2018-07-17 Microsoft Technology Licensing, Llc Securing passwords against dictionary attacks
US8661257B2 (en) * 2010-05-18 2014-02-25 Nokia Corporation Generic bootstrapping architecture usage with Web applications and Web pages
US20110289315A1 (en) * 2010-05-18 2011-11-24 Nokia Corporation Generic Bootstrapping Architecture Usage With WEB Applications And WEB Pages
US8566910B2 (en) 2010-05-18 2013-10-22 Nokia Corporation Method and apparatus to bind a key to a namespace
US8903095B2 (en) * 2011-04-01 2014-12-02 Telefonaktiebolaget L M Ericsson (Publ) Methods and apparatuses for avoiding damage in network attacks
US9338173B2 (en) 2011-04-01 2016-05-10 Telefonaktiebolaget L M Ericsson (Publ) Methods and apparatuses for avoiding damage in network attacks
US20120254997A1 (en) * 2011-04-01 2012-10-04 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatuses for avoiding damage in network attacks
US9107075B1 (en) 2012-05-04 2015-08-11 Google Inc. Proximity unlock and lockout
US8396452B1 (en) 2012-05-04 2013-03-12 Google Inc. Proximity login and logoff
US20130311768A1 (en) * 2012-05-21 2013-11-21 Klaus S. Fosmark Secure authentication of a user using a mobile device
US9521548B2 (en) 2012-05-21 2016-12-13 Nexiden, Inc. Secure registration of a mobile device for use with a session
US9642005B2 (en) * 2012-05-21 2017-05-02 Nexiden, Inc. Secure authentication of a user using a mobile device
US20150189507A1 (en) * 2012-07-02 2015-07-02 Orange Implementing a Security Association During the Attachment of a Terminal to an Access Network
US9532218B2 (en) * 2012-07-02 2016-12-27 Orange Implementing a security association during the attachment of a terminal to an access network
US20160142412A1 (en) * 2013-06-17 2016-05-19 Thinkat Co., Ltd Method and system for preventing information leakage based on telephone
US9736161B2 (en) * 2013-06-17 2017-08-15 Thinkat Co., Ltd. Method and system for preventing information leakage based on telephone
EP3017586A4 (en) * 2013-07-01 2016-06-15 Ericsson Telefon Ab L M User consent for generic bootstrapping architecture
US9686280B2 (en) 2013-07-01 2017-06-20 Telefonaktiebolaget Lm Ericsson (Publ) User consent for generic bootstrapping architecture
EP3017586A1 (en) * 2013-07-01 2016-05-11 Telefonaktiebolaget LM Ericsson (publ) User consent for generic bootstrapping architecture
US20160155109A1 (en) * 2013-11-19 2016-06-02 Wayne Fueling Systems Llc Systems and Methods for Convenient and Secure Mobile Transactions
US10217096B2 (en) * 2013-11-19 2019-02-26 Wayne Fueling Systems Llc Systems and methods for convenient and secure mobile transactions
US9430630B2 (en) * 2014-07-31 2016-08-30 Textpower, Inc. Credential-free identification and authentication
US10050969B2 (en) 2014-07-31 2018-08-14 Textpower, Inc. Credential-free identification and authentication
US20160191478A1 (en) * 2014-12-31 2016-06-30 Motorola Solutions, Inc Method and computing device for integrating a key management system with pre-shared key (psk)-authenticated internet key exchange (ike)
US10339285B2 (en) * 2015-06-03 2019-07-02 Fuji Xerox Co., Ltd. Authentication selection for information processing apparatus, information processing method, and non-transitory computer readable medium

Also Published As

Publication number Publication date
WO2010095988A1 (en) 2010-08-26
EP2399376A1 (en) 2011-12-28
US8875232B2 (en) 2014-10-28

Similar Documents

Publication Publication Date Title
Barrett et al. SSH, The Secure Shell: The Definitive Guide: The Definitive Guide
KR101636028B1 (en) Identity management with local functionality
FI115098B (en) Authentication data communications
ES2706540T3 (en) User equipment credentials system
EP2834729B1 (en) Secure authentication in a multi-party system
US7707412B2 (en) Linked authentication protocols
CA2731462C (en) System and method for in- and out-of-band multi-factor server-to-user authentication
Bhargavan et al. Triple handshakes and cookie cutters: Breaking and fixing authentication over TLS
EP1255392B1 (en) Computer network security system employing portable storage device
US8510811B2 (en) Network transaction verification and authentication
KR101684753B1 (en) Method and apparatus for trusted federated identity
CN101621801B (en) Method, system, server and terminal for authenticating wireless local area network
CN101822082B (en) Techniques for secure channelization between UICC and terminal
ES2595105T3 (en) Effective and secure authentication of computer systems
CN101160924B (en) Method for distributing certificates in a communication system
US9015473B2 (en) Method and system for automated and secure provisioning of service access credentials for on-line services to users of mobile communication terminals
EP2259539A2 (en) Secure bootstrapping for wireless communications
EP2608486B1 (en) A computer implemented system and method for providing users with secured access to application servers
US20090288143A1 (en) Multi-factor password-authenticated key exchange
EP2314090B1 (en) Portable device association
US8423768B2 (en) Method for controlling the location information for authentication of a mobile station
TWI510108B (en) Method and apparatus for trusted federated identity management and data access authorization
EP2632108B1 (en) Method and system for secure communication
CN102204305B (en) Home node-b apparatus and security protocols
ES2424474T3 (en) Method and apparatus for establishing a security association

Legal Events

Date Code Title Description
AS Assignment

Owner name: TELEFONAKTIEBOLAGET L M ERICSSON (PUBL), SWEDEN

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BARRIGA, LUIS;BLOM, ROLF;NORRMAN, KARL;REEL/FRAME:026761/0541

Effective date: 20090219

STCF Information on status: patent grant

Free format text: PATENTED CASE

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551)

Year of fee payment: 4