Device authentication through a proxy

Abstract

A software-based authentication protocol allows a client to be authenticated by a server through a host. The authentication protocol involves the use of variable authentication data that varies to prevent impostors from cloning a genuine client. The host requests a token from the client as proof of authenticity. The client establishes a communication channel to the server using the host as a communication proxy. The client presents the variable authentication data to the server. If the server determines that the variable authentication data is out of date, the client is considered an impostor. If the server determines that the variable authentication data is the latest version, the client is considered authentic and is issued a token. Depending on a set of policies, the server modifies the variable authentication data and sends the new variable authentication data to the client, but not to fake clients.

Description

[Background technology]

[0001] Many electronic devices (e.g., computers, smartphones, and video game consoles) are used with accessory devices (e.g., mice, headphones, game controllers, etc.), which have become a large market and a target for counterfeiters. Summary of the Invention

[0002] The concepts described herein relate to software-based authentication techniques. For example, a communication protocol is described for authenticating an accessory device with an authentication service via a proxy device (e.g., a host device). The communication protocol enables verification of an accessory device's authentication license while preventing unauthorized interoperation of counterfeit accessory devices. The proxy device can serve as a communication conduit for the accessory device and the authentication service to exchange messages. The communication protocol includes exchanging variable authentication data. The use of variable authentication data that changes frequently can prevent counterfeiters from creating valid counterfeit accessories. The concepts can render counterfeit accessories inoperable to prevent mass production and sale of unauthorized accessories. The communication protocol also includes using tokens to verify authenticated accessories. The tokens can be bound to a specific accessory device and / or a specific host device.

[0003] To clarify the implementation and operation of authentication protocols and techniques, the concepts are described below with respect to authenticating a game controller (as an example accessory device) with a game console (as an example host device). Note that these concepts are not limited to authenticating controllers in the gaming world, but have broad application to authenticating any type of device across various industries. [Brief explanation of the drawings]

[0004] [Figure 1]Several implementations of the present concepts illustrate authentication scenarios in which they can be used to authenticate devices and detect counterfeits. [Figure 2] 1 illustrates systems according to some implementations of the present concepts. [Figure 3] 1 illustrates communication according to some implementations of the present concepts. [Figure 4] 1 illustrates a flow diagram of an example authentication server method according to some implementations of the present concepts. [Figure 5] 1 illustrates a flow diagram of an example authentication client method according to some implementations of the present concepts. DETAILED DESCRIPTION OF THE INVENTION

[0005] The detailed description will now refer to the accompanying drawings. The use of like reference numbers in different instances in the specification and drawings may indicate similar or identical items. The illustrative figures are not necessarily to scale.

[0006] [overview] 1 depicts an example authentication scenario 100 in which some implementations of the present concepts may be used to authenticate devices and detect counterfeits. As mentioned above, the present concepts are described with respect to detecting counterfeit game controllers, but the same or similar concepts may be applied in other situations.

[0007] The authentication scenario 100 depicted in Figure 1 includes one or more gaming consoles 102. A gaming console 102 is any electronic device that allows a user to play a game with an accessory. A gaming console 102 has processing and / or storage capabilities to store and execute games. For example, a gaming console 102 may include a personal computer (PC), a smartphone, a virtual reality headset, a television, or a typical standalone gaming console.

[0008] The game console 102 includes or connects to one or more accessory devices (e.g., a display, a keyboard, a mouse, speakers, headphones, a storage device, a remote control, and a game controller 104, etc.) to enable a user to interact with the game by providing input and / or receiving output. The game console 102 connects to the accessory devices by wire (e.g., a Universal Serial Bus (USB) cable) or wirelessly (e.g., Wi-Fi, Bluetooth, infrared, etc.).

[0009] For example, genuine game controller 104(1) is approved for use with game console 102(1) to play games. However, counterfeit game controller 104(2) is imitated from genuine game controller 104(1) by unauthorized, malicious actors and sold on the market. Prior art cannot distinguish between genuine game controller 104(1) and counterfeit game controller 104(2). Therefore, an authentication check, for example, is required to prevent counterfeit game controller 104(2) from operating with game console 102(2).

[0010] [Technical issues] One conventional authentication technique involves a game console provider selling hardware security chips to accessory vendors who build game controllers. Each security chip contains unique static authentication data, such as a unique certificate and a unique private key. A game controller manufacturer licenses a specific number of security chips depending on the number of game controllers it plans to manufacture and sell. The game controller manufacturer then includes the security chip in every game controller it manufactures. As a result, each genuine game controller contains unique static authentication data.

[0011] When a game controller is connected to a game console, the game console sends a challenge to the security chip in the game controller. In response, the security chip signs the challenge with a private key and sends the signed challenge back to the game console. The game console then validates the signed challenge sent by the game controller using a certificate and private key stored on the game console. Thus, the game console can authenticate that the security chip in the game controller was provided by the game console provider and verify that the game controller is authentic.

[0012] However, counterfeiters may imitate genuine game controllers without authorization to create fake game controllers. For example, a malicious actor may destroy the security chip, extract the private key, create a fake security chip, and sell the fake game controller with the fake security chip. Therefore, when the fake game controller is connected to a game console, the fake game controller pretends to be the genuine game controller by forging the same static authentication data stored in the genuine game controller.

[0013] One technical challenge associated with conventional authentication techniques is that the secret key used to authenticate a game controller is an unchanging constant. Therefore, if a counterfeit game controller is manufactured with the same authentication data as a genuine controller, a game console cannot distinguish between the counterfeit game controller and the genuine game controller because they are the same. Therefore, there is a need in the art to provide an improved authentication paradigm that can enable a game console to distinguish between a genuine game controller and a counterfeit game controller.

[0014] Another technical challenge associated with conventional authentication technologies is the use of hardware security chips. Security chips are susceptible to manufacturing defects and delays (e.g., due to factory shutdowns). A shortage of security chips can create a supply chain bottleneck in the manufacturing and distribution of new game controllers. Therefore, there is a need to develop a software-based authentication scheme that can be implemented on commodity hardware.

[0015] [Technical solution] This concept concerns an accessory authentication scheme that allows end-to-end authentication between an accessory and an authentication server via a proxy device. The authentication server, accessory, and proxy implement an authentication protocol that can validate genuine accessories and reject fake ones.

[0016] 1, the authentication service 106 communicates with the game consoles 102. Additionally, the authentication service 106 may also communicate with the game controllers 104, with their respective game consoles 102 acting as a communication conduit. In one implementation, the game controller 104(1) provides a command-based interface that allows the game console 102(1) to manage the authentication session and communicate with the authentication service 106.

[0017] In one implementation, game controller 104(1) initiates communication with authentication service 106. For example, game controller 104(1) and authentication service 106 can establish an encrypted communication channel (e.g., a Transport Security Layer (TSL) connection) that tunnels through game console 102(1) by mutually authenticating each other. In one implementation, game console 102(1) requests that game controller 104(1) present a token as proof of its authenticity. Game controller 104(1) requests a token from authentication service 106 by presenting variable authentication data (e.g., controller authentication data (CAD) 110) to authentication service 106 using the encrypted communication channel. Authentication service 106 then checks with policy service 108 to determine whether the CAD 110 presented by game controller 104(1) is valid. Policy service 108 can be implemented on the same or different server hardware as authentication service 106.

[0018] Policy service 108 maintains an authentication database 114 that stores CADs associated with multiple game controllers, including CAD 110 associated with game controller 104(1). Policy service 108 verifies that the CAD 110 provided by game controller 104(1) matches a CAD 110 stored in authentication database 114. If policy service 108 validates the CAD 110 from game controller 104(1), authentication service 106 issues a token to game controller 104(1). Game controller 104(1) then presents the token to game console 102(1) as proof that it has been authenticated and is authorized to interoperate with game console 102(1).

[0019] In accordance with this concept, policy service 108 modifies CAD 110 stored in authentication database 114, issues and stores the modified CAD 110 to game controller 104(1), and stores a set of policies that determine the circumstances for presentation during future authentication sessions. If a fake game controller 104(2) attempts to authenticate by replicating an old CAD 112 and presenting the old CAD 112, policy service 108 rejects the fake game controller 104(2) because the old CAD 112 does not match the modified CAD 110 in authentication database 114. Thus, game console 102(2) restricts the operation of the fake game controller 104(2).

[0020] The policy service 108 can mutate (e.g., change, update, replace, or reset) the CAD 110 periodically (e.g., daily, weekly, etc.) and / or upon specific events (e.g., each time a game controller 104(1) connects to the game console 102(1)), such that a genuine game controller 104(1) that stores and presents the latest CAD 110 will be successfully authenticated, while a counterfeit game controller 104(2) that stores and presents an older CAD 112 will fail the authentication check. Thus, the present concept can combat counterfeiters by rendering their counterfeit accessories unusable as the mutable authentication data changes. Various implementations of the present concept, including the mutable authentication data and policies, as well as technical advantages, are described in U.S. Patent Application No. 17 / 848,235, entitled "Authentication Using Mutable Data," filed June 23, 2022, which is incorporated herein by reference.

[0021] [System Devices] 2 depicts an example system 200 according to some implementations of the present concepts. System 200 includes a server 210, a host 230, and a client 250. Although FIG. 2 shows only one server 210, one host 230, and one client 250 for simplicity in illustrating the present concepts, system 200 may include multiple servers 210, multiple hosts 230, and / or multiple clients 250.

[0022] Server 210 may be implemented in one or more server computers with processing and storage capabilities. Server 210 includes a certificate issuing service 212 that generates and issues unique certificates, including unique client identifiers 215, to be stored on clients 250. In one embodiment, the certificates are globally unique and formatted using a public key certificate standard, such as the X.509 standard. The certificates may be signed. For example, the provider of host 230 may sign the certificate with its private key. In some scenarios, an accessory intermediate certificate authority (“CA”) may sign the certificate with its private key. Server 210 includes a certificate database 214 that stores multiple client identifiers associated with multiple clients. For example, certificate database 214 stores client identifiers 215 associated with client 250.

[0023] Server 210 includes policy service 108. Policy service 108 stores policies related to authentication. Based on the policies, policy service 108 makes decisions regarding whether to authenticate or reject client 250 and whether to generate and / or modify variable authentication data 219 (e.g., CAD 110 of FIG. 1). Policy service 108 generates and issues variable authentication data 219 to client 250. Policy service 108 also checks variable authentication data 219 presented by client 250 to authenticate or reject client 250 for use with host 230.

[0024] For example, variable authentication data 219 can include a randomly or arbitrarily generated number and / or string, such as a nonce. Alternatively, or additionally, variable authentication data 219 can include a timestamp, a serial number, and / or a signature. In an exemplary situation where client 250 is game controller 104(1), variable authentication data 219 includes CAD 110. Variable authentication data 219 can have a fixed size (e.g., 1 kilobyte or 4 kilobytes) or can have 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 simply receive, store, present, and / or relay variable authentication data 219.

[0025] The server 210 includes an authentication database 114 that stores variable authentication data 219 generated and issued by the policy service 108. In one implementation, the variable authentication data 219 is stored in association with the client identifier 215 of the client 250 to which the variable authentication data 219 was issued. Thus, the policy service 108 knows multiple client identifiers for multiple clients, as well as their associated variable authentication data, in order to perform authentication checks.

[0026] According to some implementations of the present concepts, the policy service 108 authenticates the client 250 if the client 250 provides the correct variable authentication data 219 that was last issued to the client 250 by the policy service 108. For example, the policy service 108 issues new variable authentication data 219 to the client 250 to be stored and then presented for 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 upon specific events (e.g., after each authentication check, after a certain period of time has elapsed, when the client 250 connects to a different host, etc.). In one implementation, the expiration period of the variable authentication data 219 is set by policy. Such policies maintained by the policy service 108 may be adjusted. If the client 250 presents expired authentication data (e.g., old CAD 112 in FIG. 1 ), the policy service 108 rejects the request to authenticate the client 250.

[0027] In some implementations, the policy service 108 stores more than one variable authentication data item in association with each client identifier 215 in the authentication database 114. For example, the authentication database 114 may store the two most recent variable authentication data items per client identifier 215 in a first-in, first-out manner. Thus, the policy service 108 authenticates the client 250 even if the client 250 presents the second most recent variable authentication data item instead of the most recent variable authentication data item. This configuration allows the policy service 108 to be resilient to errors and / or failures that may occur while the client 250 is receiving updated variable authentication data 219 over the network and / or writing the updated variable authentication data 219 to the authentication data storage 254. Alternatively, three or more recent variable authentication data items 219 may be stored in association with each client identifier 215 in the authentication database 114, and the client 250 may present any one of the stored variable authentication data items 219 in order to be authenticated.

[0028] The server 210 includes an authentication service 106. The authentication service 106 generates and issues a token to the client 250 in response to the policy service 108 validating the variable authentication data 219 presented by the client 250. The token may be signed by the authentication service 106 before being sent to the client 250. In addition to being assigned specifically to the client 250, the token may be associated specifically with the host 230. The token may thereby be used by the client 250 to interoperate with the host 230 but not with other hosts. The authentication service 106 may also check and validate the token to ensure that it was issued by the authentication service 106. For example, the authentication service 106 may check and verify that the token was signed by the authentication server 106.

[0029] 2 depicts certificate issuing service 212, certificate database 214, policy service 108, authentication database 114, and authentication service 106 as being contained on server 210, alternative configurations are possible. For example, certificate issuing service 212, certificate database 214, policy service 108, authentication database 114, and authentication service 106 may be contained on different servers (see FIG. 1) and / or different storage devices. In other implementations, certificate database 214 and / or authentication database 114 may be remote from server 210.

[0030] Client 250 can be any device, accessory, or article that can be authenticated. For example, client 150 can include a real game controller 104(1), a display, a keyboard, a mouse, speakers, headphones, a hard drive, removable storage, a card, a key, a badge, a remote control, glasses, headgear, etc. While Figure 2 depicts client 250 as a hardware device, client 250 can be a software module capable of executing an authentication protocol.

[0031] In some implementations, all or some functionality of client 250 (e.g., the ability to function with host 230) is limited unless or until client 250 is authenticated by policy service 108. Host 230 may include an enforcement policy that determines which functionality of client 250 is enabled or disabled depending on whether client 250 can be authenticated. In one implementation, client 250 includes certificate storage 252 that stores a certificate including client identifier 215. Client 250 also includes authentication data storage 254 that stores variable authentication data 219.

[0032] The certificate stored in certificate storage 252 of client 250 is issued by certificate issuing service 212 of server 210. In some implementations, the certificate is stored on client 250 at the time client 250 is manufactured, and the certificate does not change.

[0033] The variable authentication data 219 stored in authentication data storage 254 of client 250 is issued by policy service 108 of server 210. In one implementation, each time policy service 108 issues new variable authentication data 219 to client 250, client 250 writes the new variable authentication data 219 to authentication data storage 254, thereby allowing the variable authentication data 219 stored on client 250 and server 210 to be synchronized. In one implementation, when new variable authentication data 219 is written on client 250, any old variable authentication data is replaced (e.g., deleted, discarded, overwritten, etc.). In some implementations, client 250 stores more than one variable authentication data 219 in authentication data storage 254. For example, authentication data storage 254 includes two slots that can store the two most recent variable authentication data 219 that client 250 received from server 210, e.g., in a first-in, first-out manner. Thus, the client 250 can present both of its stored variable authentication data 219 to the server 210, and the policy service 108 authenticates the client 250 based on whichever one of the two presented variable authentication data 219 matches one or more of the most recent variable authentication data 219 stored in the authentication database 114 of the server 210.

[0034] These implementations of storing multiple variable authentication data 219 provide resilience and robustness against errors and / or failures that may occur while the client 250 is receiving updated variable authentication data 219 over the network and / or writing the updated variable authentication data 219 to memory, and / or against data corruption after the variable authentication data 219 is stored. For example, the client 250 may accidentally disconnect from the network and lose its connection to the server 210, the client 250 may experience an error while writing the latest variable authentication data 219 to the authentication data storage 254, or the client 250 may unexpectedly lose power. Furthermore, corruption of flash storage data may render the variable authentication data 219 stored on the client 250 unusable for authentication. These and any other errors may prevent the client 250 from successfully authenticating, for example, during the next authentication session. By storing multiple variable authentication data 219, the client 250 is more tolerant to errors and can still pass future authentication checks.

[0035] In one implementation, client 250 is manufactured without any variable authentication data 219. Client 250 is issued its initial variable authentication data 219 by policy service 108 the first time client 250 attempts authentication. If an impostor is able to extract variable authentication data 219 to create multiple clones (e.g., fake game controller 104(2)), by the time the clones attempt authentication using the old variable authentication data (e.g., old CAD 112), the variable authentication data 219 will have been changed and the clones will no longer be able to authenticate with policy service 108.

[0036] The client 250 also includes a token storage 256 that stores a token received from the authentication service 106 of the server 210 upon a successful authentication check. The client 250 can present the token from the token storage 256 to the host 230 as proof of successful authentication.

[0037] Host 230 can be any computer, device, apparatus, machine, or accessory capable of operating with client 250. For example, host 230 can include game console 102(1), a PC, a television, a tablet, a smartphone, etc. Although Figure 2 depicts host 230 as a hardware device, host 230 can be a software module (e.g., an application, a program, an operating system, firmware, etc.) that authenticates client 250.

[0038] According to some implementations of the present concepts, the host 230 attempts to authenticate the client 250 by 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.

[0039] In some implementations, host 230 facilitates communication between client 250 and server 210 for the purpose of performing authentication checks, i.e., host 230 acts as a proxy or intermediary that supports a communication channel between client 250 and server 210.

[0040] Depending on whether the authentication attempt by client 250 is successful or unsuccessful, host 230 may enforce one or more enforcement policies depending on the authentication result, for example, by enabling or disabling certain features of client 250. That is, host 230 is capable of operating client 250 in one or more operational modes.

[0041] Each of the server 210, host 230, and client 250 can include a personal computer, desktop computer, server computer, notebook computer, mobile phone, smartphone, personal digital assistant, tablet or pad computer, mobile computer, camera, appliance, virtual reality headset, video game console, controller, smart device, IoT device, vehicle, watch, wearable, set-top box, gaming system, automotive entertainment or navigation console, coffee maker, etc., and / or countless types of electronic devices continuing to evolve or yet to be developed. The number of devices and client versus server sides of the devices described and shown are intended to be illustrative and non-limiting.

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

[0043] As used herein, terms such as "device," "computer," or "computing device" can refer to any type of device that has some degree of processing and / or storage capability. Processing capability can be provided by one or more hardware processors that can execute data in the form of computer-readable instructions to provide functionality. Computer-readable instructions and / or data, such as user-related data, can be written to storage, such as storage that can be internal or external to the device. Storage can include any one or more of volatile or non-volatile memory, hard drives, flash storage devices, optical storage devices (e.g., CDs, DVDs, etc.), and / or remote storage (e.g., USB drives or cloud-based storage), among others. As used herein, the term "computer-readable medium" can include a transitory, propagating signal or carrier wave. In contrast, the term "computer-readable storage medium" does not include transitory, propagating signals and carrier waves. A computer-readable storage medium can include a computer-readable storage device. Examples of computer-readable storage devices include, among others, volatile storage media such as RAM and non-volatile storage media such as hard drives, optical disks, and flash memory.

[0044] 2 illustrates two exemplary device configurations 270 that may be used by any or all of server 210, host 230, and client 250. First configuration 270(1) represents an operating system (OS)-centric configuration. Second configuration 270(2) represents a system-on-chip (SoC) configuration. First configuration 270(1) may consist of one or more applications 272, an operating system 274, and hardware 276. Second configuration 270(2) may consist of shared resources 278, dedicated resources 280, and an interface 282 therebetween. Both configurations 270 may include storage 284 and a processor 286. For example, storage 284 in server 210 may include certificate database 214 and / or authentication database 114, while storage 284 in client 250 may include certificate storage 252 and / or authentication data storage 254.

[0045] Configuration 270 also includes an authentication module 288 that implements the communication protocols described herein. For example, authentication module 288 in server 210 implements certificate issuing service 212, policy service 108, and authentication service 106. Authentication module 288 in host 230 enables a pass-through communication channel, relays messages between client 250 and server 210, initiates authentication checks, requires client 250 to present a token as proof of authenticity, verifies the validity of the token with server 210, and enforces authentication results by placing client 250 in one or more operational modes. Authentication module 288 in client 250 stores variable authentication data 219 received from server 210, presents variable authentication data 219 to server 210 for authentication, and presents tokens to host 230.

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

[0047] In general, any of the functionality described herein may be implemented using software, firmware, hardware (e.g., fixed logic circuitry), or a combination of these implementations. As used herein, the terms “component” or “module” generally refer to software, firmware, hardware, an entire device, or network, or a combination thereof. In the case of a software implementation, for example, these terms refer to program code that, when executed on a processor (e.g., one or more CPUs), performs specified tasks. The program code may be stored in one or more computer-readable memory devices, such as computer-readable storage media. The functionality and techniques of the components or modules are platform-independent, meaning they may be implemented on a variety of commercially available computing platforms having various processing configurations. The system 200 depicted in FIG. 2 is merely an example. System 200 need not include all of the exemplary elements described in connection with FIG. 2. System 200 may also include additional elements not explicitly described in connection with FIG. 2.

[0048] [communication] FIG. 3 illustrates communications according to some implementations of the present concepts. With reference to FIG. 3, an example sequence of communications (e.g., exchanged messages) between controller 104(1), console 102(1), authentication service 106, and policy service 108 when performing an authentication check is described. In these examples, controller 104(1) is an example of client 250 that has been authenticated to prevent counterfeiting, and console 102(1) is an example of host 230 that acts as a communication proxy. Note that the same or similar communications may occur with other types of clients and hosts. The names of messages and payloads within messages described below are examples. Other names may be used and serve the same purpose or function. Any of the described communications may be sent or received using or including any communication technology or protocol, such as Representational State Transfer (REST), Transport Layer Security (TSL), JavaScript Object Notation (JSON), etc.

[0049] Even before sequence 1, when a user powers on controller 104(1) and connects it to console 102(1) either wired or wirelessly, controller 104(1) and console 102(1) begin communicating with each other. For example, controller 104(1) and console 102(1) may perform a handshake and / or any authentication using their certificates.

[0050] In Sequence 1, console 102(1) requests a token from controller 104(1). Sequence 1 may begin when console 102(1) determines that a particular event has triggered console 102(1) to test the authenticity of controller 104(1) and therefore wishes to verify controller 104(1) (e.g., that controller 104(1) has a valid license). For example, console 102(1) powers on, controller 104(1) powers on, controller 104(1) connects to console 102(1), a user initiates a particular function on console 102(1) (e.g., by starting a game), or any other event may cause console 102(1) to request that controller 104(1) present a valid token.

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

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

[0053] In sequence 2, controller 104(1) and authentication service 106 authenticate each other and establish a communication channel. Sequence 2 represents several messages exchanged between controller 104(1) and authentication service 106 via console 102(1), which acts as a communication proxy.

[0054] In practice, controller 104(1) exchanges messages with console 102(1), and console 102(1) exchanges messages with authentication service 106. Note that because console 102(1) relays messages between controller 104(1) and authentication service 106, controller 104(1) and authentication service 106 can logically be considered to be exchanging messages with each other. The messages exchanged between controller 104(1) and authentication service 106 can be opaque to console 102(1). Console 102(1) can simply forward (pass) the messages. For example, controller 104(1) and authentication service 106 can send a SetPassThroughData message to console 102(1). The payload of the SetPassThroughData message can be the substantive message intended for the ultimate recipient to which console 102(1) will forward the substantive message.

[0055] In one implementation, controller 104(1) and authentication service 106 use the TLS protocol to establish an encrypted communication channel. As described above, controller 104(1) can initiate a communication session with authentication service 106 via console 102(1). For example, controller 104(1) and authentication service 106 exchange client and server certificates, including an AccessoryID. AccessoryID is a unique accessory identification associated with controller 104(1), such as client identifier 215. After sequence 2 establishes the encrypted communication channel, messages between controller 104(1) and authentication service 106 are transmitted over that communication channel (i.e., via console 102(1)).

[0056] In sequence 3, controller 104(1) requests an AToken from authentication service 106 using the communication channel. For example, controller 104(1) sends a GetATokenRequest message to authentication service 106. In one implementation, the GetATokenRequest message includes one CAD blob (e.g., CAD 110 in FIG. 1). In another implementation, the GetATokenRequest message includes two CAD blobs. In a scenario where controller 104(1) is requesting authentication for the first time and has not been previously issued a CAD blob, the GetATokenRequest message includes a meaningless CAD blob. The GetATokenRequest message may also include the ConsoleID that console 102(1) sent to controller 104(1) in sequence 1.

[0057] In sequence 4, authentication service 106 checks with policy service 108 to authenticate controller 104(1). For example, authentication service 106 sends an IsAccessoryAllowed message to policy service 108. In one implementation, the IsAccessoryAllowed message includes the AccessoryID that authentication service 106 obtained from 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.

[0058] In accordance with this concept, policy service 108 maintains an authorization database 114 of AccessoryIDs and associated CAD blobs. Thus, upon receiving an IsAccessoryAllowed message, policy service 108 checks authorization database 114 to determine whether controller 104(1) should be allowed or denied. Policy service 108 also stores a set of policies for determining authorization results.

[0059] Several alternative outcomes are possible: If one or more CAD blobs and Accessory IDs in the IsAccessoryAllowed message do not match CAD blobs and Accessory IDs in authentication database 114, policy service 108 rejects controller 104(1) as fake (Alternative 3 in FIG. 3). If one or more CAD blobs and Accessory IDs in the IsAccessoryAllowed message match CAD blobs and Accessory IDs in authentication database 114, policy service 108 authorizes controller 104(1).

[0060] If controller 104(1) is authorized, policy service 108 further checks the policy to determine whether a new CAD blob should be created and issued to controller 104(1). For example, the policy may be set to issue a new CAD blob each time 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, the policy may require that the CAD blob be updated if controller 104(1) connects to a different console. If the policy determines that the CAD blob should be updated, policy service 108 issues the new CAD blob to controller 104(1) (Alternative 2 in FIG. 3). Otherwise, policy service 108 simply authenticates controller 104(1) without updating the CAD blob (Alternative 1 in FIG. 3).

[0061] Furthermore, in a scenario where controller 104(1) is attempting authentication for the first time, policy service 108 can check authentication database 114 to verify that the AccessoryID provided by the IsAccessoryAllowed message does not exist in policy service 108's authentication database 114. After verifying that the authentication attempt is new to controller 104(1) or that controller 104(1) has not been issued a CAD blob before, policy service 108 generates a new CAD blob and issues it to controller 104(1) (Alternative 2 in FIG. 2 ).

[0062] 3, after sequences 1-4, there are alternative communication sequences that are possible. Alternative 1 includes sequences 5-9, alternative 2 includes sequences 10-12, and alternative 3 includes sequences 13-15. These alternatives are described below.

[0063] In Alternative 1, policy service 108 has determined that controller 104(1) presents an up-to-date CAD blob that is synchronized with the CAD blob stored in authentication database 114, and has determined that controller 104(1)'s CAD blob does not need to be updated. Therefore, in sequence 5, policy service 108 sends an AccessoryIsAllowed message to authentication service 106. The AccessoryIsAllowed message in sequence 5 is one possible response to the IsAccessoryAllowed message in sequence 4.

[0064] In response, authentication service 106 generated an AToken as evidence that controller 104(1) successfully passed the authentication check. In one implementation, the AToken is a JSON web token (JWT) and is signed by the private key of authentication service 106. In some implementations, the AToken is generated based on specific information (e.g., in fields) such as the AccessoryID of controller 104(1), the time the AToken was issued, the time the AToken expires, the ConsoleID of console 102(1), and / or the time the CAD blob was issued. If the AToken contains the ConsoleID of console 102(1), the AToken authenticates the controller 104(1) used with that particular console 102(1). Thus, if an impostor copies an AToken and attempts to use the copied AToken to interoperate a fake 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), so they cannot see the contents of the AToken. Other techniques are possible in addition to the AToken described herein for the authentication service 106 to communicate to the console 102(1) that the controller 104(1) has successfully authenticated.

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

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

[0067] Upon receiving the AToken, console 102(1) verifies the authenticity of controller 104(1) by requesting that authentication service 106 validate the AToken, for example, using an API service provided by authentication service 106. In sequence 8, console 102(1) sends a ValidateAToken message to authentication service 106. The ValidateAToken message includes the AToken that console 102(1) received from controller 104(1) in the RequestATokenSuccess message in sequence 7.

[0068] Upon receiving the ValidateAToken message, the authentication service 106 verifies that the AToken in the ValidateAToken message was actually issued to the authentication service 106. In one implementation, the authentication service 106 checks the signature of the AToken to verify that the AToken is correctly signed and was actually issued by the authentication service 106. This implementation does not require the authentication service 106 to maintain a database of ATokens.

[0069] If authentication service 106 determines that the AToken is valid, then in sequence 9, authentication service 106 notifies console 102(1) that the AToken is valid. For example, authentication service 106 sends an ATokenValid message to console 102(1). The ATokenValid message in sequence 9 is one possible response to the ValidateAToken message in sequence 8. Note that if authentication service 106 determines that the AToken is invalid, authentication service 106 sends an ATokenInvalid to console 102(1).

[0070] Depending on whether console 102(1) receives an ATokenValid message or an ATokenInvalid message from authentication service 106, console 102(1) either accepts controller 104(1) as authentic or rejects controller 104(1) as a fake. Console 102(1) includes an enforcement policy that determines the pass or fail outcome of the authentication check. For example, controller 104(1) may be completely disabled, enabled to operate in a restricted mode with limited functionality, or allowed to operate fully with all functionality enabled. Once sequence 9 is complete, the authentication session can be successfully terminated. In addition to using the AToken to verify the authenticity of controller 104(1) to console 102(1), the same AToken can also be used to prove the authenticity of controller 104(1) to other devices or services.

[0071] In Alternative 2, policy service 108 determines that controller 104(1) presents an up-to-date CAD blob that is synchronized with the CAD blob stored in authentication database 114 and determines that controller 104(1)'s CAD blob should be updated. Alternatively, policy service 108 determines that controller 104(1) has not previously issued any CAD blob (e.g., controller 104(1) is attempting authentication for the first time). Policy service 108 creates a new CAD blob and associates it with the AccessoryID in authentication database 114. If authentication database 114 already contains one or more existing CAD blobs associated with the AccessoryID, policy service 108 replaces the existing CAD blob (or one of the existing CAD blobs) with the new CAD blob. If the AccessoryID does not exist in authentication database 114, policy service 108 adds the controller ID to authentication database 114 along with the new CAD blob.

[0072] Policy service 108 stores the new CAD blob persistently until it is replaced with a newer CAD blob. Thus, the next time policy service 108 receives an authentication request from controller 104(1) presenting the correct, latest CAD blob, policy service 108 is assured that controller 104(1) is the same physical device for which the latest CAD blob was previously issued.

[0073] In one implementation, policy service 108 stores one CAD blob per Accessory ID. Thus, storing a new CAD blob overwrites any older CAD blobs already stored in authentication database 114. Alternatively, policy service 108 stores multiple CAD blobs per Accessory ID, such as two, three, or any number of the most recently created CAD blobs associated with controller 104(1)'s Accessory ID. Storing multiple CAD blobs provides resilience against errors that may occur while controller 104(1) receives and / or writes CAD blobs.

[0074] In sequence 10, policy service 108 sends a WriteNewCad message to authentication service 106. The WriteNewCad message contains a new CAD blob. If controller 104(1) contains multiple slots for storing multiple CAD blobs, the WriteNewCad message contains a SlotNumber, which can be a numeric value (e.g., 0, 1, 2, 3, etc.) that indicates the slot number into which the new CAD blob should be written. The WriteNewCad message in sequence 10 is one possible response to the IsAccessoryAllowed message in sequence 4.

[0075] Upon receiving the new CAD blob from policy service 108, authentication service 106 forwards the new CAD blob to controller 104(1). For example, authentication service 106 sends a GetATokenReplaceCad message to controller 104(1). The GetATokenReplaceCad message in sequence 11 includes the new CAD blob that was in the WriteNewCad message in sequence 10. If controller 104(1) has multiple slots for storing multiple CAD blobs, the GetATokenReplaceCad message includes the SlotNumber that was included in the WriteNewCad message in sequence 10. The GetATokenReplaceCad message in sequence 11 is one possible response to the GetATokenRequest message in sequence 3.

[0076] Controller 104(1) receives the GetATokenReplaceCad message and stores the new CAD blob in memory. If the GetATokenReplaceCad message includes a SlotNumber, controller 104(1) stores the new CAD blob in the slot indicated by SlotNumber. If this is the first time controller 104(1) has received the new CAD blob, controller 104(1) simply stores the new CAD blob in memory. Otherwise, the new CAD blob replaces the existing CAD blob already stored in controller 104(1). The existing CAD blob is stale, meaning it is out of sync with the new CAD blob stored in authentication database 114 of policy service 108, and therefore can no longer be used to successfully authenticate controller 104(1) in the future. Instead, the new CAD blob is up to date (i.e., synchronized with the CAD blob stored in the authentication database 114 of the policy service 108) and therefore can be used to successfully authenticate the controller 104(1) in the future.

[0077] Optionally, in sequence 12, controller 104(1) informs console 102(1) that a CAD blob is being replaced. For example, controller 104(1) sends a ReplacingCad message to console 102(1). The ReplacingCad message in sequence 12 is one possible response to the RequestAToken message in sequence 1. The ReplacingCad message in sequence 12 is an optional message that does not need to be sent.

[0078] After Alternative 2 (i.e., after Sequence 11 and / or Sequence 12), controller 104(1) repeats Sequence 3, sending another GetATokenRequest message containing the new CAD blob to authentication service 106. 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 use in the repeated iteration of Sequence 3. Sequences 4-9 then also repeat. This repetition of Sequences 3-4, in which controller 104(1) returns the new CAD blob to policy service 108, which issued it to controller 104(1), confirms that the new CAD blob was successfully transmitted from policy service 108 to controller 104(1) and successfully written and durably committed to controller 104(1). Rather than having a separate, dedicated acknowledgement message from controller 104(1) to policy service 108 to confirm successful receipt and writing of the new CAD blob, a repeated GetATokenRequest containing the new CAD blob can serve as the acknowledgement.

[0079] The next time controller 104(1) is powered on or connects to console 102(1), the above communications may be repeated. For example, sequences 1-9 (or sequences 1-4, 10-12, and 3-9) may be performed to successfully authenticate controller 104(1) because the CAD blob provided by controller 104(1) in sequence 3 is the most recent CAD blob that matches the CAD blob in authentication database 114 of policy service 108. Furthermore, in sequence 10, policy service 108 issues a newer CAD blob to controller 104(1). In accordance with this concept, modifying the CAD blob prevents a fake controller 104(2) from being authenticated.

[0080] A counterfeiter could manufacture one or more counterfeit controllers with the same certificate (and therefore the same AccessoryID) as controller 104(1), but the counterfeit controllers would not be able to successfully authenticate with policy service 108 because they would not be able to present the most recent CAD blob that policy service 108 issued to controller 104(1).

[0081] In Alternative 3, policy service 108 determines that controller 104(1) is presenting an outdated CAD blob that does not match the most recent CAD blob stored in authentication database 114. Therefore, policy service 108 rejects controller 104(1) as a fake.

[0082] Thus, in sequence 13, policy service 108 informs authentication service 106 that controller 104(1) has been rejected. For example, policy service 108 sends an AccessoryIsRejected message to authentication service 106. The AccessoryIsRejected message in sequence 13 is one possible response to the IsAccessoryAllowed message in sequence 4.

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

[0084] In sequence 15, controller 104(1) informs console 102(1) that the attempt to authenticate and obtain a valid AToken failed. For example, controller 104(1) sends a RequestATokenFailed message to console 102(1). The RequestATokenFailed message in sequence 15 is one possible response 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 indicating why the authentication attempt failed. Once sequence 15 is complete, the failed authentication session can be terminated.

[0085] In some implementations, if console 102(1) receives a RequestATokenFailed message from controller 104(1), or if controller 104(1) fails to respond to a RequestAToken message, console 102(1) attempts to determine whether the authentication failure is the fault of controller 104(1) or authentication service 106. For example, controller 104(1) may have failed to obtain a valid AToken because controller 104(1) was a fake that presented an outdated CAD blob, or because authentication service 106 was unavailable (e.g., unresponsive).

[0086] For example, upon receiving a RequestATokenFailed message from controller 104(1), console 102(1) sends a CheckServiceStatus message to authentication service 106. If authentication service 106 responds with a ServiceHealthy message, console 102(1) informs the user that controller 104(1) is an unauthorized accessory and / or has an invalid license.

[0087] Alternatively, if authentication service 106 fails to respond to the CheckServiceStatus message or responds with an error message (or other indication that authentication service 106 and / or policy service 108 are out of date), console 102(1) ignores the failed authentication attempt by controller 104(1). In such a case, console 102(1) allows controller 104(1) to operate as if authentication was successful until authentication service 106 becomes healthy. For example, console 102(1) could periodically (hourly, daily, etc.) retry sending a CheckServiceStatus message to authentication service 106 until a ServiceHealthy message is received. This scheme allows controller 104(1) to operate even if authentication service 106 and / or policy service 108 are down, temporarily offline for scheduled maintenance, or are unable to authenticate accessories for some reason.

[0088] [process] 4 depicts a flow diagram of an exemplary authentication server method 400 according to some implementations of the present concepts. The authentication server method 400 is presented for illustrative purposes and is not intended to be comprehensive or limiting. The operations of the authentication server method 400 may be performed in the order presented, in a different order, in parallel or simultaneously, omitted, repeated, or include intermediate operations therebetween.

[0089] In operation 402, a communication channel is established with a client through a host. In one implementation, the client initiates contact to request communication. While the communication channel is logically used to exchange messages with the client, the communication channel is actually implemented through the host acting as a proxy to relay messages to and from the client. That is, messages intended for the client are actually sent to the host, which forwards the messages to the client. Also, messages from the client are actually received from the host, which forwards the messages from the client. The communication channel can be an encrypted channel. Establishing the communication channel can include exchanging certificates. For example, a client certificate is received that includes a client identifier associated with the client.

[0090] At operation 404, a request for a token is received from a client. The request is received via the communication channel established at operation 402. The token provides evidence that the client is authentic, authenticated, valid, and / or licensed. Thus, the request for a token is a request for authentication. In accordance with this 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.

[0091] At operation 406, it is determined whether the variable authentication data received from the client matches 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. At operation 406, a search is performed in the authentication database using the client identifier received at operation 402 to retrieve the most recent variable authentication data associated with the client. The retrieved most recent variable authentication data is also compared with the variable authentication data received in the request for the token at operation 404. If the two compared variable authentication data match, the client is considered authentic; if they do not match, the client is considered impersonated.

[0092] 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 over the communication channel established in operation 402. The failure message indicates that the variable authentication data provided by the client in the request for a token in operation 404 was not the most recent variable authentication data issued in association with the client identifier obtained while establishing the communication channel in operation 402. The failure message is sent in place of the token requested in operation 404. Thus, the client is considered an impostor, and a valid token (which provides proof of authenticity) is not provided to the client.

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

[0094] If the policy check determines that the existing variable authentication data should be updated, then new variable authentication data is generated in operation 412. The new variable authentication data is stored in association with the client identifier in the authentication database by replacing (e.g., overwriting) the existing variable authentication data. Thus, in accordance with this concept, the next authentication attempt by the client will be successful by supplying the new authentication data rather than the old authentication data.

[0095] At operation 414, the new variable authentication data is sent to the client. The new variable authentication data is sent over the communication channel established at operation 402. For example, a command to store the new variable authentication data is sent to the client, the command including the new variable authentication data as a payload (e.g., parameter). After operation 404, the client can send another request for a token using the new variable authentication data. In that case, server authentication method 400 repeats from operation 404 (or from operation 402).

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

[0097] At operation 418, the token is sent to the client. The token is sent over the communication channel established in operation 402. The issuance of the token to the client is a result of the client presenting current variable authentication data. Thus, the token serves as proof of the client's authenticity.

[0098] 5 depicts a flow diagram of an exemplary authentication client method 500 according to some implementations of the present concepts. The authentication client method 500 is presented for illustrative purposes and is not intended to be exhaustive or limiting. The operations of the authentication client method 500 may be performed in the order presented, in a different order, in parallel or simultaneously, omitted, repeated, or include intermediate operations therebetween.

[0099] At operation 502, a request for a token is received from a host. The host is requesting proof of authenticity because the token provides proof of authenticity. Other paradigms for proving authenticity may be used in addition to tokens. In one implementation, the request for a token includes an identification of a server from which the token can be obtained. The identification of the server may include a host name, an Internet Protocol (IP) address, or other identification that can be used to contact and / or communicate with the server. The request for a token may include a host identifier for the host.

[0100] At operation 504, a communication channel is established with the server via the host. In one implementation, a client initiates contact with the server to request communication. While the communication channel is logically used to exchange messages with the server, the communication channel is actually implemented via the host acting as a proxy to relay messages to and from the server. That is, messages intended for the server are actually sent to the host, which forwards the messages to the server. Also, messages from the server are actually received from the host, which forwards the messages from the server. The communication channel can be an encrypted channel. Establishing the communication channel can include exchanging certificates. For example, a client certificate containing a client identifier is sent to the server.

[0101] At operation 506, a request for a token is sent to the server. The request for the token is sent over the communication channel established at operation 504. In one implementation, the request for the token includes one variable authentication data. In another implementation, the request for the token includes multiple variable authentication data. In one implementation, the request for the token at operation 506 includes the host identifier received at operation 504. The server can respond to the request for the token in one of at least three ways. Three alternatives are described below.

[0102] In Alternative 1, the server has determined that the variable authentication data included in the request for the token in operation 506 is the most current variable authentication data and has determined that the variable authentication data should not be updated. Therefore, the token is received from the server in operation 508. The token is received via the communication channel established in operation 504.

[0103] The token is sent to the host at operation 510. That is, the token received from the server at operation 508 is presented to the host as evidence of successful authentication at operation 510. Sending the token to the host at operation 510 is one possible response to the request for the token received from the host at operation 502.

[0104] In Alternative 2, the server has determined that the variable authentication data included in the request for the token in operation 506 is the most current variable authentication data and that the variable authentication data should be updated. Therefore, new variable authentication data is received from the server in operation 512. The new variable authentication data is received via the communication channel established in operation 504.

[0105] The new variable authentication data is stored in operation 514. Storing the new variable authentication data replaces the old variable authentication data sent in the request for the token to the server in operation 506. Thus, any counterfeit device that attempts to authenticate by presenting the old variable authentication data to the server will be rejected. The new variable authentication data is stored persistently so that it can be presented to the server during future authentication attempts.

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

[0107] In Alternative 3, the server determines that the variable authentication data included in the request for the token in operation 506 is not the most recent variable authentication data and therefore rejects the request for the token. Thus, in operation 516, a failure message is received from the server. The failure message is received over the communication channel established in operation 504. The failure message may include an error code that indicates one of several reasons for the failure. For example, if a counterfeit device sends a request for a token that includes expired variable authentication data, the request for the token is rejected.

[0108] A failure message is sent to the host in operation 518. The failure message sent to the host in operation 518 is one possible response to the request for the token received from the host in operation 502.

[0109] [Technical advantages] The concepts described herein offer numerous technical advantages. For example, authenticating the accessory through the host allows the accessory to be a relatively simple (and / or small) device. For example, the accessory does not need to include a cellular modem chip or a Wi-Fi chip to connect to the Internet. Instead, the accessory communicates with the host to indirectly communicate with an authentication server. Thus, the accessory can simply communicate with the host using wires, Bluetooth, infrared, near-field communication (NFC), etc. Also, the accessory can implement a relatively lean protocol with a minimal number of commands (or messages) that can be executed by an embedded device, rather than implementing a large command suite included in a comprehensive protocol that requires more processing power, more memory, more storage, more power, etc. For example, the accessory can implement a small subset of the full TLS specification. Thus, the cost of the accessory can be lower. Furthermore, because the concepts do not require a separate security integrated circuit (IC), the cost of manufacturing the accessory is reduced.

[0110] Furthermore, the present concepts provide a software-based authentication scheme that does not need to be specialized as compared to previous solutions that rely on hardware security chips to resist counterfeiters. Therefore, the software-based authentication schemes described herein are less susceptible to manufacturing defects, manufacturing delays, labor costs, labor shortages, supply chain bottlenecks, weather-related catastrophes, and the like. The reduced hardware requirements also provide the advantage of easier modification. That is, the present concepts, which use software-based authentication techniques, are more versatile, i.e., they can be changed more easily, faster, and cheaper by modifying the software, e.g., via updates or patches. For example, the authentication protocol can be updated via software updates without any hardware modifications. Furthermore, the authentication protocol can be implemented with the existing hardware of the accessory originally designed and manufactured to implement the authentication protocol.

[0111] This concept takes advantage of the ease of updating software data in client devices by issuing and frequently changing variable authentication data stored in the client device (e.g., an accessory). While a counterfeiter can copy and install the same client certificate into multiple clones, it is extremely difficult for them to copy and install variable authentication data into multiple clones. Furthermore, even if a counterfeiter were to copy and install variable authentication data into multiple clones, the clones would not function because this concept dynamically changes the variable authentication data. And, of course, it would be virtually impossible for a counterfeiter to continually copy all newly issued variable authentication data into all multiple clones. Thus, this concept provides an inexpensive, versatile, and reliable authentication technique for deterring cloning.

[0112] [application] The present concept and many of the embodiments above have been described in the context of authenticating a video game controller as an accessory device. However, the present concept has a much wider variety of applications. The present concept can be implemented with any client that needs to be authenticated, as long as the client is capable of storing, overwriting, and presenting variable authentication data. A client can be any hardware device (e.g., a video game controller, a video game console, a computer, a smartphone, a tablet, headphones, a keyboard, a card, a badge, a car, a key, a switch, a watch, a camera, a storage device, a remote control, an appliance, an integrated circuit, a wearable, etc.) or any software module (e.g., an application, a program, a game, a file, a service, an operating system, a driver, etc.). A host can be any hardware device or any software module that can facilitate communication between a client and a server. For example, a host can be a video game console, a computer, a car, a door, a switch, an elevator, or any hardware or software that can enable, disable, accept, reject, detect, use, or interact with a client.

[0113] [example] Various examples are described above. Further examples are described below. As an example, a system includes a storage including first variable authentication data and a processor that executes instructions, the instructions causing the processor to receive a first request for a token from a host, establish a communications channel with a server via the host, and 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.

[0114] As another example, any of the above and / or below examples, wherein the instructions further cause the processor to receive second variable authentication data from the server.

[0115] As another example, any of the above and / or below examples, wherein the instructions further cause the processor to store second variable authentication data in storage.

[0116] Another example is any of the examples above and / or below, where second variable authentication data is stored in storage to replace first variable authentication data in storage.

[0117] As another example, any of the above and / or below examples, wherein the instructions further cause the processor to send a third request for the token, the third request including the second variable authentication data.

[0118] Another example is any 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.

[0119] Another example is any of the examples above and / or below, in which the second request is sent and the token is received over a communication channel.

[0120] As another example, there is 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 via the host, send a second request for the token to the server via the communication channel, the second request including first variable authentication data, receive the token from the host via the communication channel, and send the token to the host in response to the first request.

[0121] As another example, in any of the above and / or below examples, the instructions further cause the processor to receive, via the communications channel, second variable authentication data from the server, the second variable authentication data being different from the first variable authentication data.

[0122] As another example, 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.

[0123] As another example, 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 over the communications channel, the third request including the second variable authentication data.

[0124] Another example is any of the above and / or below examples, wherein the first request includes a host identifier for the host and the second request includes the host identifier.

[0125] As another example, there is a computer-implemented method having the steps of establishing a communication channel for a client through a host; receiving a first request for a token from the host, 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 the second variable authentication data should be updated; in response to determining that the second variable authentication data should be updated, generating third variable authentication data; and sending the third variable authentication data to the client.

[0126] As another example, any of the above and / or below examples, wherein the method further comprises checking one or more policies to determine whether the second variable authentication data should be updated.

[0127] As another example, any of the above and / or below examples, wherein the method further comprises, in response to determining that the second variable authentication data should not be updated, generating a token and sending the token to the client.

[0128] As another example, any of the above and / or below examples, wherein the method further comprises, in response to determining that the first variable authentication data does not match the second variable authentication data, sending a failure message to the client.

[0129] As another example, any of the above and / or below examples, wherein the method further comprises storing third variable authentication data.

[0130] As another example, any of the above and / or below examples, wherein the method further comprises replacing the second variable authentication data with third variable authentication data.

[0131] Another example is any of the above and / or below examples, in which the first request is received and the third variable authentication data is sent over a communications channel.

[0132] As another example, any of the above and / or below examples, wherein the method further comprises receiving a second request from the host to validate the token and sending a message to the host validating the token.

Claims

1. a storage containing first variable authentication data; a processor for executing instructions; The instructions cause the processor to: receiving a first request for a token from a host; establishing a communication channel with a server via said host; sending a second request for the token to the server, the second request including the first variable authentication data; receiving the token from the server; transmitting the token to the host; A system that executes the following.

2. The instructions further cause the processor to receive second variable authentication data from the server. The system of claim 1 .

3. The instructions further cause the processor to store the second variable authentication data in the storage. The system of claim 2 .

4. storing the second variable authentication data in the storage replaces the first variable authentication data in the storage; The system of claim 3 .

5. The instructions further cause the processor to send a third request for the token, the third request including the second variable authentication data. The system of claim 2 .

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

7. the second request is sent and the token is received over the communication channel; The system of claim 1 .

8. the communication channel is an encrypted communication channel. The system of claim 1 .

9. The system includes a video game controller. The system of claim 1 .

10. instructions that, when executed by a processor, cause the processor to: receiving a first request for a token from a host; establishing a communication channel with a server via said host; sending a second request for the token to the server over the communication channel, the second request including first variable authentication data; receiving the token from the host via the communication channel; transmitting the token to the host in response to the first request; A computer-readable storage medium that causes the computer to execute the method.

11. The instructions further cause the processor to: receiving second variable authentication data from the server via the communication channel; the second variable authentication data is different from the first variable authentication data; The computer-readable storage medium of claim 10.

12. The instructions further cause the processor to store the second variable authentication data by replacing the first variable authentication data. The computer-readable storage medium of claim 11.

13. The instructions further cause the processor to: sending a third request for the token to the server via the communication channel; the third request includes the second variable authentication data; The computer-readable storage medium of claim 12.

14. the first request includes a host identifier for the host; the second request includes the host identifier; The computer-readable storage medium of claim 10.

15. the communication channel is an encrypted communication channel. The computer-readable storage medium of claim 10.

Images