CN114128212A - Method and system for authenticating secure credential transmission to a device - Google Patents

Method and system for authenticating secure credential transmission to a device Download PDF

Info

Publication number
CN114128212A
CN114128212A CN202080047653.9A CN202080047653A CN114128212A CN 114128212 A CN114128212 A CN 114128212A CN 202080047653 A CN202080047653 A CN 202080047653A CN 114128212 A CN114128212 A CN 114128212A
Authority
CN
China
Prior art keywords
client device
user
processors
identifier
authentication server
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
CN202080047653.9A
Other languages
Chinese (zh)
Other versions
CN114128212B (en
Inventor
瓦迪姆·苏霍姆利诺夫
阿尔贝托·马丁
安德雷·普罗宁
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.)
Google LLC
Original Assignee
Google LLC
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 Google LLC filed Critical Google LLC
Priority to CN202410442557.4A priority Critical patent/CN118199894A/en
Publication of CN114128212A publication Critical patent/CN114128212A/en
Application granted granted Critical
Publication of CN114128212B publication Critical patent/CN114128212B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/575—Secure boot
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3273—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/50—Secure pairing of devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/084—Access security using delegated authorisation, e.g. open authorisation [OAuth] protocol

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Power Engineering (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Information Transfer Between Computers (AREA)
  • Telephonic Communication Services (AREA)
  • Computer And Data Communications (AREA)

Abstract

A method for authenticating a secure credential transmission to a device (130) includes verifying a user identity (306) and a device identity (308). In particular, the method comprises verifying a user identity by requesting (412, 414) and receiving (310, 416) a user identification input at the first client device (120), and verifying a device identity of the second client device (130) by: (i) determining (408) a security state of the second client device (130) from hardware of the second client device (130), (ii) invoking (418, 420) an identifier related to the security state of the second client device (130) to the authentication server (110), and (iii) obtaining (424) an attestation of the second client device (130) from the authentication server (110) based on the invoked identifier. After verifying the user identity and the device identity, the method comprises establishing (312, 448) a secure channel between the first client device (120) and the second client device (130) for secure credential transmission using one or more tokens (436, 444, 446) generated by the authentication server (110).

Description

Method and system for authenticating secure credential transmission to a device
Cross Reference to Related Applications
This application is a continuation of U.S. application No.16/526,384 filed on 30/7/2019, the entire disclosure of which is incorporated herein by reference.
Background
When setting up a new device, the user will have to re-login to the system, such as by providing a password, using two-factor authentication, or other means. This login process may include additional steps, such as accessing a password lookup system. Prior to logging in, the user may not be able to adequately explore the new device and determine whether the new device is suitable for their needs or whether the new device is a secure device for work or other purposes.
Disclosure of Invention
Aspects of the present disclosure provide a method for authenticating a secure credential transmission to a device. The method includes receiving, by one or more first processors at a first client device, a user input to initiate a security credential transmission to a second device, the user input triggering a communication to be sent to the second client device; verifying a user identity by requesting a user identification input by the one or more first processors and receiving the user identification input by the one or more first processors; verifying a device identity of a second client device by: determining, by the one or more second processors of the second client device, a security state of the second client device from hardware of the second client device, invoking, by the one or more second processors, an identifier related to the security state of the second client device to the authentication server, and receiving, by the one or more second processors, attestation of the second client device from the authentication server based on the invoked identifier; receiving, by the one or more second processors, one or more tokens associated with the account for the security credential transmission; and after verifying the user identity and the device identity, establishing, using the one or more first processors and the one or more second processors, a secure channel between the first client device and the second client device using the one or more tokens for secure credential transmission.
In one example, the user input to initiate the secure credential transfer to the second device comprises a tap input in an applet installed on the first client device. In another example, communications are sent from a first client device to a second client device using near field communication. In this example, the method optionally includes, after the one or more second processors of the second client device receive the communication, requesting, by the one or more second processors, the user to confirm the transmission of the security credentials to the second device.
In a further example, the user identification input is an existing verification of the user identity for the first client device. In yet another example, the security state of the second client device is determined from a trusted security chip of the second client device. In yet another example, the attestation from the authentication server indicates that the invoked identifier is associated with a known client device in a database of the authentication server.
In another example, the method further includes receiving, by the one or more first processors, an attestation of the second client device. In a further example, the method further includes receiving, by the one or more first processors, a selection of an account for the security credential transmission. In yet another example, invoking the identifier related to the security state of the second client device with the authentication server includes using the first client device as a proxy for invoking the identifier with the authentication server.
Other aspects of the disclosure provide a non-transitory computer-readable medium configured to store instructions executable by one or more processors. The instructions, when executed, cause one or more processors to perform a method. The method includes receiving, at a first client device, a user input to initiate a security credential transmission to a second device, the user input triggering a communication to be sent to the second client device; verifying, at the first client device, the user identity by requesting a user identification input and receiving the user identification input; verifying a device identity of a second client device by: determining, at the second client device, a security state of the second client device from hardware of the second client device, invoking, from the second client device to the authentication server, an identifier related to the security state of the second client device, and receiving, at the second client device, attestation of the second client device from the authentication server based on the invoked identifier; receiving, from an authentication server, one or more tokens associated with an account for secure credential transmission; and after verifying the user identity and the device identity, establishing a secure channel between the first client device and the second client device using the one or more tokens for secure credential transmission.
In one example, the user input to initiate the secure credential transfer to the second device comprises a tap input in an applet installed on the first client device. In another example, communications are sent from a first client device to a second client device using near field communication. In a further example, the security state of the second client device is determined from a trusted security chip of the second client device. In yet another example, the attestation from the authentication server indicates that the invoked identifier is associated with a known client device in a database of the authentication server.
In yet another example, the method further comprises receiving, at the first client device, the attestation for the second client device. In another example, the method further includes receiving, at the first client device, a selection of an account for the security credential transmission. In a further example, invoking the identifier associated with the security state of the second client device with the authentication server includes using the first client device as a proxy to invoke the identifier with the authentication server.
Further aspects of the present disclosure provide a system. The system includes a memory storing a database of device identity information for a plurality of devices having verified security states; and one or more processors in communication with the memory. The one or more processors are configured to receive, from a first computing device, a communication related to initiating a security credential transmission; receiving a verification request from a second computing device, the verification request including a challenge communication carrying: information relating to user authentication, a first identifier from a previous challenge communication, and a signature from a second computing device, the signature including a second identifier relating to a security state of the second computing device; performing verification of the verification request, including verifying that information relating to user authentication is from the first computing device, verifying that the first identifier matches the second identifier, and verifying that the second identifier matches a device in a database of device identity information; and providing the one or more tokens to the first computing device and the second computing device to establish a secure channel for secure credential transmission to the second computing device.
In one example, the one or more processors are configured to provide the one or more tokens by providing a first token to the second computing device that includes a proof of the verification request; receiving a selection of a user account from a first computing device; providing a second token for the user account to the first computing device; receiving a signed second token from a second computing device; and providing a third token for establishing a secure channel for secure credential transmission to the second computing device.
Drawings
Fig. 1 is a functional diagram of an example system 100, according to aspects of the present disclosure.
Fig. 2 is a pictorial diagram of an example system 100, in accordance with aspects of the present disclosure.
Fig. 3 is a flow diagram 300 of an example method in accordance with aspects of the present disclosure.
Fig. 4 is a detailed diagram 400 of an example method according to aspects of the present disclosure.
Fig. 5 is a flow diagram 500 of an example method in accordance with aspects of the present disclosure.
Detailed Description
The technology relates to a method and system for authenticating a secure credential transmission to a device. When a user uses a new device or borrows a device, credentials are typically required to transmit user profiles (profiles) and other settings to the device. Typically, some combination of passwords, two-factor authentication, and other authentication schemes are implemented. One problem with these approaches, however, is that they typically do not include an integrated way of also verifying that the device is a secure device. The methods and systems described herein provide a series of steps that allow for authentication of the user as well as the device prior to credential transmission. Furthermore, the methods and systems described herein require less user interaction than other authentication methods and systems, thereby allowing a user to perform simpler processing. Further, the approaches described herein may improve the security of user profiles and other settings by reducing the need to manually type credentials on a new or borrowed device, and/or by allowing for temporary transmission/authentication of credentials.
The authentication system includes a first client device, a second client device, and an authentication server. The user may have a user profile on the first client device or may access the user profile from the first client device. The user profile may include device settings, application downloads, application settings, or account settings. The second client device may be any device that does not have a user profile store thereon or from which a user profile may be accessed. The authentication server may have a database of device identity information for a plurality of devices whose security is known or otherwise verified.
To initiate a secure credential transmission of a user profile, user input may be received at a first client device, and then the second client device confirms the transmission from the first client device to the second client device. In response to the confirmation, the second client device may send an identifier of the second client device to the first client device. The identifier may include a security status retrieved from hardware of the second client device indicating that the second client device is a trusted device for transmission purposes. After the second client device receives the user confirmation, user authentication may be performed at the first client device to further confirm the request for the secure credential transmission to the second client device. In addition, device authentication may be performed for the second client device by transmitting the signature of the second client device to the authentication server for verification. If the second client device is verified, the authentication server may provide the second client device with the attestation and the transfer token of the second client device. The proof and the transmission token may be transmitted from the second client device to the first client device, which may perform additional checks on the proof of the second client device.
User input may be received at the first client device to select an account, such as a user profile, and a time of validity for the security credential transmission. The first client device may then request a temporary token for the selected account from the authentication server. In response, the authentication server may transmit the temporary token to the first client device, which transmits the temporary token to the second client device. The second client device may sign the temporary token and transmit the signed temporary token to the authentication server to verify a channel between the first client device and the second client device. When the information related to the signed temporary token is verified, the authentication server then provides the second client device with the conventional session token with the requested validity time for the secure credential transmission. The secure credential transfer of the user profile from the first client device to the second client device is then completed using the conventional session token. That is, the second client device is authenticated by the first client device to access the user profile for a valid time.
The above-described features have the technical effect of providing a more secure process to authorize access to user credentials on a client device. By using a client device that has been trusted by the user to authenticate the second client device, this process has the technical advantage that no complex user input is required and security can be improved by removing the need to manually enter user credentials on an unknown device. The authentication method does not require the user to enter login information and additional user verification steps, but rather requires the user to request that a particular account be transferred and authenticated on a trusted device. Further, because the process uses the authentication server to verify the second device as a trusted device, the user may have greater confidence in the security of transmitting or accessing the user credentials to the second device. Security may also be improved by the process of mutually authenticating both the first and second client devices prior to any user credential transmission.
Example System
Fig. 1 and 2 illustrate an example system 100 in which features described herein may be implemented. An example system may be a system for authenticating a client computing device. In this example, system 100 may include a plurality of computing devices 110, 120, 130 and a storage system 150 connected via a network 160. The computing device 110 may be a server computing device operating as an authentication server. Computing devices 120 and 130 may be client computing devices.
As shown in fig. 1, authentication server 110 includes one or more processors 112, memory 114, instructions 116, and data 118. The one or more processors 112 may be any conventional processor, such as a commercially available CPU. Alternatively, one or more processors may be a special purpose device, such as an ASIC or other hardware-based processor. Although fig. 1 functionally illustrates the processor, memory, and other elements of the computing device 110 as being within the same block, those of ordinary skill in the art will appreciate that a processor, computing device, or memory may in fact comprise multiple processors, computing devices, or memories that may or may not be located or stored within the same physical housing. In one example, the one or more computing devices 110 may include one or more server computing devices having multiple computing devices, e.g., load balancing server farms, that exchange information with different nodes of the network for receiving, processing, and transmitting data to or from other computing devices.
The memory 114 stores information that may be accessed by the one or more processors 112, including instructions 116 and data 118 that may be executed or otherwise used by the processor(s) 112. The memory 114 may be of any type capable of storing information accessible by the processor, including a computing device readable medium, or other medium that stores data readable by an electronic device, such as a hard disk drive, memory card, ROM, RAM, DVD, or other optical disk, as well as other writable and read-only memories. The systems and methods may include different combinations of the foregoing, whereby different portions of the instructions and data are stored on different types of media. In particular, the memory 114 may be configured to store a database of device identity information for a plurality of computing devices.
The instructions 116 may be any set of instructions that are executed directly (such as machine code) or indirectly (such as scripts) by a processor. For example, the instructions may be stored as computing device code on a computing device readable medium. In this regard, the terms "instructions" and "programs" may be used interchangeably herein. The instructions may be stored in an object code format for direct processing by a processor, or in any other computing device language, including scripts or collections of independent source code modules that are interpreted on demand or compiled in advance. The procedures, functions, methods and routines of the instructions are explained in more detail below. Further, the instructions 116 may include compiling and updating a database of device identity information for devices known or verified as security devices.
The processor 112 may retrieve, store, or modify data 118 according to the instructions 116. As an example, the data 118 associated with the memory 114 may include a database of device identity information for a plurality of computing devices. Further, data 118 may also include data for supporting services of one or more client devices (e.g., 120, 130, or more). Such data may include data that supports hosting network-based applications, file sharing services, communication services, games, sharing video or audio files, or any other networking-based service.
Each of the client computing devices 120 and 130 may be configured similarly to the authentication server 110, with one or more processors, memory, instructions, and data as described above. Each client computing device 120, 130 may be a personal computing device intended for use by a user. As shown in fig. 2, both client computing devices 120 and 130 may be intended for use by a single user 220. In some alternative examples, the authentication server 110 may be part of the client computing device 120 or 130 rather than remote from the client computing device 120 or 130.
In addition, each client computing device 120, 130 has all of the components typically used in conjunction with a personal computing device, including one or more processors (e.g., a Central Processing Unit (CPU)), memory (e.g., RAM and internal hard drives) to store data and instructions, a display such as display 122, 132 (e.g., a monitor having a screen, a touch screen, a projector, a television or other device operable to display information), speakers, and user input devices 124, 134 (e.g., a mouse, keyboard, touch screen, camera, or microphone). The one or more processors of each client computing device may be the same as or similar to the one or more processors 112, and the memory of each client computing device storing instructions and data may be the same as or similar to the memory 114 storing instructions 116 and data 118. Further, each client computing device may include one or more components that implement Near Field Communication (NFC) capabilities.
Although the client computing devices 120, 130 may each comprise a full-size personal computing device, they may alternatively comprise being able to wirelessly exchange data with a server computing device (such as server computing device 110) over a network such as the internet. By way of example only, the client computing device 120 may be a mobile phone or device, such as a wireless-enabled PDA, a tablet PC, a wearable computing device or system, or a netbook capable of obtaining information via the internet or other network. In another example, the client computing device 120 may be a wearable computing system, such as a smart watch.
At the client computing device 120, a user profile of a user (such as user 220) may be on or accessible. The user profile may include device settings, application downloads, application settings, and/or account settings. The client computing device 130 may not have a user profile stored thereon or may have access to a user profile therefrom. For example, the client computing device 130 may be a newly purchased laptop or a borrowed laptop, or a display laptop in a retail environment.
Like the memory 114, the storage system 150 may be any type of computerized storage capable of storing information accessible to the server computing device 110, such as a hard drive, memory card, ROM, RAM, DVD, CD-ROM, writable and read-only memory. Further, storage system 150 may comprise a distributed storage system in which data is stored on a number of different storage devices, which may be physically located in the same or different geographic locations. As shown, storage system 150 may be connected to computing devices via network 160, and/or may be directly connected to or incorporated into any of computing devices 110, 120, 130, etc. Storage system 150 may store various types of information that may be retrieved or otherwise accessed by one or more server computing devices (such as authentication server 110) and/or one or more client computing devices (such as client computing devices 120 or 130) in order to perform some or all of the features described herein.
Although fig. 1 functionally illustrates the processors, memory, and other elements of the computing device as being within the same block, the processors, computers, computing devices, or memory may in fact comprise multiple processors, computers, computing devices, or memories, which may or may not be stored in the same physical housing. For example, memory 114 may be a hard drive or other storage medium located in a different enclosure than the enclosure of computing device 110.
References to a processor, computer, computing device, or memory are to be understood as including references to a processor, computer, computing device, or memory that may or may not operate in parallel. For example, the computing devices 110 may include server computing devices operating as a load balancing server farm, a distributed system, and so forth. Further, while some of the functions described below are indicated as occurring on a single computing device having a single processor, various aspects of the subject matter described herein may be implemented by multiple computing devices, e.g., communicating information over network 160.
The network 160 and intermediate nodes may include various configurations and protocols, including short-range communication protocols, such as BluetoothTMBluetoothTMLE, internet, world wide web, intranet, virtual private network, wide area network, local area network, private network using one or more company-specific communication protocols, ethernet, WiFi, and HTTP, and various combinations thereof. Such communication may be facilitated by any device capable of communicating data to and from other computing devices, such as modems and wireless interfaces.
Example method
In addition to the operations described above and illustrated in the accompanying figures, various operations will now be described. It should be understood that the following operations need not be performed in the exact order described below. Conversely, various operations may be processed in a different order or concurrently, and operations may be added or omitted. For example, fig. 3 is a flow chart 300 according to aspects of the present disclosure. More specifically, fig. 3 shows a flow of an example method for authenticating a secure credential transmission from a client computing device 120 (hereinafter "first client device") to a client computing device 130 (hereinafter "second client device") using an authentication server 110. The first client device 120 and the second client device 130 may have NFC enabled. Further, fig. 4 shows a functional diagram 400 illustrating additional details of the method shown in fig. 3, including communications between the first client device 120, the second client device 130, and the authentication server 110.
At block 302, to initiate a secure credential transmission of a user profile, user input may be received at the first client device 120 and the second client device 130. For example, as shown in fig. 4, at step 402, a user input may be received at the first client device 120 to initiate a process of authenticating the second client device 130. The user input may be a tap received at the user input device 124 of the first client device in an applet installed on the first client device or in a browser opened on the first client device, but it will be understood that other types of user input may alternatively be used. In some cases, the user input may provide an indication of an account for the secure credential transfer. At step 404a, the user input may trigger transmission of a first communication from the first client device to the authentication server. The first communication may include information related to the first client device, the initiation of the security credential transmission, and/or the account used for the transmission. At step 404b, the user input may also trigger the transmission of a second communication using NFC or another short-range communication protocol. The second communication may include instructions for initiating a security credential transmission on the second client device. The second client device may detect the communication from the first client device and, at step 406a, prompt the user to confirm the transmission on the second client device. The prompting may include opening a browser (or other application) on the second client device and requesting user input in the browser. At step 406b, a user confirmation may be received at the second client device via user input at the second client device.
At block 304, in response to the user confirmation, the second client device may send an identifier of the second client device to the first client device. As shown in step 408 in fig. 4, the identifier may be retrieved from hardware of the second client device, such as a trusted security chip. The identifier may also include a security status, which may also be retrieved from the hardware of the second client device. In particular, the security state of the second client device may indicate that the second client device is ready for a security credential transmission. For example, the security state may be that the second client device is in a "verification boot mode". The security state of the verification boot mode may indicate that the platform firmware and/or operating system of the second client device is authenticated as coming from a known and trusted source. In one example, the security state of the verification startup mode may indicate that all code executing on the second client device has been verified as coming from a known and trusted source tree. As shown at step 410, after retrieving the identifier of the second client device, the identifier may be transmitted to the first client device 120, such as via NFC.
At block 306, user authentication may be performed at the first client device to confirm the request for the secure credential transmission to the second client device. As shown in step 412 of fig. 4, user authentication may be requested after receiving a user confirmation at the second client device. The transmission of the request for user authentication from the second client device may be as a challenge communication using, for example, NFC or another short-range communication protocol. In response to receiving the request, at step 414, the first client device may provide a prompt for user identification input. The prompt may be provided on the display 122 of the first client device. This may facilitate a two-way authentication process, which has the technical advantage of improving the security of the credential transmission. The user identification input may be an existing authentication process on the first client device. For example, a user identification input, such as a password, fingerprint verification, facial recognition, etc., may be used that will unlock the first client device. Once the first client device receives and verifies the user identification input as shown in step 416, user authentication is complete. Optionally, user authentication may be performed at a later stage, such as selecting an account for transfer at block 312 below.
At block 308, device authentication may be performed for the second client device using the identifier of the second client device. The device authentication may be initiated by the first client device after completing the user authentication. As shown in fig. 4 at step 418, the first client device may send a challenge communication to the second client device, where the challenge communication includes at least an identifier of the second client device. In some implementations, the challenge communication can be a combined challenge communication that shows a chain between the current challenge communication and the previous challenge communication. In this case, the chain may be between challenge communication for current device authentication and user authentication performed at block 306. The combined challenge communication may thus include an identifier of the second client device and information related to user authentication.
In response to receiving the challenge communication for device authentication, the second client device may insert a signature including an identifier related to a security state of the second client device. As previously described, the security state of the second client device may be retrieved from hardware of the second client device, such as a trusted security chip. The signature including the identifier is then transmitted to the authentication server in a check request at step 420. In some embodiments where the authentication server is part of the second client device 130, the transmission of the verification request with the signature including the identifier may be performed by calling or referencing the signature including the identifier to the authentication server.
After receiving the verification request, the authentication server verifies the second client device as a secure device using a database of identifiers and device identity information at step 422. As described above, the database of device identity information may be stored in the memory 114 of the authentication server 110 or at a storage system 150 accessible to the one or more processors 112 of the authentication server. The database of device identity information may include known identifiers of the security devices. The second client device is verified as a secure device when the identifier in the signature matches an identifier of a device stored in the database. Further, the verification may also include checking that the identifier in the challenge communication matches the identifier in the signature to ensure that a verification is being performed for the intended client device. The authentication may also include checking that information related to the user identification authentication is from the first client device.
The authentication server then sends a response to the second client device with a confirmation of verification (attestation) and a transport token for the secure credential transmission at step 424. The proof may be a signature comprising an identifier for authenticating the server further inserted in the challenge communication. The transmission token may then be communicated by the second client device to the first client device through challenge communication using the credential updated at step 426.
Based on the updated challenge communication, the first client device may optionally perform an additional check of the attestation of the second client device at step 428. The additional checks may include (i) verifying that the signature of the second client device matches the content in the certificate, and (ii) verifying that the signature of the authentication server includes an identifier of a known authentication server. Performing additional checks may further improve the security and integrity of the device authentication process.
At block 310, user input may be received at the first client device to select an account for the security credential transmission (if the account has not already been selected). The selected account may be a user profile on the first client device. After receiving the transfer token at the first client device and/or after additional verification of the proof, the first client device may provide a prompt for user input regarding account selection at step 430 of fig. 4. A prompt may be provided on the display 122 of the first client device. This may improve the security of the credential transfer process, as the second client device may not be provided with information indicative of the user account until a confirmation is received that the second client device is trustworthy and ready for secure credential transfer. The user input may be received at step 432 and may also include a request for a valid time for a conventional session token for an account. The effective time may be between 15 and 45 minutes, for example 30 minutes. This may facilitate temporary authentication of the user account or profile and associated settings. Such temporary authentication may improve user security by preventing access by third parties at a later time. Optionally, user authentication may be performed at this stage, which may be before or after selecting an account.
At block 312, a secure channel is established between the first client device and the second client device using one or more tokens generated by the authentication server. At step 434 of fig. 4, the first client device may request a temporary token for the selected account from the authentication server. In response, at step 436, the authentication server may transmit the temporary token to the first client device and, when applicable, record the requested validity time of the regular session token. The temporary token may be valid for a relatively short duration, such as between 10 seconds and 30 seconds. The temporary token valid time only needs to be long enough to perform the establishment of the secure channel. Using NFC, a temporary token is transferred from the first client device to the second client device at step 438 and then signed at the second client device. For example, the second client device may sign the temporary token with an identifier from the secure chip. At step 440, the signed temporary token and transport token are transmitted from the second client device to the authentication server to verify the channel between the first client device and the second client device. When the signature/identifier, the temporary token, and the transport token all match the content stored on the authentication server, the authentication server verifies the channel at step 442. The authentication server then provides the second client device with a conventional session token having the requested validity time for the security credential transmission at step 444.
At block 314, the secure credential transfer of the user profile from the first client device to the second client device is completed using the conventional session token. At step 446 of fig. 4, a conventional session token is transmitted from the second client device to the first client device, which then authenticates the second client device as a trusted device for the requested validity time using NFC at step 448. During the validity time span, the second client device is authorized to access the user profile through an application, such as a browser. Alternatively, the first client transmits the user profile to the second client device after the first client receives the regular session token. In some other examples, such as when the user has not specified a validity time, another time period may be utilized in place of the requested validity time. The time period may be a preset time period or may be defined as a time when the first client device is in proximity of a set second client device.
In some alternative examples, in addition to the trusted security chip, a Trusted Platform Module (TPM), security-related instruction code built into the central processing unit, or a Trusted Execution Environment (TEE) solution may provide an identifier of the state or signature of the second client device.
In another example, the first client device may be used by the second client device as an internet gateway for communicating with the authentication server, in the event that the second client device may not have a network connection that allows it to access the authentication server. To this end, the first client device may provide an ephemeral wireless connection to the second client device, transmitting as a proxy to/from the authentication server on behalf of the second client device or by other known means.
Fig. 5 is a flow diagram 500 according to aspects of the present disclosure. More specifically, fig. 5 shows a flow of an example method performed by the one or more processors 112 of the authentication server 110 for authenticating a secure credential transmission from a first client device 120 to a second client device 130.
At block 502, the one or more processors 112 may receive a communication from a first computing device related to initiating a security credential transmission. As described above with respect to steps 402 and 404a, a communication may be triggered based on a user input received at the first computing device, such as a tap in an applet opened on the first computing device.
At block 504, a verification request may be received from a second computing device. The verification request may include a challenge communication carrying: information relating to user authentication, a first identifier from a previous challenge communication, and a signature from the second computing device, the signature including a second identifier relating to a security state of the second computing device. Information relating to user authentication may be obtained as described above with respect to steps 412-416. The first identifier may be obtained as described above with respect to steps 408, 410, and 418.
At block 506, the one or more processors 112 may perform verification of the verification request. As shown in block 506 and described further above with respect to step 422, verifying may include (i) verifying that information relating to user authentication comes from the first computing device, (ii) verifying that the first identifier matches the second identifier, and (iii) verifying that the second identifier matches a device in the device identity information database.
At block 508, the one or more processors 112 may transmit one or more tokens to the first computing device and the second computing device to establish a secure channel for secure credential transmission to the second computing device. In particular, the one or more processors 112 may generate and transmit a first token to a second computing device that includes proof of the verification request. The first token may be a pass token, as described above with respect to steps 424 and 426. The one or more processors 112 may also generate and transmit a second token to the first computing device for the selected user account. As described above with respect to steps 434 and 436, the second token may be a temporary token that is requested by the first client device after receiving user input indicating a selection of a user account. Further, the one or more processors 112 may generate and transmit a third token to the second computing device for establishing a secure channel for the security credential transmission. As described above with respect to steps 442 and 444, the third token may be generated and transmitted after verifying the channel based on the signed temporary token and the transmission token.
The above-described features provide a more secure process to authorize access to user credentials on a client device. By using a client device that has been trusted by the user to authenticate the second client device, the process requires less complex user input and may improve security by removing the need for user credentials that are manually entered on an unknown device. The authentication method does not require the user to enter login information and additional user verification steps, but rather requires the user to request that a particular account be transferred and authenticated on a trusted device. Further, because the process uses the authentication server to verify the second device as a trusted device, the user may have greater confidence in the security of transmitting or accessing the user credentials to the second device. Security may also be improved by the process of mutually authenticating both the first and second client devices prior to any user credential transmission.
Unless otherwise specified, the foregoing alternative examples are not mutually exclusive and may be implemented in various combinations to achieve unique advantages. As these and other variations and combinations of the features discussed above can be utilized without departing from the subject matter defined by the claims, the foregoing description of the embodiments should be taken by way of illustration rather than by way of limitation of the subject matter defined by the claims. Additionally, the provision of examples described herein and clauses phrased as "e.g," "including," and the like, should not be interpreted as limiting the claimed subject matter to the specific examples; rather, the examples are intended to illustrate only one of many possible embodiments. Further, the same reference numbers in different drawings may identify the same or similar elements.
Where the systems discussed herein may collect or may utilize personal information about a user, the user is provided with one or more opportunities to control whether programs or functions collect user information (e.g., passwords, information about the user's social network, user characteristics (age, gender, occupation, etc.), social behaviors or activities, the user's preferences, content created or submitted by the user, or the user's current location). In addition, certain data may be processed in one or more ways prior to storage or use, such that personally identifiable information is removed. For example, the identity of the user may be processed such that personally identifiable information for the user cannot be determined, or the geographic location of the user may be summarized where location information is obtained (such as to a city, zip code, or state level) such that a particular location of the user cannot be determined. Thus, a user may control how information is collected about the user and used by embodiments described herein.

Claims (20)

1. A method for authenticating a secure credential transmission to a device, the method comprising:
receiving, by one or more first processors at a first client device, a user input to initiate a security credential transmission to a second device, the user input triggering a communication to be sent to the second client device;
verifying user identity by:
requesting, by the one or more first processors, a user identification input, an
Receiving, by the one or more first processors, the user identification input;
verifying a device identity of the second client device by:
determining, by one or more second processors of the second client device, a security state of the second client device from hardware of the second client device,
invoking, by the one or more second processors, an identifier associated with the security state of the second client device to an authentication server, and
receiving, by the one or more second processors, from the authentication server, an attestation of the second client device based on the invoked identifier;
receiving, by the one or more second processors, one or more tokens associated with an account for the security credential transmission; and
after verifying the user identity and the device identity, establishing, using the one or more first processors and the one or more second processors, a secure channel between the first client device and the second client device using the one or more tokens for the secure credential transfer.
2. The method of claim 1, wherein the user input to initiate the security credential transmission to a second device comprises a tap input in an applet installed on the first client device.
3. The method of any of claims 1 or 2, wherein the communication is sent from the first client device to the second client device using near field communication.
4. The method of claim 3, further comprising, after the one or more second processors of the second client device receive the communication, requesting, by the one or more second processors, a user confirmation of the security credential transmission to the second device.
5. A method as claimed in any preceding claim, wherein the user identification input is an existing verification of the user identity of the first client device.
6. The method of any preceding claim, wherein the security state of the second client device is determined from a trusted security chip of the second client device.
7. The method of any preceding claim, wherein the attestation from the authentication server indicates that the invoked identifier is associated with a known client device in a database of the authentication server.
8. The method of any preceding claim, further comprising receiving, by the one or more first processors, the attestation for the second client device.
9. The method of any preceding claim, further comprising receiving, by the one or more first processors, a selection of the account for the security credential transmission.
10. The method of any preceding claim, wherein invoking the identifier relating to the security state of the second client device to the authentication server comprises using the first client device as a proxy for invoking the identifier to the authentication server.
11. A non-transitory computer-readable medium configured to store instructions executable by one or more processors, the instructions, when executed, causing the one or more processors to perform a method, the method comprising:
receiving, at a first client device, a user input to initiate a security credential transmission to a second device, the user input triggering a communication to be sent to the second client device;
verifying, at the first client device, a user identity by:
requesting user identification input, an
Receiving the user identification input;
verifying a device identity of the second client device by:
determining, at the second client device, a security state of the second client device from hardware of the second client device,
invoking an identifier associated with the security state of the second client device from the second client device to an authentication server, an
Receiving, at the second client device, an attestation from the authentication server for the second client device based on the invoked identifier;
receiving, from the authentication server, one or more tokens associated with an account for the secure credential transmission; and
after verifying the user identity and the device identity, establishing a secure channel between the first client device and the second client device using the one or more tokens.
12. The media of claim 11, wherein the user input to initiate the security credential transmission to the second device comprises a tap input in an applet installed on the first client device.
13. The medium of any of claims 11 or 12, wherein the communication is sent from the first client device to the second client device using near field communication.
14. The medium of any of claims 11-13, wherein the security state of the second client device is determined according to a trusted security chip of the second client device.
15. The medium of any of claims 11-14, wherein the attestation from the authentication server indicates that the invoked identifier is associated with a known client device in a database of the authentication server.
16. The media of any of claims 11-15, wherein the method further comprises receiving, at the first client device, the attestation for the second client device.
17. The medium of any of claims 11-16, wherein the method further comprises receiving, at the first client device, a selection of the account for the security credential transmission.
18. The medium of any of claims 11-17, wherein invoking the identifier related to the security state of the second client device to the authentication server comprises using the first client device as a proxy for invoking the identifier to the authentication server.
19. A system, comprising:
a memory storing a database of device identity information for a plurality of devices having verified security states; and
one or more processors in communication with the memory, the one or more processors configured to:
receiving, from a first computing device, a communication related to initiating a security credential transmission;
receiving a verification request from a second computing device, the verification request including a challenge communication carrying:
information relating to the authentication of the user,
a first identifier from a previous challenge communication, an
A signature from the second computing device, the signature comprising a second identifier related to a security state of the second computing device;
performing validation of the verification request, comprising:
verifying that the information related to the user authentication is from the first computing device,
verifying that the first identifier matches the second identifier, an
Verifying that the second identifier matches a device in the database of device identity information; and
providing one or more tokens to the first computing device and the second computing device to establish a secure channel for the secure credential transmission to the second computing device.
20. The system of claim 19, wherein the one or more processors are configured to provide the one or more tokens by:
providing, to the second computing device, a first token comprising a proof for the validation request;
receiving, from the first computing device, a selection of a user account;
providing a second token for the user account to the first computing device;
receiving a signed second token from the second computing device; and
providing a third token for establishing a secure channel for the secure credential transmission to the second computing device.
CN202080047653.9A 2019-07-30 2020-07-22 Method and system for authenticating secure credential transmission to a device Active CN114128212B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202410442557.4A CN118199894A (en) 2019-07-30 2020-07-22 Method and system for authenticating secure credential transmission to a device

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16/526,384 2019-07-30
US16/526,384 US11552798B2 (en) 2019-07-30 2019-07-30 Method and system for authenticating a secure credential transfer to a device
PCT/US2020/043042 WO2021021511A1 (en) 2019-07-30 2020-07-22 Method and system for authenticating a secure credential transfer to a device

Related Child Applications (1)

Application Number Title Priority Date Filing Date
CN202410442557.4A Division CN118199894A (en) 2019-07-30 2020-07-22 Method and system for authenticating secure credential transmission to a device

Publications (2)

Publication Number Publication Date
CN114128212A true CN114128212A (en) 2022-03-01
CN114128212B CN114128212B (en) 2024-04-30

Family

ID=71995169

Family Applications (2)

Application Number Title Priority Date Filing Date
CN202080047653.9A Active CN114128212B (en) 2019-07-30 2020-07-22 Method and system for authenticating secure credential transmission to a device
CN202410442557.4A Pending CN118199894A (en) 2019-07-30 2020-07-22 Method and system for authenticating secure credential transmission to a device

Family Applications After (1)

Application Number Title Priority Date Filing Date
CN202410442557.4A Pending CN118199894A (en) 2019-07-30 2020-07-22 Method and system for authenticating secure credential transmission to a device

Country Status (6)

Country Link
US (2) US11552798B2 (en)
EP (1) EP4005177A1 (en)
JP (2) JP7318108B2 (en)
KR (1) KR20220019834A (en)
CN (2) CN114128212B (en)
WO (1) WO2021021511A1 (en)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210119802A1 (en) * 2019-10-21 2021-04-22 Vmware, Inc. Two-way authentication for voice-activated devices
US12015831B2 (en) * 2019-10-23 2024-06-18 Telecom Italia S.P.A. Multimedia content secure access
CN112887260A (en) * 2019-11-30 2021-06-01 华为技术有限公司 Authorization method and device
US11251980B2 (en) 2020-01-22 2022-02-15 Motorola Mobility Llc Electronic devices and corresponding methods for verifying device security prior to use
US11595214B2 (en) * 2020-11-10 2023-02-28 Okta, Inc. Efficient transfer of authentication credentials between client devices
US12021861B2 (en) * 2021-01-04 2024-06-25 Bank Of America Corporation Identity verification through multisystem cooperation
US20240097895A1 (en) * 2021-10-28 2024-03-21 Boe Technology Group Co., Ltd. Device identity authentication method and apparatus, electronic device, and computer-readable medium

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090300744A1 (en) * 2008-06-02 2009-12-03 Microsoft Corporation Trusted device-specific authentication
CN103535090A (en) * 2011-02-15 2014-01-22 黑莓有限公司 System and method for identity management for mobile devices
CN104737176A (en) * 2012-08-10 2015-06-24 奇博德有限公司 System for providing multiple levels of authentication before delivering private content to client devices
CN104823196A (en) * 2012-12-23 2015-08-05 迈克菲股份有限公司 Hardware-based device authentication
CN105378744A (en) * 2013-05-03 2016-03-02 思杰***有限公司 User and device authentication in enterprise systems
CN106664554A (en) * 2014-08-18 2017-05-10 高通股份有限公司 Secure provisioning of an authentication credential
CN107624238A (en) * 2015-05-19 2018-01-23 微软技术许可有限责任公司 To the safe access control of the application based on cloud
US9918226B2 (en) * 2013-12-30 2018-03-13 Apple Inc. Spoofing protection for secure-element identifiers

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7694018B2 (en) * 2002-11-19 2010-04-06 Hewlett-Packard Development Company, L.P. Method and system for communication between two devices by editing machine specific information at a proxy server
JP4760101B2 (en) * 2005-04-07 2011-08-31 ソニー株式会社 Content providing system, content reproducing apparatus, program, and content reproducing method
EP2070248B1 (en) * 2006-09-27 2018-10-10 SecureAuth Corporation System and method for facilitating secure online transactions
US8078873B2 (en) 2008-06-30 2011-12-13 Intel Corporation Two-way authentication between two communication endpoints using a one-way out-of-band (OOB) channel
US20120128154A1 (en) * 2010-11-23 2012-05-24 Intuit Inc. Establishing a secure proximity pairing between electronic devices
GB2506591A (en) * 2012-09-28 2014-04-09 Bell Identification Bv Method of providing secure services using a mobile device
US10123189B2 (en) 2013-03-21 2018-11-06 Razer (Asia-Pacific) Pte. Ltd. Electronic device system restoration by tapping mechanism
EP2997531B1 (en) * 2013-05-15 2019-08-28 Visa International Service Association Methods and systems for provisioning payment credentials
US10756906B2 (en) * 2013-10-01 2020-08-25 Kalman Csaba Toth Architecture and methods for self-sovereign digital identity
US9589263B2 (en) * 2014-06-27 2017-03-07 Paypal, Inc. Automatic payment code display system
US11087572B2 (en) 2015-05-01 2021-08-10 Assa Abloy Ab Continuous authentication
US9602493B2 (en) * 2015-05-19 2017-03-21 Cisco Technology, Inc. Implicit challenge authentication process
US10257171B2 (en) * 2015-09-04 2019-04-09 Ca, Inc. Server public key pinning by URL
AU2017289252A1 (en) * 2016-06-27 2019-02-14 Live Nation Entertainment, Inc. Systems and methods for short-range communication between devices
FR3057689A1 (en) * 2016-10-14 2018-04-20 Safran Identity and Security METHOD AND SYSTEM FOR PROVIDING TOKEN IN A HOST CARD EMULATION SYSTEM HAVING A FIRST AND A SECOND DEVICE
GB2561396B (en) * 2017-04-13 2020-07-15 Barclays Execution Services Ltd Data security using two operating environments operating in parallel
US10833859B2 (en) 2017-12-07 2020-11-10 International Business Machines Corporation Automating verification using secure encrypted phone verification
KR20240024294A (en) * 2018-06-03 2024-02-23 애플 인크. User interfaces for transfer accounts
US11100498B2 (en) * 2018-06-03 2021-08-24 Apple Inc. User interfaces for transfer accounts
US11599627B2 (en) * 2018-12-03 2023-03-07 Bank Of America Corporation System employing smart device for secure and authenticated event execution
US20210019285A1 (en) * 2019-07-16 2021-01-21 Citrix Systems, Inc. File download using deduplication techniques

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090300744A1 (en) * 2008-06-02 2009-12-03 Microsoft Corporation Trusted device-specific authentication
CN103535090A (en) * 2011-02-15 2014-01-22 黑莓有限公司 System and method for identity management for mobile devices
CN104737176A (en) * 2012-08-10 2015-06-24 奇博德有限公司 System for providing multiple levels of authentication before delivering private content to client devices
CN104823196A (en) * 2012-12-23 2015-08-05 迈克菲股份有限公司 Hardware-based device authentication
CN105378744A (en) * 2013-05-03 2016-03-02 思杰***有限公司 User and device authentication in enterprise systems
US9918226B2 (en) * 2013-12-30 2018-03-13 Apple Inc. Spoofing protection for secure-element identifiers
CN106664554A (en) * 2014-08-18 2017-05-10 高通股份有限公司 Secure provisioning of an authentication credential
CN107624238A (en) * 2015-05-19 2018-01-23 微软技术许可有限责任公司 To the safe access control of the application based on cloud

Also Published As

Publication number Publication date
JP7318108B2 (en) 2023-07-31
US20230106348A1 (en) 2023-04-06
KR20220019834A (en) 2022-02-17
US20210036859A1 (en) 2021-02-04
US11552798B2 (en) 2023-01-10
CN118199894A (en) 2024-06-14
WO2021021511A8 (en) 2021-04-01
JP2022542327A (en) 2022-09-30
CN114128212B (en) 2024-04-30
WO2021021511A1 (en) 2021-02-04
EP4005177A1 (en) 2022-06-01
JP2023145552A (en) 2023-10-11

Similar Documents

Publication Publication Date Title
CN114128212B (en) Method and system for authenticating secure credential transmission to a device
JP6992105B2 (en) Query system and method for determining authentication capability
US10404754B2 (en) Query system and method to determine authentication capabilities
US10171241B2 (en) Step-up authentication for single sign-on
US9306754B2 (en) System and method for implementing transaction signing within an authentication framework
US9015482B2 (en) System and method for efficiently enrolling, registering, and authenticating with multiple authentication devices
US9219732B2 (en) System and method for processing random challenges within an authentication framework
JP5928854B2 (en) Method, device and system for managing user authentication
US9083689B2 (en) System and method for implementing privacy classes within an authentication framework
US11539526B2 (en) Method and apparatus for managing user authentication in a blockchain network
KR20180034199A (en) Unified login method and system based on single sign on service
JP6172774B2 (en) Method, device and system for managing user authentication
KR20240075374A (en) System and method for financial transaction service based on authentication using portable device
JP2019129385A (en) Information processing unit, authentication server, authentication control method and authentication control program
KR20170111823A (en) Method, authentication server apparatus and user trtminal for one time password

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant