Device authentication by proxy

Abstract

A software-based authentication protocol that allows a client to accept authentication by a server through a host. The authentication protocol involves the use of variable authentication data that varies to prevent a counterfeit from cloning a genuine client. The host requests the token from the client as certified proof. The client establishes a communication channel with the server using the host as a communication agent. The client provides variable authentication data to the server. If the server determines that the variable authentication data has expired, the client is considered to be counterfeited. If the server determines that the variable authentication data is the latest version, the client is considered as genuine and a token is issued to the client. In accordance with a set of policies, the server alters the variable authentication data and sends new variable authentication data to the client, but does not send new variable authentication data to the counterfeited client.

Description

Background Art

[0001] Many electronic devices (e.g., computers, smart phones, and video game consoles) are used in conjunction with accessory devices (e.g., mice, headphones, game controllers, etc.). As a result, accessory devices represent a large market and have become targets for counterfeiters. Summary of the Invention

[0002] The concepts described herein relate to software-based authentication techniques. For example, communication protocols are described herein for authenticating accessory devices by an authentication service via a proxy device (e.g., a host device). These communication protocols are capable of verifying the genuine license of an accessory device while preventing unauthorized interoperability of counterfeit accessory devices. The proxy device can act as a communication conduit through which the accessory device and the authentication service exchange messages.

[0003] These communication protocols involve the exchange of variable authentication data. Using variable authentication data that changes frequently can combat counterfeiters from creating operable clones of accessories. The present invention can render cloned accessories inoperable, thereby preventing the large-scale production and sale of unauthorized accessories. These communication protocols also involve the use of tokens to authenticate authorized accessories. These tokens can be bound to a specific accessory device and / or a specific host device.

[0004] To demonstrate the implementation and operation of the authentication protocols and techniques, the present invention will be described below in the context of authenticating a game controller (as an example accessory device) by a game console (as an example host device). However, these concepts can be widely applied across various industries to authenticate any type of device, not limited to authenticating controllers in the gaming domain. Brief Description of the Drawings

[0005] The following detailed description refers to the accompanying drawings. The use of like reference numerals in different instances in the specification and the drawings may indicate like or identical items. Example figures are not necessarily drawn to scale.

[0006] Figure 1 Example authentication scenarios are illustrated in which some implementations of the concepts of the present invention can be used to authenticate devices and detect counterfeits.

[0007] Figure 2 Example systems are illustrated that are consistent with some implementations of the concepts of the present invention.

[0008] Figure 3 Example communications are illustrated that are consistent with some implementations of the concepts of the present invention.

[0009] Figure 4 A flowchart of an example authentication server method is illustrated that is consistent with some implementations of the concepts of the present invention.

[0010] Figure 5 A flowchart illustrating an example authentication client method consistent with some implementations of the inventive concept. Specific implementation

[0011] Overview

[0012] Figure 1 An example authentication scenario 100 is illustrated in which some implementations of the inventive concept can be used to authenticate devices and detect forgeries. As mentioned above, the concept will be described in the context of detecting cloned counterfeit game controllers, but the same or similar concepts can be applied to other contexts.

[0013] Figure 1 The illustrated authentication scenario 100 includes one or more game consoles 102. A game console 102 is any electronic device that allows a user to play games using accessories. The game console 102 includes processing capabilities and / or storage capabilities for storing and running games. For example, the game console 102 includes a personal computer (PC), a smart phone, a virtual reality headset, a television, or a typical stand-alone game console.

[0014] The game console 102 includes or is connected to one or more accessory devices (such as a display, a keyboard, a mouse, speakers, headphones, a storage device, a remote control, and a game controller 104) so that a user can interact with the game by providing input and / or receiving output. The game console 102 is connected to the accessory devices either wired (e.g., a universal serial bus (USB) cable) or wirelessly (e.g., Wi-Fi, Bluetooth, infrared, etc.).

[0015] For example, an authentic game controller 104(1) is approved for use with a game console 102(1) to play games. However, a malicious actor clones a counterfeit game controller 104(2) from the authentic game controller 104(1) without authorization and sells it on the market. Traditional techniques cannot distinguish between the authentic game controller 104(1) and the counterfeit game controller 104(2). Therefore, it is necessary to prevent the counterfeit game controller 104(2) from working in cooperation with the game console 102(2) through, for example, an authentication check.

[0016] Technical problem

[0017] A traditional authentication technique involves a game console provider selling hardware security chips to accessory suppliers that produce game controllers. Each security chip includes unique static authentication data, such as a unique certificate and a unique private key. A game controller manufacturer obtains a license for a specific quantity of security chips corresponding to the number of game controllers it plans to produce and sell. Then, the game controller manufacturer installs a security chip in each game controller it produces. Thus, each legitimate game controller contains unique static authentication data.

[0018] When a game controller is connected to a game console, the game console sends a challenge to the security chip inside the game controller. In response, the security chip signs the challenge using the private key and sends the signed challenge back to the game console. Then, the game console uses the certificate and public key stored in the game console to verify the signed challenge sent by the game controller. Thus, the game console can authenticate that the security chip inside the game controller was provided by the game console provider and confirm that the game controller is genuine.

[0019] However, counterfeiters can clone legitimate game controllers without permission, thus manufacturing counterfeit game controllers. For example, malicious actors can crack the security chip, extract the private key, manufacture a counterfeit security chip, and sell counterfeit game controllers that include the counterfeit security chip. Thus, when a counterfeit game controller is connected to a game console, the counterfeit game controller will impersonate a legitimate game controller by deceiving with the same static authentication data stored in a legitimate game controller.

[0020] One technical problem with traditional authentication techniques is that the private key used to authenticate game controllers is a constant. Thus, once a cloned game controller is manufactured using the same static authentication data as a legitimate controller, the game console cannot distinguish between the cloned game controller and the legitimate game controller because they are identical. Thus, there is a technical need to provide an improved authentication paradigm that allows a game console to distinguish between legitimate game controllers and cloned counterfeit game controllers.

[0021] Another technical problem with traditional authentication techniques is the use of hardware security chips. Security chips are vulnerable to manufacturing defects and manufacturing delays (e.g., due to factory closures). A shortage in the supply of security chips can become a bottleneck in the supply chain for manufacturing and selling new game controllers. Thus, there is a need to develop a software-based authentication scheme that can be implemented on general-purpose hardware.

[0022] Technical Solution

[0023] This concept relates to an accessory authentication scheme that supports end-to-end authentication between an accessory and an authentication service through a proxy device. The authentication service, the accessory, and the proxy implement an authentication protocol that can verify legitimate accessories and reject forgeries.

[0024] Referring again to Figure 1 authentication scenario 100 in, the authentication service 106 communicates with the game console 102. Additionally, the authentication service 106 can also communicate with the game controller 104 through the corresponding game console 102 acting as a communication pipeline. In one implementation, the game controller 104(1) provides a command-based interface that enables the game console 102(1) to manage the authentication session and communicate with the authentication service 106.

[0025] In one implementation, the game controller 104(1) initiates communication with the authentication service 106. For example, the game controller 104(1) and the authentication service 106 can establish an encrypted communication channel (e.g., a Transport Security Layer (TSL) connection) through the game console 102(1) by mutually authenticating each other.

[0026] In one implementation, the game console 102(1) requests the game controller 104(1) to provide a token as evidence of its authenticity. The game controller 104(1) uses the encrypted communication channel to request a token from the authentication service 106 by providing variable authentication data (e.g., Controller Authentication Data (CAD) 110) to the authentication service 106. In turn, the authentication service 106 checks with the policy service 108 to determine whether the CAD 110 provided by the game controller 104(1) is valid. The policy service 108 can be implemented on the same or different server hardware as the authentication service 106.

[0027] The policy service 108 maintains an authentication database 114 that stores CADs associated with multiple game controllers, including the CAD 110 associated with the game controller 104(1). The policy service 108 checks whether the CAD 110 provided by the game controller 104(1) matches the CAD 110 stored in the authentication database 114. If the policy service 108 verifies the CAD 110 from the game controller 104(1), the authentication service 106 issues a token to the game controller 104(1). In turn, the game controller 104(1) provides the token to the game console 102(1) as proof of having passed authentication and being allowed to interact with the game console 102(1).

[0028] In accordance with the inventive concept, the policy service 108 stores a set of policies for determining under what circumstances to change the CAD 110 stored in the authentication database 114 and send the changed CAD 110 to the game controller 104(1) for storage and provision in future authentication sessions. If a forged game controller 104(2) copies the old CAD 112 and attempts to authenticate by providing the old CAD 112, the policy service 108 will reject the forged game controller 104(2) because the old CAD 112 does not match the changed CAD 110 in the authentication database 114. Accordingly, the game console 102(2) will restrict the operations of the forged game controller 104(2).

[0029] The policy service 108 can change (e.g., change, update, replace, overwrite, or reset) the CAD 110 periodically (e.g., daily, weekly, etc.) and / or based on certain events (e.g., each time the game controller 104(1) connects to the game console 102(1)), such that a genuine game controller 104(1) storing and providing the latest CAD 110 can be successfully authenticated, while a forged game controller 104(2) storing and providing the old CAD 112 cannot pass the authentication check. Accordingly, the inventive concept can combat forgers by rendering cloned accessories unusable due to the change in the variable authentication data. Various implementations of the inventive concept involving variable authentication data and policies and their technical advantages are described in U.S. Patent Application No. 17 / 848,235, filed on June 23, 2022 (entitled “Authentication Using Variable Data”), the entire content of which is incorporated herein by reference.

[0030] System Devices

[0031] Figure 2 An example system 200 is illustrated that is consistent with some implementations of the inventive concept. The system 200 includes a server 210, a host 230, and a client 250. Although for simplicity of explaining the inventive concept, Figure 2 only one server 210, one host 230, and one client 250 are illustrated, the system 200 can include multiple servers 210, multiple hosts 230, and / or multiple clients 250.

[0032] Server 210 can be implemented in one or more server computers with processing capabilities and storage capacities. Server 210 includes a certificate issuance service 212 that generates and issues a unique certificate including a unique client identifier 215, which will be stored in client 250. In one example implementation, the certificate is globally unique and is formatted using a public key certificate standard (such as the X.509 standard). The certificate can be signed. For example, the provider of host 230 can sign the certificate using its private key. In some cases, an intermediate certification authority ("CA") can sign the certificate using its private key. Server 210 includes a certificate database 214 for storing multiple client identifiers associated with multiple clients. For example, certificate database 214 stores client identifier 215 associated with client 250.

[0033] Server 210 includes a policy service 108. Policy service 108 stores policies related to authentication. Based on these policies, policy service 108 decides whether to authenticate or reject client 250 and whether to generate and / or change variable authentication data 219 (such as Figure 1 CAD 110 in). Policy service 108 generates variable authentication data 219 and issues it to client 250. Policy service 108 also checks the variable authentication data 219 provided by client 250 to authorize or reject client 250's use with host 230.

[0034] Alternatively, variable authentication data 219 can include randomly or arbitrarily generated numbers and / or strings, such as random numbers. Alternatively or additionally, variable authentication data 219 can include timestamps, serial numbers, and / or signatures. In the example context where client 250 is a game controller 104(1), variable authentication data 219 includes CAD 110. Variable authentication data 219 can have a fixed size (e.g., 1KB or 4KB) or a variable size. In one implementation, variable authentication data 219 is formatted and stored as a binary large object (blob). Variable authentication data 219 can be opaque to client 250 and host 230. That is, client 250 and host 230 do not read or interpret variable authentication data 219. Client 250 and host 230 can only receive, store, provide, and / or relay variable authentication data 219.

[0035] Server 210 includes an authentication database 114 for storing variable authentication data 219 generated and issued by policy service 108. In one implementation, the variable authentication data 219 is stored in association with a client identifier 215 of a client 250 to which the variable authentication data 219 is issued. Thus, the policy service 108 knows the client identifiers of multiple clients and their assigned variable authentication data in order to perform authentication checks.

[0036] Consistent with some implementations of the inventive concept, if client 250 provides the correct variable authentication data 219 that policy service 108 most recently issued to client 250, then policy service 108 authenticates client 250. For example, policy service 108 issues new variable authentication data 219 to client 250 for the new variable authentication data 219 to be stored and provided in future authentication checks. Depending on the policy, the variable authentication data 219 may be updated periodically (e.g., hourly, daily, weekly, monthly, etc.) and / or updated according to specific events (e.g., each authentication check, expiration of a time period, client 250 connecting to another host, etc.). In one implementation, the validity period of the variable authentication data 219 is set by the policy. Such policies maintained by policy service 216 may be adjusted. If client 250 provides expired authentication data (such as Figure 1 the old CAD 112 in), then policy service 108 will reject a request to authenticate client 250.

[0037] In some implementations, policy service 108 stores multiple variable authentication data associated with each client identifier 215 in authentication database 114. For example, authentication database 114 may store the two most recent variable authentication data of each client identifier 215 in a first-in, first-out manner. Thus, even if client 250 provides the second most recent variable authentication data instead of the most recent variable authentication data, policy service 108 will authenticate client 250. This setting allows policy service 108 to flexibly handle errors and / or failures that may occur when client 250 receives updated variable authentication data 219 over the network and / or writes the updated variable authentication data 219 to the authentication data store 254. Alternatively, three or more of the most recent variable authentication data 219 may be stored in association with each client identifier 215 in authentication database 114, and client 250 may provide any one of the multiple stored variable authentication data 219 for authentication.

[0038] Server 210 includes an authentication service 106. The authentication service 106 generates and issues a token to the client 250 in response to the verification of the variable authentication data 219 provided by the client 250 by the policy service 108. The token can be signed by the authentication service 106 before being sent to the client 250. In addition to being specifically assigned to the client 250, the token can also be specifically associated with the host 230 so that the client 250 can use the token to interoperate with the host 230 but not with other hosts. The authentication service 106 can also check and verify the token to confirm that the token is issued by the authentication service 106. For example, the authentication service 106 can check and confirm that the token is signed by the authentication server 106.

[0039] Although Figure 2 the certificate issuance service 212, the certificate database 214, the policy service 108, the authentication database 114, and the authentication service 106 are illustrated as being included in the server 210, other configurations can also be adopted. For example, the certificate issuance service 212, the certificate database 214, the policy service 108, the authentication database 114, and the authentication service 106 can be included in different servers (as Figure 1 shown) and / or included in different storage devices. In other implementations, the certificate database 214 and / or the authentication database 114 can be remote from the server 210.

[0040] The client 250 can be any device, accessory, or item that can be authenticated. For example, the client 250 can include a genuine game controller 104(1), a display, a keyboard, a mouse, speakers, headphones, a hard disk, removable storage, a card, a key, a badge, a remote control, glasses, a head-mounted device, etc. Although Figure 2 the client 250 is illustrated as a hardware device, the client 250 can be a software module capable of executing an authentication protocol.

[0041] In some implementations, all or part of the functions of the client 250 (such as the ability to cooperate with the host 230) will be restricted unless or until the client 250 is authenticated by the policy service 108. The host 230 can include enforcement policies that determine which functions of the client 250 are enabled or disabled based on whether the client 250 can be authenticated. In one implementation, the client 250 includes a certificate store 252 for storing a certificate including a client identifier 215. The client 250 also includes an authentication data store 254 for storing variable authentication data 219.

[0042] The certificate stored in the certificate store 252 of the client 250 is issued by the certificate issuance service 212 of the server 210. In some implementations, the certificate is stored in the client 250 during the manufacture of the client 250 and the certificate does not change.

[0043] The variable authentication data 219 stored in the authentication data store 254 of the client 250 is issued by the policy service 108 of the server 210. In one embodiment, whenever the policy service 108 issues new variable authentication data 219 to the client 250, the client 250 writes the new variable authentication data 219 to the authentication data store 254 so that the variable authentication data 219 stored in the client 250 and the server 210 can be synchronized. In one embodiment, when new variable authentication data 219 is written to the client 250, any old variable authentication data is replaced (e.g., deleted, discarded, overwritten, etc.). In some implementations, the client 250 stores two or more variable authentication data 219 in the authentication data store 254. For example, the authentication data store 254 has two slots that can store the two most recent variable authentication data 219 received by the client 250 from the server 210, e.g., on a first-in, first-out basis. Thus, the client 250 can provide the two stored variable authentication data 219 to the server 210, and the policy service 108 authenticates the client 250 based on any one of the two provided variable authentication data 219 that matches one or more of the most recent variable authentication data 219 stored in the authentication database 114 of the server 210.

[0044] These implementations that store multiple variable authentication data 219 provide resilience and robustness against errors and / or failures that may occur when the client 250 receives updated variable authentication data 219 over the network, writes the updated variable authentication data 219 to the memory, and / or data corruption occurs after the variable authentication data 219 has been stored. For example, the client 250 may erroneously disconnect from the network and lose connection with the server 210, the client 250 may encounter an error when writing the most recent variable authentication data 219 to the authentication data store 254, or the client 250 may experience an unexpected power outage. In addition, flash data corruption may cause the variable authentication data 219 stored in the client 250 to be unavailable for authentication. These errors, as well as any other errors, may cause the client 250 to fail to authenticate successfully, e.g., during the next authentication session. By storing multiple variable authentication data 219, the client 250 is better able to handle errors and still be able to pass future authentication checks.

[0045] In one implementation, the client 250 is manufactured without any variable authentication data 219. When the client 250 attempts authentication for the first time, the policy service 108 issues its first variable authentication data 219 to the client 250. If a forger is able to extract the variable authentication data 219 to create multiple clones (e.g., forging the game controller 104(2)), those clones will not be able to authenticate through the policy service 108 because the variable authentication data 219 may have changed by the time the clones attempt to authenticate using the old variable authentication data (e.g., the old CAD 112).

[0046] The client 250 also includes a token store 256 for storing the token received from the authentication service 106 of the server 210 after a successful authentication check. The client 250 can provide the token from the token store 256 to the host 230 as proof of successful authentication.

[0047] The host 230 can include any computer, device, apparatus, machine, or accessory that can work with the client 250. For example, the host 230 can include a game console 102(1), a PC, a TV, a tablet, a smart phone, etc. Although Figure 2 the host 230 is illustrated as a hardware device, the host 230 can be a software module (e.g., an application, a program, an operating system, firmware, etc.) for authenticating the client 250.

[0048] In accordance with some implementations of the inventive concept, the host 230 attempts to authenticate the client 250 using the policy service 108 of the server 210. For example, the host 230 requests a token from the client 250 as proof of successful authentication.

[0049] In some implementations, the host 230 facilitates communication between the client 250 and the server 210 to perform an authentication check. That is, the host 230 acts as a proxy or intermediary that supports the communication channel between the client 250 and the server 210.

[0050] Depending on whether the authentication attempt made by the client 250 is successful or not, the host 230 can enforce one or more policies based on the authentication result, e.g., by enabling or disabling certain functions of the client 250. That is, the host 230 has the ability to run the client 250 in one or more operating modes.

[0051] The server 210, the host 230, and the client 250 may each include a personal computer, a desktop computer, a server computer, a laptop computer, a cellular phone, a smart phone, a personal digital assistant, a tablet or tablet-type computer, a mobile computer, a camera, a home appliance, a virtual reality headset, a video game console, a controller, a smart device, an Internet of Things device, a vehicle, a watch, a wearable device, a set-top box, a gaming system, an automotive entertainment or navigation console, a coffee maker, etc., and / or various evolving or yet-to-be-developed electronic devices. The number of devices described and shown in this specification and the relationship between the device client and server sides are for illustrative purposes only and are not restrictive.

[0052] The server 210, the host 230, and the client 250 may communicate with each other via wired (e.g., USB, Ethernet, etc.), wirelessly (e.g., Wi-Fi, Bluetooth, infrared, near field communication, etc.), and / or via one or more networks, including the Internet. For example, the server 210, the host 230, and / or the client 250 include a communication module (such as a radio chip) that may communicate using one or more communication protocols.

[0053] As used herein, the terms "device", "computer", or "computing device" may refer to any type of device having a certain amount of processing power and / or storage capacity. The processing power may be provided by one or more hardware processors that may execute data in the form of computer-readable instructions to provide functionality. Data (such as computer-readable instructions and / or user-related data) may be written on storage, such as storage that may be internal or external to the device. Storage may include volatile or non-volatile memory, a hard disk drive, a flash storage device, and / or an optical storage device (e.g., CD, DVD, etc.), remote storage (e.g., a USB drive or cloud-based storage), and any one or more of others. The term "computer-readable medium" as used herein may include an instantaneous propagation signal or carrier wave. In contrast, a "computer-readable storage medium" does not include an instantaneous propagation signal and carrier wave. A computer-readable storage medium may include a "computer-readable storage device". Examples of computer-readable storage devices include volatile storage media such as RAM, non-volatile storage media such as hard disk drives, optical discs, and flash memories, and others.

[0054] Figure 2Shows two example device configurations 270, which can be used by any one or all of the server 210, the host 230, and the client 250. The first configuration 270(1) represents an operating system (OS)-centric configuration. The second configuration 270(2) represents a system-on-chip (SoC) configuration. The first configuration 270(1) can be organized into one or more applications 272, an operating system 274, and hardware 276. The second configuration 270(2) can be organized into shared resources 278, dedicated resources 280, and an interface 282 therebetween.

[0055] Any configuration 270 can include a memory 284 and a processor 286. For example, the storage 284 in the server 210 includes a certificate database 214 and / or an authentication database 114, while the storage 284 in the client 250 includes a certificate store 252 and / or an authentication data store 254.

[0056] The configuration 270 also includes an authentication module 288 for implementing the communication protocols described herein. For example, the authentication module 288 in the server 210 implements a certificate issuance service 212, a policy service 108, and an authentication service 106. The authentication module 288 in the host 230 enables a direct communication channel and relays messages between the client 250 and the server 210, initiates an authentication check, requests the client 250 to provide a token as proof of authenticity, confirms the validity of the token to the server 210, and enforces the authentication result by placing the client 250 in one or more operating modes. The authentication module 288 in the client 250 stores variable authentication data 219 received from the server 210, submits the variable authentication data 219 to the server 210 for authentication, and submits the token to the host 230.

[0057] As mentioned above, the second configuration 270(2) includes an SoC-type design, which can be integrated on a single SoC or multiple coupled SoCs. One or more processors 286 can be configured to coordinate with shared resources 278 (such as the storage 284, etc.), and / or with one or more dedicated resources 280 (such as hardware blocks configured to perform certain specific functions). Therefore, the term "processor" as used herein may also refer to a central processing unit (CPU), a graphics processing unit (GPU), a controller, a microcontroller, a processor core, or other types of processing devices, as well as integrated circuits.

[0058] In general, any functionality described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), or any combination of these implementations. As used herein, the term "component" or "module" generally refers to software, firmware, hardware, an entire device or network, or any combination thereof. For example, in the case of a software implementation, these terms can represent program code that, when executed on a processor (e.g., one or more CPUs), performs a specified task. The program code can be stored in one or more computer-readable memory devices, such as a computer-readable storage medium. The various features and techniques of a component or module can be platform-independent, meaning that they can be implemented on a variety of commercial computing platforms having various processing configurations.

[0059] Figure 2 The system 200 illustrated in [reference] is merely an example. The system 200 does not have to include all of the example elements described in conjunction with Figure 2 The system 200 can also include other elements not explicitly described in conjunction with Figure 2 reference.

[0060] Communication

[0061] Figure 3 illustrates example communications consistent with some implementations of the inventive concept. In conjunction with Figure 3 reference, an example communication sequence (e.g., messages exchanged) between the controller 104(1), the console 102(1), the authentication service 106, and the policy service 108 during the performance of an authentication check will be described. In these examples, the controller 104(1) is an example of a client 250 that is being authenticated to prevent forgery, and the console 102(1) is an example of a host 230 that acts as a communication proxy. However, other types of clients and hosts can perform the same or similar communications. The message names and the names of the payloads within the messages described below are merely examples. Other names can be used and serve the same purpose or function. Any of the above communications can be sent and received using or involving any communication technology or protocol, such as Representational State Transfer (REST), Transport Layer Security (TLS), JavaScript Object Notation (JSON), etc.

[0062] Even before sequence 1, if the user starts the controller 104(1) and connects it to the console 102(1) either wired or wirelessly, the controller 104(1) and the console 102(1) will initiate communication with each other. For example, the controller 104(1) and the console 102(1) can perform a handshake and / or any authentication using their certificates.

[0063] In Sequence 1, the console 102(1) requests a token from the controller 104(1). Sequence 1 can be initiated when the console 102(1) determines that it wishes to authenticate the controller 104(1) (e.g., the controller 104(1) has a valid license), because an event has triggered the console 102(1) to test the authenticity of the controller 104(1). For example, the console 102(1) powers on, the controller 104(1) powers on, the controller 104(1) connects to the console 102(1), the user initiates a function of the console 102(1) (e.g., by starting a game), or any other event that may cause the console 102(1) to request a valid token from the controller 104(1).

[0064] In one implementation, the token is an accessory token ("AToken") for authenticating the authenticity of an accessory device. For example, the console 102(1) requests that the controller 104(1) provide a valid AToken by sending a RequestAToken message to the controller 104(1). The RequestAToken message can include a payload (e.g., variables, parameters, settings, flags, etc.). For example, the RequestAToken message includes the ConsoleID, which is an identifier of the console 102(1). The RequestAToken message can also include the identity of the authentication service 106 (e.g., hostname, address, etc.).

[0065] In some cases, the controller 104(1) has received and cached an AToken from a previous authentication session, and the controller 104(1) can simply return the cached AToken to the console 102(1) (e.g., Sequence 7). If the controller 104(1) does not have an AToken (or the cached AToken has expired, is invalid, or is not accepted by the console 102(1)), then the controller 104(1) requests an AToken from the authentication service 106.

[0066] In Sequence 2, the controller 104(1) and the authentication service 106 perform mutual authentication and establish a communication channel. Sequence 2 represents a plurality of messages exchanged between the controller 104(1) and the authentication service 106 through the console 102(1) acting as a communication proxy.

[0067] In fact, the controller 104(1) exchanges messages with the console 102(1), and the console 102(1) exchanges messages with the authentication service 106. However, since the console 102(1) relays messages between the controller 104(1) and the authentication service 106, logically, the controller 104(1) and the authentication service 106 can be considered to be exchanging messages with each other. The messages exchanged between the controller 104(1) and the authentication service 106 can be opaque to the console 102(1). The console 102(1) may only forward (or pass) these messages. For example, the controller 104(1) and the authentication service 106 can send a SetPassThroughData message to the console 102(1). The payload of the SetPassThroughData message can be a substantial message intended for the ultimate recipient, and the console 102(1) will pass the substantial message to the ultimate recipient.

[0068] In one implementation, the controller 104(1) and the authentication service 106 use the TLS protocol to establish an encrypted communication channel. As explained above, the controller 104(1) can initiate a communication session with the authentication service 106 through the console 102(1). For example, the controller 104(1) and the authentication service 106 exchange server certificates and client certificates including the AccessoryID. The AccessoryID is a unique accessory identifier associated with the controller 104(1), such as the client identifier 215. After the encrypted communication channel is established in sequence 2, the messages between the controller 104(1) and the authentication service 106 will be sent through this communication channel (i.e., through the console 102(1)).

[0069] In sequence 3, the controller 104(1) uses this communication channel to request an AToken from the authentication service 106. For example, the controller 104(1) sends a GetATokenRequest message to the authentication service 106. In one implementation, the GetATokenRequest (obtain AToken request) message includes a CAD blob (e.g., Figure 1 the CAD 110 in). In another implementation, the GetATokenRequest message includes two CAD blobs. In the case where the controller 104(1) requests authentication for the first time and has not been issued a CAD blob before, the GetATokenRequest message will include a meaningless CAD blob. The GetATokenRequest message can also include the ConsoleID (console ID) that the console 102(1) sent to the controller 104(1) in sequence 1.

[0070] In Sequence 4, the authentication service 106 checks with the policy service 108 to authenticate the controller 104(1). For example, the authentication service 106 sends an IsAccessoryAllowed message to the policy service 108. In one implementation, the IsAccessoryAllowed message includes the AccessoryID obtained by the authentication service 106 from the controller 104(1) during mutual authentication in Sequence 2. The IsAccessoryAllowed message may also include one or more CAD blobs that were included in the GetATokenRequest message in Sequence 3.

[0071] In accordance with the current concept, the policy service 108 maintains an authentication database 114 that includes the AccessoryID and associated CAD blobs. Thus, upon receiving the IsAccessoryAllowed message, the policy service 108 checks the authentication database 114 to determine whether to allow or deny the controller 104(1). The policy service 108 also stores a set of policies for determining the authentication result.

[0072] There may be several possible replacement results. If one or more of the CAD blobs and the AccessoryID in the IsAccessoryAllowed message do not match the CAD blobs and the AccessoryID in the authentication database 114, the policy service 108 determines the controller 104(1) to be a forgery and rejects it (see Figure 3 Replacement Option 3). If one or more of the CAD blobs and the AccessoryID in the IsAccessoryAllowed message match the CAD blobs and the AccessoryID in the authentication database 114, the policy service 108 allows the controller 104(1).

[0073] If the controller 104(1) is allowed, the policy service 108 further checks the policies to determine whether a new CAD blob should be generated and issued to the controller 104(1). For example, the policy can be set to issue a new CAD blob each time the controller 104(1) attempts authentication, or after a certain period of time (e.g., 24 hours, one week, etc.) has elapsed since the last successful authentication. Additionally or alternatively, if the controller 104(1) is connected to a different console, the policy may require an update of the CAD blob. If the policy determines that the CAD blob should be updated, the policy service 108 issues a new CAD blob to the controller 104(1) ( Figure 3 Replacement Option 2). Otherwise, the policy service 108 only authenticates the controller 104(1) without updating the CAD blob ( Figure 3 Replacement Option 1).

[0074] In addition, in the case where the controller 104(1) makes a first attempt at authentication, the policy service 108 can check the authentication database 114 to confirm that the AccessoryID provided in the IsAccessoryAllowed message does not exist in the authentication database 114 of the policy service 108. After confirming that this is the first authentication attempt of the controller 104(1) or that the controller 104(1) has not been issued a CAD blob previously, the policy service 108 generates a new CAD blob and issues it to the controller 104(1) ( Figure 2 Replacement Option 2 in

[0075] In Figure 3 there are three possible communication replacement sequences after sequences 1 - 4. Replacement Option 1 includes sequences 5 - 9, Replacement Option 2 includes sequences 10 - 12, and Replacement Option 3 includes sequences 13 - 15. These replacement options will be explained below.

[0076] In Replacement Option 1, the policy service 108 has determined that the controller 104(1) has provided the most recent CAD blob that is synchronized with the CAD blob stored in the authentication database 114 and has determined that the CAD blob in the controller 104(1) does not need to be updated. Thus, in sequence 5, the policy service 108 sends an AccessoryIsAllowed message to the authentication service 106. The AccessoryIsAllowed message in sequence 5 is one of the possible responses to the IsAccessoryAllowed message in sequence 4.

[0077] In response, the authentication service 106 generates an AToken as evidence that the controller 104(1) has successfully passed the authentication check. In one implementation, the AToken is a JSON Web Token (JWT) and is signed with the private key of the authentication service 106. In some implementations, the AToken is generated based on certain information (e.g., in fields), such as the AccessoryID of the controller 104(1), the issue time of the AToken, the expiration time of the AToken, the ConsoleID of the console 102(1), and / or the issue time of the CADblob. If the AToken includes the ConsoleID of the console 102(1), the AToken authorizes the controller 104(1) to be used with that specific console 102(1). Thus, if a forger copies the AToken and attempts to use the copied AToken to interoperate a forged controller 104(2) with another console 102(2), the attempt will fail. In one implementation, the AToken is opaque to the console 102(1) and the controller 104(1), such that they cannot view the content of the AToken. In addition to the AToken described herein, the authentication service 106 may use other techniques to convey to the console 102(1) the information that the controller 104(1) has successfully passed authentication.

[0078] In sequence 6, the authentication service 106 provides the AToken to the controller 104(1) as proof of successful authentication. For example, the authentication service 106 sends a GetATokenSuccess message to the controller 104(1) that includes the AToken as a payload. The GetATokenSuccess message in sequence 6 is one of the possible responses to the GetATokenRequest message in sequence 3.

[0079] In sequence 7, the controller 104(1) provides the AToken received from the authentication service 106 to the console 102(1) as proof of successful authentication. For example, the controller 104(1) sends a RequestATokenSuccess message to the console 102(1). The RequestATokenSuccess message includes the AToken within the GetATokenSuccess message in sequence 6. The RequestATokenSuccess message in sequence 7 is one of the possible responses to the RequestAToken message in sequence 1.

[0080] After receiving the AToken, the console 102(1) will verify the AToken through the request authentication service 106 (for example, using the API service provided by the authentication service 106) to confirm that the controller 104(1) is genuine. In sequence 8, the console 102(1) sends a ValidateAToken (Verify AToken) message to the authentication service 106. The ValidateAToken message includes the AToken that the console 102(1) received from the controller 104(1) within the RequestATokenSuccess message in sequence 7.

[0081] After receiving the ValidateAToken message, the authentication service 106 will confirm that the AToken in the ValidateAToken message was indeed issued by the authentication service 106. In one implementation, the authentication service 106 checks the signature of the AToken to confirm that the AToken has been correctly signed by the authentication service 106 and was indeed issued by it. This implementation does not require the authentication service 106 to maintain a database of ATokens.

[0082] After confirming that the AToken is valid, in sequence 9, the authentication service 106 will notify the console 102(1) that the AToken is valid. For example, the authentication service 106 will send an AtokenValid (Atoken is valid) message to the console 102(1). The AtokenValid message in sequence 9 is one of the possible responses to the ValidateAToken message in sequence 8. However, if the authentication service 106 determines that the Atoken is invalid, the authentication service 106 will send an AtokenInvalid (Atoken is invalid) message to the console 102(1).

[0083] Depending on whether the console 102(1) receives an AtokenValid message or an AtokenInvalid message from the authentication service 106, the console 102(1) will accept the controller 104(1) as genuine or reject the controller 104(1) as counterfeit. The console 102(1) includes a mandatory policy for determining the consequences of a successful or failed authentication check. For example, the controller 104(1) can be completely disabled, made to run in a restricted mode with limited functionality, or allowed to run fully with all features enabled. The completion of sequence 9 can end a successful authentication session. In addition to using the AToken to confirm the genuineness of the controller 104(1) to the console 102(1), the same AToken can be used to prove the genuineness of the controller 104(1) to other devices or services.

[0084] In replacement scenario 2, the policy service 108 has determined that the controller 104(1) has provided the most recent CAD blob that is synchronized with the CAD blob stored in the authentication database 114, and has determined that the CAD blob in the controller 104(1) is to be updated. Alternatively, the policy service 108 has determined that the controller 104(1) has not been issued any CAD blobs previously (e.g., the controller 104(1) is attempting authentication for the first time). The policy service 108 generates a new CAD blob and associates it with the AccessoryID in the authentication database 114. If the authentication database 114 already includes one or more existing CAD blobs associated with the AccessoryID, the policy service 108 replaces the existing CAD blob (or one of the existing CAD blobs) with the new CAD blob. In the case where the AccessoryID does not exist in the authentication database 114, the policy service 108 adds the controller ID along with the new CAD blob to the authentication database 114.

[0085] The policy service 108 persists the new CAD blob until the new CAD blob is replaced by a more recent CAD blob. Thus, the next time the policy service 108 receives an authentication request from the controller 104(1) providing the correct most recent CAD blob, the policy service 108 can ensure that the controller 104(1) is the same physical device that was previously issued the most recent CAD blob.

[0086] In one implementation, the policy service 108 stores one CAD blob for each AccessoryID. Thus, storing the new CAD blob will overwrite any old CAD blobs that were previously stored in the authentication database 114. Alternatively, the policy service 108 stores multiple CAD blobs for each AccessoryID, e.g., two, three, or any number of the most recently generated CAD blobs associated with the AccessoryID of the controller 104(1). Storing variable CAD blobs can protect against any potential errors that occur when the controller 104(1) receives and / or writes CAD blobs.

[0087] In sequence 10, the policy service 108 sends a WriteNewCad (write new CAD) message to the authentication service 106. The WriteNewCad message includes a new CAD blob. If the controller 104(1) includes multiple slots for storing multiple CAD blobs, the WriteNewCad message will include a SlotNumber, which can be a numerical value (such as 0, 1, 2, 3, etc.) used to indicate which slot the new CAD blob should be written to. The WriteNewCad message in sequence 10 is one of the possible responses to the IsAccessoryAllowed message in sequence 4.

[0088] After receiving the new CAD blob from the policy service 108, the authentication service 106 forwards the new CAD blob to the controller 104(1). For example, the authentication service 106 sends a GetATokenReplaceCad (get an Atoken to replace Cad) message to the controller 104(1). The GetATokenReplaceCad message in sequence 11 includes the new CAD blob within the WriteNewCad message in sequence 10. If the controller 104(1) has multiple slots for storing multiple CAD blobs, the GetATokenReplaceCad message will include the SlotNumber included in the WriteNewCad message in sequence 10. The GetATokenReplaceCad message in sequence 11 is one of the possible responses to the GetATokenRequest message in sequence 3.

[0089] The controller 104(1) receives the GetATokenReplaceCad message and stores the new CAD blob in the memory. If the GetATokenReplaceCad message includes a SlotNumber, the controller 104(1) will store the new CAD blob in the slot indicated by the SlotNumber. If the controller 104(1) receives a new CAD blob for the first time, the controller 104(1) simply stores the new CAD blob in the memory. Otherwise, storing the new CAD blob will replace the existing CAD blob stored in the controller 104(1). The existing CAD blob has expired, that is, it is out of sync with the new CAD blob stored in the authentication database 114 of the policy service 108 and thus can no longer be used for successful authentication of the controller 104(1) in the future. Instead, the new CAD blob is up-to-date (i.e., in sync with the CAD blob stored in the authentication database 114 of the policy service 108) and thus can be used for successful authentication of the controller 104(1) later.

[0090] Optionally, in sequence 12, the controller 104(1) notifies the console 102(1) that the CAD blob is being replaced. For example, the controller 104(1) sends a ReplacingCad (Replace Cad) message to the console 102(1). The ReplacingCad message in sequence 12 is one of the possible responses to the RequestAToken message in sequence 1. The ReplacingCad message in sequence 12 is an optional message that need not be sent.

[0091] After replacement scenario 2 (i.e., sequence 11 and / or sequence 12), the controller 104(1) repeats sequence 3 and sends another GetATokenRequest message to the authentication service 106 that includes the new CAD blob. Sequence 3 can be repeated by continuing to use the same communication channel established in the previous iteration of sequence 2, or another iteration of sequence 2 can be performed to establish a new communication channel for the repeated iteration of sequence 3. Then, sequences 4 - 9 will also be repeated. The repeated execution of sequences 3 - 4, where the controller 104(1) returns the new CAD blob to the policy service 108 that has issued the new CAD blob to the controller 104(1), ensures that the new CAD blob has been successfully transferred from the policy service 108 to the controller 104(1) and has been successfully written and persisted in the memory of the controller 104(1). There is no need to send a separate dedicated acknowledgement message from the controller 104(1) to the policy service 108 to confirm that the new CAD blob has been successfully received and written, and the repeated GetATokenRequest that includes the new CAD blob can be used as an acknowledgement.

[0092] The above communication can be repeated the next time the controller 104(1) is powered on or connected to the console 102(1). For example, sequences 1 - 9 (or sequences 1 - 4, 10 - 12, and 3 - 9) can be executed to successfully authenticate the controller 104(1) because the CAD blob provided by the controller 104(1) in sequence 3 will be the most recent CAD blob that matches the CAD blob in the authentication database 114 of the policy service 108. Additionally, in sequence 10, the policy service 108 issues an even newer CAD blob to the controller 104(1). Consistent with the inventive concept, changing the CAD blob causes the forged controller 104(2) to fail authentication.

[0093] A forger can create one or more cloned controllers that have the same certificate as the controller 104(1) (and thus the same AccessoryID). However, the cloned controllers will not be able to successfully authenticate through the policy service 108 because the cloned controllers cannot provide the most recent CAD blob that the policy service 108 has issued to the controller 104(1).

[0094] In replacement scenario 3, the policy service 108 has determined that the CAD blob provided by the controller 104(1) is expired and does not match the most recent CAD blob stored in the authentication database 114. Accordingly, the policy service 108 rejects the controller 104(1) as a forgery.

[0095] Accordingly, in sequence 13, the policy service 108 notifies the authentication service 106 that the controller 104(1) has been rejected. For example, the policy service 108 sends an AccessoryIsRejected message to the authentication service 106. The AccessoryIsRejected message in sequence 13 is one of the possible responses to the IsAccessoryAllowed message in sequence 4.

[0096] In sequence 14, the authentication service 106 relays a message that the authentication attempt has failed to the controller 104(1). For example, the authentication service 106 sends a GetATokenRejected message to the controller 104(1). The GetATokenRejected message in sequence 14 is one of the possible responses to the GetATokenRequest message in sequence 3.

[0097] In sequence 15, the controller 104(1) notifies the console 102(1) that the attempt to authenticate and obtain a valid AToken has failed. For example, the controller 104(1) sends a RequestATokenFailed message to the console 102(1). The RequestATokenFailed message in sequence 15 is one of the possible responses to the RequestAToken message in sequence 1. In some implementations, one or more of the AccessoryIsRejected message in sequence 13, the GetATokenRejected message in sequence 14, and the RequestATokenFailed message in sequence 15 include an error code for indicating the reason for the failed authentication attempt. Completion of sequence 15 can end the unsuccessful authentication session.

[0098] In some implementations, if the console 102(1) receives a RequestATokenFailed message from the controller 104(1), or if the controller 104(1) fails to respond to a RequestAToken message, the console 102(1) attempts to determine whether the failure is due to a fault in the controller 104(1) or a fault in the authentication service 106. For example, the controller 104(1) may fail to obtain a valid AToken because the controller 104(1) is a counterfeit that provided an expired CAD blob, or because the authentication service 106 is unavailable (e.g., unresponsive).

[0099] For example, after receiving a RequestATokenFailed message from the controller 104(1), the console 102(1) sends a CheckServiceStatus (check service status) message to the authentication service 106. If the authentication service 106 responds with a ServiceHealthy (service healthy) message, the console 102(1) notifies the user that the controller 104(1) is an unauthorized accessory and / or the certificate is invalid.

[0100] Alternatively, if the authentication service 106 fails to respond to the CheckServiceStatus message or responds with an error message (or any other indication of degraded performance of the authentication service 106 and / or the policy service 108), the console 102(1) ignores the failed authentication attempt of the controller 104(1). In this case, the console 102(1) allows the controller 104(1) to operate as if it had successfully passed authentication until the authentication service 106 returns to normal. For example, the console 102(1) can periodically (e.g., hourly, daily, etc.) retry sending a CheckServiceStatus message to the authentication service 106 until a ServiceHealthy message is received. This scenario allows the controller 104(1) to operate even if the authentication service 106 and / or the policy service 108 are experiencing an outage, are temporarily offline for regular maintenance, or are unable to authenticate any accessories for some reason.

[0101] Flow

[0102] Figure 4 Illustrates a flowchart of an example authentication server method 400 consistent with some implementations of the inventive concept. The authentication server method 400 is for illustrative purposes only and is not exhaustive or restrictive. The various actions in the authentication server method 400 can be performed in the order shown, in a different order, in parallel or simultaneously, can be omitted, repeated, or intermediate actions can be included between the actions.

[0103] In operation 402, a communication channel is established between the host and the client. In one implementation, the client initiates contact to request communication. Although the communication channel is logically used to exchange messages with the client, in practice, the communication channel is implemented by the host acting as a proxy for relaying messages to the client. That is, messages originally intended for the client are actually sent to the host, and the host forwards the messages to the client. Also, messages from the client are actually received from the host that has forwarded the messages from the client. The communication channel can be an encrypted channel. Establishing the communication channel may involve exchanging certificates. For example, receiving a client certificate that includes a client identifier associated with the client.

[0104] In operation 404, a request for a token is received from the client. The request is received via the communication channel established in operation 402. The token can serve as evidence that the client is genuine, authorized, valid, and / or has been granted permission. Thus, the request for a token is a request for authentication. Consistent with the current concept, the request includes variable authentication data associated with the client. For example, the client stores the variable authentication data and includes it in the request for the token. In one implementation, the request also includes a host identifier associated with the host.

[0105] In operation 406, it is determined whether the variable authentication data received from the client matches the variable authentication data stored in association with the client identifier in the authentication database. In one implementation, the authentication database stores the most recent variable authentication data issued to the client in association with the client's client identifier. In operation 406, a lookup is performed in the authentication database using the client identifier received in operation 402 to retrieve the most recent variable authentication data associated with the client. And, the retrieved most recent variable authentication data is compared with the variable authentication data received in the request for the token in operation 404. If the two compared variable authentication data match, the client is considered genuine; if they do not match, the client is considered a forgery.

[0106] If the two compared variable authentication data do not match, then in operation 408, a failure message is sent to the client. The failure message is sent via the communication channel established in operation 402. The failure message indicates that the variable authentication data provided by the client in the request for the token in operation 404 is not the most recent variable authentication data issued in association with the client identifier obtained when the communication channel was established in operation 402. The failure message is sent instead of the token requested in operation 404. Thus, the client is considered a forgery, and a valid token (which would serve as proof of genuineness) is not provided to the client.

[0107] If the two compared variable authentication data match in operation 406, then in operation 410, it is determined whether to update the variable authentication data associated with the client. In one implementation, a policy or a set of policies is checked to determine whether these policies indicate that the existing variable authentication data should be replaced with new variable authentication data. These policies can depend on one or more factors, such as the time since the last authentication attempt, the number of authentication attempts within a specific time period, the client identifier, the host identifier, the time since the existing variable authentication data was generated, or any other factors set by the policy setting authority.

[0108] If the policy check determines that the existing variable authentication data is to be updated, then in operation 412, new variable authentication data is generated. The new variable authentication data is stored in the authentication database in association with the client identifier by replacing (e.g., overwriting) the existing variable authentication data. Thus, in line with the current concept, the client's next authentication attempt will succeed by providing the new authentication data (instead of the old authentication data).

[0109] In operation 414, the new variable authentication data is sent to the client. The new variable authentication data is sent through the communication channel established in operation 402. For example, a command to store the new variable authentication data is sent to the client, and the command includes the new variable authentication data as a payload (e.g., parameter). After 414, the client can send another request for a token using the new variable authentication data, in which case the server authentication method 400 will repeat from operation 404 (or from operation 402).

[0110] If the policy check determines that the existing variable authentication does not need to be updated, then a token is generated in operation 416. The token can serve as proof that the client has been authenticated to the host. In some implementations, the token is associated with a specific host, so the token cannot serve as proof that the client has been authenticated to any other host. In one implementation, the token is signed using a private key, and the corresponding public key is available to the host so that the host can verify the authenticity of the token.

[0111] In operation 418, the token is sent to the client. The token is sent through the communication channel established in operation 402. Issuing the token to the client is the result of the client providing the latest variable authentication data. Thus, the token serves as proof that the client is authentic.

[0112] Figure 5A flowchart of an example authentication client method 500 consistent with some implementations of the concepts of the present invention is illustrated. The authentication client method 500 is for illustrative purposes only and is not exhaustive or restrictive. The various actions in the authentication client method 500 may be performed in the order shown, in a different order, in parallel or simultaneously, may be omitted, repeated, or intermediate actions may be included between the actions.

[0113] In action 502, a request for a token is received from a host. The token serves as a proof of authenticity, and thus, the host is requesting a proof of authenticity. In addition to the token, other examples for proving authenticity may also be used. In one implementation, the request for the token includes the identity of a server from which the token can be obtained. The identity of the server may include a host name, an Internet Protocol (IP) address, or any other identity that can be used to contact and / or communicate with the server. The request for the token may include a host identifier of the host.

[0114] In action 504, a communication channel is established with the server through the host. In one implementation, the client initiates contact with the server to request communication. Although the communication channel is logically used to exchange messages with the server, in practice, the communication channel is implemented by the host acting as a proxy to relay messages to and from the server. That is, a message originally intended to be sent to the server is actually sent to the host, and the host will forward the message to the server. Also, a message from the server is actually received from the host that has forwarded the message from the server. The communication channel may be an encrypted channel. Establishing the communication channel may involve exchanging certificates. For example, a client certificate including a client identifier is sent to the server.

[0115] In action 506, the request for the token is sent to the server. The request for the token is sent through the communication channel established in action 504. In one implementation, the request for the token includes a variable authentication data. In other implementations, the request for the token includes multiple variable authentication data. In one implementation, the request for the token in action 506 includes the host identifier received in action 504. The server may respond to the request for the token in at least one of three ways. These three alternatives will be described below.

[0116] In alternative 1, the server has determined that the variable authentication data in the request for the token in action 506 is the latest variable authentication data and has determined not to update the variable authentication data. Thus, in action 508, a token is received from the server. The token is received through the communication channel established in action 504.

[0117] In operation 510, the token is sent to the host. That is, the token received from the server in operation 508 is provided to the host in operation 510 as proof of successful authentication. Sending the token to the host in operation 510 is one of the possible responses to the request for the token received from the host in operation 502.

[0118] In alternative 2, the server has determined that the variable authentication data in the request for the token in operation 506 is the most recent variable authentication data and has determined that the variable authentication data will be updated. Thus, in operation 512, new variable authentication data is received from the server. The new variable authentication data is received through the communication channel established in operation 504.

[0119] In operation 514, the new variable authentication data is stored. Storing the new variable authentication data replaces the old variable authentication data sent to the server with the request for the token in operation 506. Thus, any spoofing device attempting to authenticate by providing the old variable authentication data to the server will be rejected. The new variable authentication data is persistently stored so that it can be provided to the server in future authentication attempts.

[0120] After operation 514, the client authentication method 500 returns and repeats operation 506 by sending another request for the token to the server, where the repeated request for the token includes the new variable authentication data received in operation 512. Returning the new variable authentication data to the server is a technique for confirming to the server that the new variable authentication data has been successfully received (e.g., over the network) and successfully committed to memory. The client authentication method 500 can continue by repeating operations 508 and 510. Alternatively, after operation 514, the client authentication method 500 returns and repeats operation 504 by establishing a new communication channel.

[0121] In alternative 3, the server determines that the variable authentication data in the request for the token in operation 506 is not the most recent variable authentication data and thus rejects the request for the token. Thus, in operation 516, a failure message is received from the server. The failure message is received through the communication channel established in operation 504. The failure message can include an error code indicating one of the various reasons for the failure. For example, if a spoofing device sends a request for the token that includes expired variable authentication data, the request for the token will be rejected.

[0122] In operation 518, the failure message is sent to the host. The failure message sent to the host in operation 518 is one of the possible responses to the request for the token received from the host in operation 502.

[0123] Technical advantages

[0124] The concepts described herein provide many technical advantages. For example, authenticating the accessory by the host allows the accessory to be a relatively simple (and / or small) device. For example, the accessory does not need to be equipped with a cellular modem chip or a Wi-Fi chip for connecting to the Internet. Instead, the accessory communicates with the host to indirectly communicate with the authentication server. Thus, the accessory can simply communicate with the host using wired, Bluetooth, infrared, Near Field Communication (NFC), etc. In addition, the accessory can implement a relatively streamlined protocol, which includes a minimum number of commands (or messages) that can run on an embedded device without implementing a large number of commands included in a comprehensive protocol, which would require higher processing power, more memory, more storage space, higher power consumption, etc. For example, the accessory can implement a small subset of the complete TLS specification. Thus, the cost of the accessory can be cheaper. In addition, since the inventive concept does not require a discrete security integrated circuit (IC), the manufacturing cost of the accessory is reduced.

[0125] In addition, the inventive concept provides a software-based authentication scheme that requires less dedicated hardware compared to previous solutions that rely on hardware security chips to combat counterfeits. Thus, the software-based authentication scheme described herein is less vulnerable to factors such as manufacturing defects, manufacturing delays, labor costs, labor shortages, supply chain bottlenecks, weather-related disasters, etc. The lower hardware requirements also provide the additional advantage of being easily modifiable. That is, the inventive concept employing software-based authentication technology is more flexible, i.e., it can be modified more easily, quickly, and economically by changing the software (e.g., via updates and patches). For example, the authentication protocol can be updated via a software update without any hardware modification. In addition, the authentication protocol can be implemented on the existing hardware of the accessory even if the existing hardware of the accessory was not originally designed and manufactured to implement the authentication protocol.

[0126] The inventive concept takes full advantage of the property that software data in a client device (e.g., an accessory) is easily updated by issuing and frequently changing variable authentication data stored in the client device. Although a counterfeiter can copy and install the same client certificate into multiple clones, it is extremely difficult to copy and install the variable authentication data into multiple clones. In addition, even if the counterfeiter copies the variable authentication data and installs it into multiple clones, since the inventive concept dynamically changes the variable authentication data, these clones will not work properly. And, of course, it is almost impossible for the counterfeiter to continuously copy each newly issued variable authentication data to all clones. Thus, the inventive concept provides a cheap, general, and reliable authentication technology to prevent cloning.

[0127] Application

[0128] The inventive concept and the numerous example implementations described above have been explained in the context of authenticating a video game controller as an accessory device. However, the scope of application of the inventive concept is much broader. The inventive concept can be implemented in any client where variable authentication data can be stored, overwritten, and provided, as long as the client is capable of doing so. The client can be any hardware device (e.g., video game controller, video game console, computer, smartphone, tablet, headset, keyboard, card, badge, car, key, switch, watch, camera, storage device, remote control, household appliance, integrated circuit, wearable device, etc.) or any software module (e.g., application, program, game, file, service, operating system, driver, etc.). The host can be any hardware device or any software module capable of facilitating communication between the client and the server. For example, the host can be a video game console, a computer, a car, a door, a switch, an elevator, or any hardware or software capable of enabling, disabling, accepting, rejecting, detecting, using, or interacting with the client.

[0129] Example

[0130] Various examples are described below. Additional examples are described below. One example includes a system that includes: storage including first variable authentication data; and a processor for executing instructions that cause the processor to: receive a first request for a token from a host; establish a communication channel with a server via the host; send a second request for the token to the server, the second request including the first variable authentication data; receive the token from the server; and send the token to the host.

[0131] Another example may include any of the above and / or below examples, wherein the instructions further cause the processor to: receive second variable authentication data from the server.

[0132] Another example may include any of the above and / or below examples, wherein the instructions further cause the processor to: store the second variable authentication data in the storage.

[0133] Another example may include any one of the above and / or below examples, wherein storing the second variable authentication data in the storage replaces the first variable authentication data in the storage.

[0134] Another example may include any of the above and / or below examples, wherein the instructions further cause the processor to: send a third request for the token to the server, the third request including the second variable authentication data.

[0135] Another example may include any one of the above and / or below examples, wherein the second request includes an identifier of the host; and the token is valid for the host but not for other hosts.

[0136] Another example may include any of the above and / or below examples, wherein the second request is sent through the communication channel and the token is received through the communication channel.

[0137] Another example includes a computer-readable storage medium containing instructions that, when executed by a processor, cause the processor to: receive a first request for a token from a host; establish a communication channel with a server through the host; send a second request for the token to the server through the communication channel, the second request including first variable authentication data; receive the token from the server through the communication channel; and send the token to the host in response to the first request.

[0138] Another example may include any of the above and / or below examples, wherein the instructions further cause the processor to: receive second variable authentication data from the server through the communication channel, the second variable authentication data being different from the first variable authentication data.

[0139] Another example may include any of the above and / or below examples, wherein the instructions further cause the processor to: store the second variable authentication data by replacing the first variable authentication data.

[0140] Another example may include any of the above and / or below examples, wherein the instructions further cause the processor to: send a third request for the token to the server through the communication channel, the third request including the second variable authentication data.

[0141] Another example may include any of the above and / or below examples, wherein the first request includes a host identifier of the host; and the second request includes the host identifier.

[0142] Another example includes a computer-implemented method, including: establishing a communication channel with a client through a host; receiving a first request for a token from the client, the first request including first variable authentication data; determining whether the first variable authentication data matches second variable authentication data; in response to determining that the first variable authentication data matches the second variable authentication data, determining whether to update the second variable authentication data; in response to determining to update the second variable authentication data, generating third variable authentication data; and sending the third variable authentication data to the client.

[0143] Another example may include any of the above and / or below examples, wherein the method further includes checking one or more policies to determine whether to update the second variable authentication data.

[0144] Another example may include any of the above and / or below examples, wherein the method further includes, in response to determining not to update the second variable authentication data, generating the token and sending the token to the client.

[0145] Another example may include any example above and / or below, wherein the method further includes sending a failure message to the client in response to determining that the first variable authentication data does not match the second variable authentication data.

[0146] Another example may include any example above and / or below, wherein the method further includes storing the third variable authentication data.

[0147] Another example may include any example above and / or below, wherein the method further includes replacing the second variable authentication data with the third variable authentication data.

[0148] Another example may include any one of the examples above and / or below, wherein the first request is received via the communication channel and the third variable authentication data is sent via the communication channel.

[0149] Another example may include any example above and / or below, wherein the method further includes receiving, from the host, a second request to authenticate the token; and sending a message to the host to authenticate the token.

Claims

1. A system, comprising: A storage including first variable authentication data; And A processor for executing instructions, the instructions causing the processor to: Receive a first request for a token from a host; Establish a communication channel with a server through the host; Send a second request for the token to the server, the second request including the first variable authentication data; Receive the token from the server; And Send the token to the host.

2. The system according to claim 1, wherein The instructions further cause the processor to perform the following operations: Receive second variable authentication data from the server.

3. The system according to claim 2, wherein The instructions further cause the processor to perform the following operations: Store the second variable authentication data in the storage.

4. The system according to claim 3, wherein Storing the second variable authentication data in the storage replaces the first variable authentication data in the storage.

5. The system according to claim 2, wherein The instructions further cause the processor to perform the following operations: Send a third request for the token to the server, the third request including the second variable authentication data.

6. The system according to claim 1, wherein: The second request includes an identifier of the host; and The token is valid for the host but not for other hosts.

7. The system according to claim 1, wherein The second request is sent through the communication channel and the token is received through the communication channel.

8. The system according to claim 1, wherein The communication channel is an encrypted communication channel.

9. The system according to claim 1, characterized in that The system includes a video game controller.

10. A computer-readable storage medium including instructions that, when executed by a processor, cause the processor to perform the following operations: Receive a first request for a token from a host; Establish a communication channel with a server through the host; Send a second request for the token to the server through the communication channel, the second request including first variable authentication data; Receive the token from the server through the communication channel; And Send the token to the host in response to the first request.

11. The computer-readable storage medium according to claim 10, wherein The instructions further cause the processor to perform the following operations: Receive second variable authentication data from the server through the communication channel, the second variable authentication data being different from the first variable authentication data.

12. The computer-readable storage medium according to claim 11, wherein The instructions further cause the processor to perform the following operations: Store the second variable authentication data by replacing the first variable authentication data.

13. The computer-readable storage medium according to claim 12, wherein The instructions further cause the processor to perform the following operations: Send a third request for the token to the server through the communication channel, the third request including the second variable authentication data.

14. The computer-readable storage medium according to claim 10, wherein: The first request includes a host identifier of the host; and The second request includes the host identifier.

15. The computer-readable storage medium according to claim 10, wherein The communication channel is an encrypted communication channel.

Images