Privacy protection using one-time authorization codes

Abstract

Methods and systems for communicating with an access control system are provided. The methods and systems, prior to establishing a secure channel between a first device and a second device, establish, between the first device and the second device, a first static privacy key. The methods and systems access, by the first device, a first random nonce that has been generated by the second device and compute, by the first and second devices, a first session key based on the first static privacy key and the first random nonce. The methods and systems generate, by the first device, a first one-time authorization code based on the first session key and a current counter value, the current counter value representing a quantity of requests sent by the first device and transmit, by the first device to the second device, a first request that is combined with the first one-time authorization code.

Description

PRIVACY PROTECTION USING ONE-TIME AUTHORIZATION CODESBACKGROUND

[0001] Access control readers are widely used in various settings to control access to restricted areas. These readers are typically connected to a server that manages access control policies and configurations. In order to securely communicate with such readers, user devices employ various encryption protocols.SUMMARY

[0002] In some aspects, the techniques described herein relate to a method including: prior to establishing a secure channel between a first device and a second device, establishing, between the first device and the second device, a first static privacy key; accessing, by the first device, a first random nonce that has been generated by the second device; computing, by the first and second devices, a first session key based on the first static privacy key and the first random nonce; generating, by the first device, a first onetime authorization code based on the first session key and a current counter value, the current counter value representing a quantity of requests sent by the first device; and transmitting, by the first device to the second device, a first request that is combined with the first one-time authorization code. The one-time authorization code may consist of a message authentication code (MAC) that is computed with the first session key over the concatenation of the current counter value and of one or more portions of the first request. In some cases, the entire first request is covered by MAC computation. In other cases, only the privacy-sensitive information (namely, any information enabling to track a user, to distinguish a user from other users, or even to identify a user), if any, contained in the first request is covered by MAC computation. For example, an authentication request may contain an authentication object reference and an ephemeral public key referring to a fixed set of domain parameters. The only privacy-sensitive information, in such cases, which may need to be covered by MAC computation is the object reference, while there is no need for the (much longer) ephemeral public key to be covered by MAC computation, as it cannot leak any privacy-sensitive information. In some cases, the computation of any one-time authorization code discussed below, alsoreferred to as the MAC, may be computed using the CMAC algorithm according to NIST SP 800-38B, or the GMAC algorithm according to NIST SP 800-38D.

[0003] In some aspects, the techniques described herein relate to a method, further including: computing, by the second device, an expected value for the first one-time authorization code based on the current counter value and the first request; determining that the expected value for the first one-time authorization code matches the first onetime authorization code; and in response to determining that the expected value for the first one-time authorization code matches the first one-time authorization code, establishing the secure channel between the first device and the second device.

[0004] In some aspects, the techniques described herein relate to a method, further including: determining that a configuration setting has been set to prevent leakage of privacy-sensitive information via passive eavesdropping; and in response to determining that the configuration setting has been set to prevent leakage of privacy-sensitive information via passive eavesdropping, encrypting one or more portions of the first request that are transmitted to the second device using at least one of the first session key or the first static privacy key. In some cases, the entire first request is encrypted. In other cases, only certain privacy-sensitive information, if any, are encrypted. For example, an authentication request may contain an authentication object reference and an ephemeral public key referring to a fixed set of domain parameters. The only privacy-sensitive information, in such cases, which may need encryption is the object reference while there is no need to encrypt the (much longer) ephemeral public key, as it cannot leak any privacy-sensitive information. If a distinct session key has been computed for this purpose, encryption is performed using that key, otherwise the same session key used to compute one-time authorization codes is also used for encryption. For example, encryption may be performed using a block cipher in CBC mode according to NIST SP 800-38 A, or a block cipher in GCM mode according to NIST SP 800-38D. In the latter case, encryption may be applied to the same concatenation of the current counter value and of one or more portions of the first request as with the computation of the one-time authorization code. If so, the resulting authentication tag may be used as the one-time authorization code, so that a single session key is sufficient.

[0005] In some aspects, the techniques described herein relate to a method, further including: transmitting, by the first device to the second device, a request to select a firstcontext; and generating the first random nonce in response to the second device receiving the request to select the first context, the first random nonce being transmitted by the second device in response to successfully selecting the first context.

[0006] In some aspects, the techniques described herein relate to a method, further including: determining that a current context on the second device is a first context; receiving, from the first device, a request to switch the current context from the first context to a second context; and generating the first random nonce in response receiving, from the first device, the request to switch the current context from the first context to the second context. In some cases, the first random nonce may not be generated in response to switching contexts but rather when a request for a random nonce is received, such as via a GET CHALLENGE command if ISO / IEC 7816-4 APDU is supported.

[0007] In some aspects, the techniques described herein relate to a method, wherein the first context is at least one of a global context or a local context, and wherein the second context is at least a different one of the global context or the local context.

[0008] In some aspects, the techniques described herein relate to a method, wherein the first request includes privacy-sensitive information.

[0009] In some aspects, the techniques described herein relate to a method, wherein the privacy-sensitive information may include at least one of an authentication object reference for an authentication request or a file reference identifier for a file access request.

[0010] In some aspects, the techniques described herein relate to a method, further including: establishing, between the first device and the second device, a second static privacy key, the first static privacy key being associated with a first context and the second static privacy key being associated with a second context; determining whether a current context corresponds to the first context or the second context; and computing the first session key based on either the first static privacy key or the second static privacy key in response to determining whether the current context corresponds to the first context or the second context.

[0011] In some aspects, the techniques described herein relate to a method, further including: determining that the current context corresponds to the first context; determining whether a new random nonce has been generated; and computing the first session key based on the first static privacy key and based on either the first randomnonce or the new random nonce in response to determining that the current context corresponds to the first context.

[0012] In some aspects, the techniques described herein relate to a method, further including: receiving, by the second device, a request to switch the current context from the second context to the first context; in response to receiving the request to switch the current context from the second context to the first context, generating the new random nonce; and using the new random nonce to compute the first session key.

[0013] In some aspects, the techniques described herein relate to a method, further including: receiving, by the second device, a request to switch the current context from the second context to the first context; in response to receiving the request to switch the current context from the second context to the first context, determining that a new random nonce has not been generated; and using the first random nonce corresponding to a latest random nonce to compute the first session key.

[0014] In some aspects, the techniques described herein relate to a method, further including: transmitting, by the first device, an additional request to switch the current context; in response to transmitting the additional request to switch the current context, receiving a second random nonce from the second device; and computing, by the first and second devices, a second session key based on the second static privacy key and the second random nonce in response to determining that the current context corresponds to the second context.

[0015] In some aspects, the techniques described herein relate to a method, further including: updating the current counter value by incrementing the current counter value in response to generating a second request; generating, by the first device, a second onetime authorization code based on the second session key and the updated current counter value; and transmitting, by the first device to the second device, a second request that is combined with the second one-time authorization code.

[0016] In some aspects, the techniques described herein relate to a method, further including: computing, by the second device, an expected value for the first one-time authorization code based on the current counter value and the first request; determining that the expected value for the first one-time authorization code fails to match the first one-time authorization code; and in response to determining that the expected value forthe first one-time authorization code fails to match the first one-time authorization code, returning a fixed error code to the first device as response without any other data.

[0017] In some aspects, the techniques described herein relate to a method, further including: determining whether the expected value for the first one-time authorization code matches the first one-time authorization code prior to executing any other semantic processing of the first request.

[0018] In some aspects, the techniques described herein relate to a method, wherein the first request is transmitted in plain text along with the first one-time authorization code.

[0019] In some aspects, the techniques described herein relate to a method, wherein the first session key is computed by encrypting the first random nonce with the first static privacy key. For example, the first session key (and any other session key mentioned below) can be computed by applying a key derivation function specified in NIST SP 800-108.

[0020] In some aspects, the techniques described herein relate to a system including: one or more processors coupled to a memory including non-transitory computer instructions that, when executed by the one or more processors, cause the one or more processors to perform operations including: prior to establishing a secure channel between a first device and a second device, establishing, between the first device and the second device, a first static privacy key; accessing, by the first device, a first random nonce that has been generated by the second device; computing, by the first and second devices, a first session key based on the first static privacy key and the first random nonce; generating, by the first device, a first one-time authorization code based on the first session key and a current counter value, the current counter value representing a quantity of requests sent by the first device; and transmitting, by the first device to the second device, a first request that is combined with the first one-time authorization code.

[0021] In some aspects, the techniques described herein relate to a non-transitory computer readable medium including non-transitory computer-readable instructions that, when executed by one or more processors, configure the one or more processors to perform operations including: prior to establishing a secure channel between a first device and a second device, establishing, between the first device and the second device, a first static privacy key; accessing, by the first device, a first random nonce that has been generated by the second device; computing, by the first and second devices, a firstsession key based on the first static privacy key and the first random nonce; generating, by the first device, a first one-time authorization code based on the first session key and a current counter value, the current counter value representing a quantity of requests sent by the first device; and transmitting, by the first device to the second device, a first request that is combined with the first one-time authorization code.BRIEF DESCRIPTION OF THE DRAWINGS

[0022] FIG. l is a block diagram of an example access control system, according to some examples.

[0023] FIG. 2 illustrates an example diagram of a flow representing privacy- strengthened authentication, according to some examples.

[0024] FIG. 3 is a flowchart illustrating example operations of the access control system, according to some examples.

[0025] FIG. 4 is a block diagram illustrating an example software architecture, which may be used in conjunction with various hardware architectures herein described.

[0026] FIG. 5 is a block diagram illustrating components of a machine, according to some examples.DETAILED DESCRIPTION

[0027] In a security product, such as a secure personal identification product for physical access control (generically referred to as a request responder), access to sensitive resources is conditional on a successful authentication by the other party (generically referred to as a request initiator) and takes place over the ensuing secure channel. Thus, an attacker sending requests for access to those resources or listening to the encrypted responses to such requests (e.g., without knowing an authentication key) would not obtain any privacy-sensitive information, namely any information enabling to track a user, to distinguish a user from other users, or even to identify a user. However, that protection does not apply to requests possibly accepted prior to a successful authentication, so that they may leak privacy-sensitive information.

[0028] For example, authentication requests themselves cannot be protected. Even if a chain of consecutive, increasing authentications is supported, access to the first authentication in the chain has to be free. Hence, an attacker could leak privacy-sensitiveinformation by probing a request responder with authentication requests and listening to the responses, regardless of their ignorance of authentication keys. The access conditions to some files may differ depending on the user, so that access is free for some users and demands authentication for some other ones. Likewise, some files may be present for some users and absent from some other ones. Hence, an attacker could leak privacysensitive information by probing a request responder with file access requests and listening to the responses.

[0029] In certain cases where the protection of user’s privacy is a concern, an attacker should be prevented from obtaining privacy-sensitive information by actively probing the request responder with requests possibly accepted prior to a successful authentication, or by passively eavesdropping on such requests and their (plain) responses. This can be referred to as the motivating privacy goal. To cope with the motivating privacy goal, conventional systems make the request responder answer to unsuccessful requests prior to a successful authentication by returning shill responses which fake those types of responses that are generated in case of success. For example, shill authentication responses in case of an unsuccessful authentication request, or shill file access responses in case of unsuccessful file access requests.

[0030] These conventional approaches have some drawbacks. Shill responses are ineffective against the leakage of privacy-sensitive information possibly resulting from passive eavesdropping on successful plain requests and their responses. Also, since timing differences between successful and unsuccessful request processing are a side channel possibly leaking privacy-sensitive information, shill responses must be timeinvariant with respect to those output in case of success. Yet, time invariance is difficult to implement and test effectively. In order to generate a shill response, an implementation generally has to make decisions among multiple possible options, precisely as happens with responses output in case of success which adds complexity. For example, a shill authentication response may have to pick out among multiple possible authentication options and a shill file access response may have to pick out among multiple possible options for file features. In some cases, an implementation can get information on the options to pick out from the incoming request or from a default configuration. However, it is generally unlikely that all the needed information can be drawn from the incoming request alone.

[0031] Consequently, some default configuration for shill responses is generally required. Such a default configuration has to be uniform across users, as differences in shill responses for distinct users may leak privacy-sensitive information. Furthermore, for the same reason, actual configurations have to conform to the default one. As a result, shill responses enable the motivating privacy goal to be achieved only partially, and they give rise to significant additional complexity for implementation, testing, and deployment.

[0032] The present disclosure provides a mechanism to fully achieve the motivating privacy goal without the aforesaid complexity side effects using inexpensive cryptographic computations upon each request possibly accepted prior to a successful authentication. Specifically, the disclosed examples provide an intelligent solution, which can operate and communicate with the access control system quickly, securely, and efficiently without revealing private information to an unauthorized party. In this way, communication with the access control readers can be performed quickly, securely, and efficiently, which improves the overall functioning of the system.

[0033] The disclosed examples, prior to establishing a secure channel between a first device and a second device, establish, between the first device and the second device, a first static privacy key. The disclosed examples access, by the first device, a first random nonce that has been generated by the second device and compute, by the first and second devices, a first session key based on the first static privacy key and the first random nonce. The disclosed examples generate, by the first device, a first one-time authorization code based on the first session key and a current counter value, the current counter value representing a quantity of requests sent by the first device. The first device to the second device transmits a first request that is combined with the first one-time authorization code.

[0034] FIG. 1 is a block diagram showing an example system 100, according to various examples. The system 100 can be an access control system that includes a client device 120, one or more access control devices 110 that control access to a protected asset or secure resource, such as through a lockable door, and a server / controller 140 that are communicatively coupled over a network 130 (e.g., LAN, WAN such as the Internet, WiFi, BLE, ultra-wideband (UWB) communication protocol, telephony network, or other wired or wireless communication protocols).

[0035] The client device 120 and the access control devices 110 can be communicatively coupled via electronic messages (e.g., packets exchanged over the Internet, BLE, UWB, WiFi Direct, NFC, or any other protocol). While FIG. 1 illustrates a single access control device 110 and a single client device 120, it is understood that a plurality of access control devices 110 and a plurality of client devices 120 can be included in the system 100 in other examples. As used herein, the term “client device” may refer to any machine that interfaces to a communications network (such as network 130) to exchange credentials with an access control device 110, the server / controller 140, another client device 120, or any other component to obtain access to the asset or resource protected by the access control device 110. In some examples, the client device 120 can additionally or alternatively communicate directly with, e.g., an access control device or another client device 120. The term “first device,” as referred to here, can include the client device 120 and the term “second device,” can include the controller 140. In some cases, the roles can be reversed where the first device can include the controller 140 and the second device, can include the client device 120.

[0036] In some cases, some or all of the components and functionality of the server / controller 140 can be included in the client device 120 and / or the access control device 110. A client device 120 may be, but is not limited to, a mobile phone, desktop computer, laptop, portable digital assistant (PDA), smart phone, a wearable device (e.g., a smart watch), tablet, ultrabook, netbook, laptop, multi-processor system, microprocessor-based or programmable consumer electronics, or any other communication device that a user may use to access a network.

[0037] The access control device 110 can include an access reader device (also referred to as an access control reader) connected to a secure / protected resource (e.g., a door locking mechanism or backend server) that controls the secure / protected resource (e.g., door locking mechanism). The resource associated with the access control device 110 can include a door lock, an ignition system for a vehicle, or any other device that grants or denies access to a physical component or that can be operated to grant or deny access to the physical component. For example, in the case of a door lock, the access control device 110 can deny access, in which case the door lock remains locked and the door cannot be opened; or can grant access, in which case the door lock becomes unlocked to allow the door to be opened. As another example, in the case of an ignition system, theaccess control device 110 can deny access, in which case the vehicle ignition system remains disabled and the vehicle cannot be started; or can grant access, in which case the vehicle ignition becomes enabled to allow the vehicle to be started.

[0038] Physical access control covers a range of systems and methods to govern access, for example by people, to secure areas or secure assets. Physical access control includes identification of authorized users or devices (e.g., vehicles, drones, etc.) and actuation of a gate, door, or other facility used to secure an area or actuation of a control mechanism, e.g., a physical or electronic / software control mechanism, permitting access to a secure asset. The access control device 110 forms part of a physical access control system (PACS), which can include a reader (e.g., an online or offline reader) that may hold authorization data (also referred to access control information) and can be capable of determining whether credentials (e.g., from credential or key devices such as radio frequency identification (RFID) chips in cards, fobs, or personal electronic devices such as mobile phones) are authorized for an actuator or control mechanism (e.g., door lock, door opener, software control mechanism, turning off an alarm, etc.), or a PACS can include a host server to which readers and actuators are connected (e.g., via a controller) in a centrally managed configuration.

[0039] In centrally managed configurations, readers can obtain credentials from credential or key devices and pass those credentials to the PACS host server or headend system. The readers can send the credentials over a wired or wireless link. The host server then determines whether the credentials authorize access to the secure area or secure asset and commands the actuator or other control mechanism accordingly by sending an allow / deny message back to the reader again over the wired or wireless link. While examples in physical access control are used herein, the disclosure applies equally to logical access control system (LACS) use cases (e.g., logical access to personal electronic devices, rider identification in transport services, access and asset control in unmanned stores, access to certain files, and so forth).

[0040] In general, the access control device 110 can include one or more of a memory, a processor, one or more antennas, a communication module, a network interface device, a user interface, and a power source or supply. The memory of the access control device 110 can be used in connection with the execution of application programming or instructions by the processor of the access control device 110, and for the temporary orlong-term storage of program instructions or instruction sets and / or credential or authorization data, such as credential data, credential authorization data, or access control data or instructions. For example, the memory can contain executable instructions that are used by the processor to run other components of access control device 110 and / or to make access determinations based on credential or authorization data. The memory of the access control device 110 can comprise a computer readable medium that can be any medium that can contain, store, communicate, or transport data, program code, or instructions for use by or in connection with access control device 110. The computer readable medium can be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device. More specific examples of suitable computer readable medium include, but are not limited to, an electrical connection having one or more wires or a tangible storage medium such as a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), Dynamic RAM (DRAM), any solid-state storage device in general, a compact disc read-only memory (CD-ROM), or other optical or magnetic storage device. Computer-readable media includes, but is not to be confused with, computer-readable storage medium, which is intended to cover all physical, non- transitory, or similar examples of computer-readable media.

[0041] The processor of the access control device 110 can correspond to one or more computer processing devices or resources. For instance, the processor can be provided as silicon, as a Field Programmable Gate Array (FPGA), an Application-Specific Integrated Circuit (ASIC), any other type of Integrated Circuit (IC) chip, a collection of IC chips, or the like. As a more specific example, the processor can be provided as a microprocessor, Central Processing Unit (CPU), or plurality of microprocessors or CPUs that are configured to execute instructions sets stored in an internal memory and / or memory of the access control device 110.

[0042] The antenna of the access control device 110 can correspond to one or multiple antennas and can be configured to provide for wireless communications between access control device 110 and a credential or key device (e.g., client device 120). The antenna can be arranged to operate using one or more wireless communication protocols and operating frequencies including, but not limited to, the IEEE 802.15.1, Bluetooth, BLE,NFC, ZigBee, Global System for Mobile communications (GSM), Code Division Multiple Access (CDMA), Wi-Fi, RF, UWB, and the like. By way of example, the antenna(s) can be RF antenna(s), and as such, may transmit / receive RF signals through free-space to be received / transferred by a credential or key device having an RF transceiver.

[0043] A communication module of the access control device 110 can be configured to communicate according to any suitable communications protocol with one or more different systems or devices either remote or local to access control device 110, such as one or more client devices 120 and / or server / controller 140. In some cases, the communication module of the access control device 110 is configured to perform the disclosed authentication protocol. Namely, the communication module can be implemented as part of the access control device 110 and / or the client device 120 to perform the privacy-strengthened authentication protocol, discussed in connection with FIG. 2.

[0044] In some cases, the communication module uses a same wired or wireless link between the access control device 110 and the controller 140 for all the communication modes. In some cases, the communication module uses one wired or wireless link between the access control device 110 and the controller 140 to communicate access control information and uses a different wired or wireless link to communicate or receive configuration information updates from the controller 140 over an Internet-Protocol (IP) communication mode.

[0045] The network interface device of the access control device 110 includes hardware to facilitate communications with other devices, such as a one or more client devices 120 and / or server / controller 140 (e.g., a PACS server), over a communication network, such as network 130, utilizing any one of a number of transfer protocols (e.g., frame relay, IP, transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.). Example communication networks can include a LAN, a WAN, a packet data network (e.g., the Internet), mobile telephone networks (e.g., cellular networks), Plain Old Telephone (POTS) networks, wireless data networks (e.g., IEEE 802.11 family of standards known as Wi-Fi, IEEE 802.16 family of standards known as WiMax), IEEE 802.15.4 family of standards, and peer-to-peer (P2P) networks, among others. In some examples, network interface device can include an Ethernet port or otherphysical jack, a Wi-Fi card, a Network Interface Card (NIC), a cellular interface (e.g., antenna, filters, and associated circuitry), or the like. In some examples, network interface device can include a plurality of antennas to wirelessly communicate using at least one of single-input multiple-output (SIMO), multiple-input multiple-output (MIMO), or multiple-input single-output (MISO) techniques.

[0046] A user interface of the access control device 110 can include one or more input devices and / or display devices. Examples of suitable user input devices that can be included in the user interface include, without limitation, one or more buttons, a keyboard, a mouse, a touch-sensitive surface, a stylus, a camera, a microphone, and so forth. Examples of suitable user output devices that can be included in the user interface include, without limitation, one or more LEDs, an LCD panel, a display screen, a touchscreen, one or more lights, a speaker, and so forth. It should be appreciated that the user interface can also include a combined user input and user output device, such as a touch-sensitive display or the like.

[0047] The network 130 may include, or operate in conjunction with, an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a LAN, a wireless network, a wireless LAN (WLAN), a WAN, a wireless WAN (WWAN), a metropolitan area network (MAN), BLE, UWB, the Internet, a portion of the Internet, a portion of the Public Switched Telephone Network (PSTN), a POTS network, a cellular telephone network, a wireless network, a Wi-Fi® network, another type of network, or a combination of two or more such networks. For example, a network or a portion of a network may include a wireless or cellular network and the coupling may be a CDMA connection, a GSM connection, or other type of cellular or wireless coupling. In this example, the coupling may implement any of a variety of types of data transfer technology, such as Single Carrier Radio Transmission Technology (IxRTT), Evolution- Data Optimized (EVDO) technology, General Packet Radio Service (GPRS) technology, Enhanced Data rates for GSM Evolution (EDGE) technology, third Generation Partnership Project (3 GPP) including 3G, fourth generation wireless (4G) networks, fifth generation wireless (5G) networks, Universal Mobile Telecommunications System (UMTS), High Speed Packet Access (HSPA), Worldwide Interoperability for Microwave Access (WiMAX), Long Term Evolution (LTE) standard, others defined by variousstandard setting organizations, other short range or long range protocols, or other data transfer technology.

[0048] In some examples, as the client device 120 approaches the access control device 110 (e.g., comes within range of a BLE communication protocol), the client device 120 transmits credentials of the client device 120 over the network 130. In some cases, the credentials can be selected from a plurality of credentials based on a current geographical location of the client device 120. For example, multiple credentials, each associated with a different geographical location, can be stored on the client device 120. When the client device 120 comes within a certain distance of a geographical location associated with one of the credentials (e.g., within 10 meters), the client device 120 retrieves the associated credentials from local memory.

[0049] In some examples, the client device 120 provides the credentials directly to the access control device 110. In such cases, the access control device 110 communicates the credentials with the server / controller 140. The server / controller 140 in FIG. 1 includes an authorization system 142. The server / controller 140, client device 120, and / or the access control device 110 can further include elements described with respect to FIGS. 4 and 5, such as a processor and memory, having instructions stored thereon, that when executed by the processor, cause the processor to control the functions of the server / controller 140, client device 120, and / or the access control device 110.

[0050] The server / controller 140 searches a list of credentials stored in the authorization system 142 to determine whether the received credentials match credentials from the list of authorized credentials for accessing a secure asset or resource (e.g., door or secure area) protected by the access control device 110. In response to determining that the received credentials are authorized to access the access control device 110, the server / controller 140 instructs the access control device 110 to perform an operation granting access for the client device 120 (e.g., instructing the access control device 110 to unlock a lock of a door). In another example, the client device 120 provides the credentials to the server / controller 140, such as using the shared secret key.

[0051] The server / controller 140 searches a list of credentials stored in the authorization system 142 to determine whether the received credentials match credentials from the list of authorized credentials for accessing a secure asset or resource (e.g., door or secure area) protected by the access control device 110. In response to determiningthat the received credentials are authorized to access the access control device 110, the server / controller 140 instructs the access control device 110 (associated with the received credentials and within a geographical distance of the client device 120) to perform an operation granting access to the client device 120 (e.g., instructing the access control device 110 to unlock a lock of a door).

[0052] In some examples, the client device 120 and the access control device 110 can initially establish an unsecure communication channel. Over this unsecure communication channel (e.g., prior to the client device 120 and the access control device 110 authenticating each other), the client device 120 and the access control device 110 can select between various symmetric static privacy keys based on a context being used. For example, a local context associated with accessing individual files or leaves connected to a root node can be associated with a first symmetric static privacy key and a global context associated with accessing a root file or root node can be associated with a second symmetric static privacy key. While the disclosed examples pertain to a single global context and a single local context each associated with its own privacy key, any arbitrary quantity of local / global context can be similarly selected each with its own privacy key in a similar manner. The selection or switching between a local context and another local context and / or between one global context and another global context or local context can trigger the generation of the random nonce, as discussed below.

[0053] Once the appropriate static privacy key is selected, a random nonce can be used to generate a session privacy key. This session privacy key can be used to generate one or more one-time authorization codes or proofs that are combined or concatenated with one or more requests. The one or more one-time authorization codes or proofs are used by the recipient device to check the authenticity of the request before any semantic operations are performed in association with the one or more requests. The one or more one-time authorization codes or proofs can be dynamically generated for each request that is generated to ensure that each request is uniquely authenticated by the recipient. After a certain request or certain sequence of requests are generated and exchanged in this manner, a secure channel is established. Subsequent requests and responses can be exchanged over the secure channel with or without generating additional one-time authorization codes or proofs.

[0054] FIG. 2 illustrates an example diagram 200 of a flow representing privacy- strengthened authentication, according to some examples. As shown in the diagram 200, a request initiator 210 (e.g., a client device 120) and a request responder 220 (e.g., access control device 110) can communicate over an unsecured network channel. Initially, the request initiator 210 can transmit a request 212 for a first random nonce R, such as by sending a request to select a first context (e.g., a global context). The random nonce can be generated and sent from the request responder 220 to the request initiator 210 in response to the request 212 from the request initiator 210 for a new random nonce to be provided and / or in response to changing contexts from the first to the second context and / or in response to changing contexts from the second to the first context. In some examples, the request responder 220, in response to receiving the request 212 to select the first context (and / or in response to a specific request to generate a random nonce), can generate a response 214 that includes the first random nonce 216 (e.g., random nonce R). Additionally, each of the request initiator 210 and the request responder 220 can select a first symmetric static privacy key 232 that corresponds to and is associated with the first context.

[0055] The request initiator 210 can generate a first session privacy key 230 using the first random nonce 216 and the first symmetric static privacy key 232. Similarly, the request responder 220 can generate the same first session privacy key 230 using the first random nonce 216 and the first symmetric static privacy key 232. The first session privacy key 230 can be generated (computed) by encrypting the first random nonce 216 by the first symmetric static privacy key 232. Alternatively, the first session privacy key 230 can be generated (computed) by applying a key derivation function specified in an encryption protocol. The request initiator 210 and the request responder 220 can generate new session privacy keys each time a new random nonce is generated and exchanged between the request initiator 210 and the request responder 220 and / or each time context is switched from the first context to the second or vice versa. If the request initiator 210 and the request responder 220 generate a new session privacy key, the request initiator 210 and the request responder 220 can either use a newly exchanged random nonce to generate the new session privacy key (if the new random nonce is generated and exchanged) and / or can use the last exchanged random nonce to generate the new session privacy key (e.g., if no new random nonce was generated and exchanged). Specifically, while the disclosed examples pertain to two round trip communications each with itsown one-time authorization codes, any arbitrary quantity of round trip communications can be performed each generating and being associated with its own one-time authorization code.

[0056] In some examples, the request initiator 210 and the request responder 220 can store a configuration setting which indicates whether or not leakage of privacy-sensitive information (e.g., any information enabling to track a user, to distinguish a user from other users, or even to identify a user) via passive eavesdropping needs to be prevented. In response to determining that the configuration setting has been set to prevent leakage of privacy-sensitive information via passive eavesdropping, an additional separate session privacy key can be generated by the request initiator 210 and the request responder 220. The additional separate session privacy key can be generated using the first random nonce 216 and the first symmetric static privacy key 232.

[0057] The request initiator 210 can generate a first request 244 which may or may not include privacy information (e.g., Request #1). The request initiator 210 can also access a current request counter 242 which tracks how many request messages have been sent by the request initiator 210. The request initiator 210 can generate a first one-time authorization code or proof 240 based on the first session privacy key 230 and the current request counter 242. The first one-time authorization code or proof 240 can further be generated based on the content of the first request 244 including the privacy information. The first one-time authorization code or proof 240 can be referred to as a first Message Authentication Code (MAC) (MAC #1).

[0058] The request initiator 210 can generate a message 246 in which the first request 244 is concatenated or otherwise combined with the first one-time authorization code or proof 240. The request initiator 210 transmits the message 246 to the request responder 220 in plain text (without encryption). In some cases, the request initiator 210 determines whether the configuration setting has been set to prevent leakage of the privacy information. If so, the request initiator 210 can encrypt the message 246 prior to sending the message 246 to the request responder 220 using the additional separate session privacy key that has been generated. For example, the message 246 can be encrypted using a block cipher in CBC mode according to NIST SP 800-38 A, or a block cipher in GCM mode according to NIST SP 800-38D.

[0059] The request responder 220, upon receiving the message 246, can process the message 246. Namely, the request responder 220 determines whether the configuration setting has been set to prevent leakage of the privacy information. If so, the request responder 220 can decrypt the message 246 using the additional separate session privacy key that has been generated prior to verifying or checking its authenticity. If the configuration setting has not been set to prevent leakage of the privacy information, the request responder 220 can avoid decrypting the message 246 and can, in response to receiving the message 246, verify or check its authenticity. As mentioned above, while the disclosed examples pertain to a specified quantity of round trip communications each causing one or more session privacy keys to be generated, any quantity of session privacy keys can be generated whenever a logical context equipped with its own static privacy key is selected on the request responder or a fresh random nonce is generated by the request responder, as discussed above and below.

[0060] In some examples, the request responder 220 checks the authenticity of the message 246 using the proof 240 included in the message 246. Specifically, the request responder 220 can first check wither the message 246 includes the first one-time authorization code or proof 240. Then, the request responder 220 can generate an expected value for the first one-time authorization code or proof 240 in response to determining that the first one-time authorization code or proof 240 is included in the message 246.

[0061] In some examples, to check the value of the first one-time authorization code or proof 240, the request responder 220 accesses the current request counter 242 (e.g., from local storage) which is incremented each time a request is received from the request initiator 210. The request responder 220 can generate the expected value of the first onetime authorization code or proof 240 based on the first session privacy key 230 and the current request counter 242 and / or the content of the first request 244 including the privacy information. The request responder 220 can compare the expected value of the first one-time authorization code or proof 240 with the actual value of the first one-time authorization code or proof 240 received in the message 246. If the two values match, the request responder 220 can proceed to perform semantic operations specified in the first request 244. If the two values fail to match each other, the request responder 220 rejects the first request by returning or transmitting a fixed error code alone as responseto the request initiator 210 without any other data. The request responder 220 can also perform both checks (e.g., whether the message 246 includes a one-time authorization proof and whether the incoming proof matches the expected value) before executing any other semantic processing of the incoming request.

[0062] After semantically processing the first request 244 in the message 246, the request responder 220 generates a message 250 including a response. The request responder 220 transmits the message 250 to the request initiator 210. At a later time, the request initiator 210 can generate a second request prior to switching contexts. The request initiator 210 can generate a second one-time authorization code or proof 240 to be sent together with the second request to the request responder 220. Since the second request is generated prior to switching contexts and prior to receiving any new random nonce from the request responder 220, the second one-time authorization code or proof 240 is generated by incrementing the value of the current request counter 242 and applying the first session privacy key 230 to the current request counter 242 optionally with content of the second request. Namely, a new one-time authorization code or proof 240 is generated each time an additional request is generated and sent by the request initiator 210 to the request responder 220 using the same first session privacy key 230 until a new random nonce is received.

[0063] In some examples, the request initiator 210 can transmit a request to select a second context. Namely, the request initiator 210 can transmit a request 260 to switch from the first context (e.g., the global context) to the second context (e.g., the local context). In response to receiving the request 260, the request responder 220 can send a response 262 indicating successful switching of the context. Optionally, the request responder 220 can generate a new random nonce 264 in response to receiving the request 260.

[0064] The request initiator 210 and the request responder 220 can access and select a second symmetric static privacy key 272 that corresponds to and is associated with the second context. The request initiator 210 and the request responder 220 generate a second session privacy key 270 based on the second symmetric static privacy key 272. The second session privacy key 270 can be further generated based on the previously exchanged first random nonce 216 if a new random nonce was not sent by the request responder 220 when the context was switched. If the request responder 220 generatedand sent the new random nonce 264 to the request initiator 210 in response to switching the context, the second session privacy key 270 can be further generated based on the new random nonce 264 instead of the previously exchanged nonce (e.g., first random nonce 216). Additionally, the request initiator 210 and the request responder 220 can generate a distinct session privacy key using the second symmetric static privacy key 272 if the configuration setting has been set to prevent leakage of the privacy information.

[0065] The request initiator 210 can generate an additional request which may or may not include privacy information (e.g., Request #2). The request initiator 210 can also access the current request counter 242 which tracks how many request messages have been sent by the request initiator 210. The request initiator 210 can generate a second one-time authorization code or proof 280 based on the second session privacy key 270 and the current request counter 242 (which has now been incremented to the integer value of two since this is the second request). The second one-time authorization code or proof 280 can further be generated based on the content of the additional request including the privacy information. The second one-time authorization code or proof 280 can be referred to as a second MAC (MAC #2).

[0066] The request initiator 210 can generate a message 282 in which the additional request is concatenated or otherwise combined with the second one-time authorization code or proof 280. The request initiator 210 transmits the message 282 to the request responder 220 in plain text (without encryption). In some cases, the request initiator 210 determines whether the configuration setting has been set to prevent leakage of the privacy information. If so, the request initiator 210 can encrypt the message 282 prior to sending the message 282 to the request responder 220 using the additional separate session privacy key that has been generated (e.g., based on the second symmetric static privacy key 272).

[0067] The request responder 220, upon receiving the message 282, can process the message 282. Namely, the request responder 220 determines whether the configuration setting has been set to prevent leakage of the privacy information. If so, the request responder 220 can decrypt the message 282 using the additional separate session privacy key that has been generated prior to verifying or checking its authenticity. If the configuration setting has not been set to prevent leakage of the privacy information, therequest responder 220 can avoid decrypting the message 282 and can, in response to receiving the message 246, verify or check its authenticity.

[0068] In some examples, the request responder 220 checks the authenticity of the message 282 using the second one-time authorization code or proof 280 included in the message 282. Specifically, the request responder 220 can first check whether the message 282 includes the second one-time authorization code or proof 280. Then, the request responder 220 can generate an expected value for the second one-time authorization code or proof 280 in response to determining that the second one-time authorization code or proof 280 is included in the message 282, as discussed above. The request responder 220 can also perform both checks (e.g., whether the message 282 includes a one-time authorization proof and whether the incoming proof matches the expected value) before executing any other semantic processing of the incoming additional request.

[0069] After verifying authenticity of the additional request based on the second onetime authorization code or proof 280, the request responder 220 generates a response 284. The response 284 is sent to the request initiator 210. The request initiator 210 and the request responder 220 then establish a secure channel (290) over which subsequence requests and responses can be exchanged. Data exchanged over the secure channel can continue to be associated with additional one-time authorization codes or proofs or can be sent without any one-time authorization codes or proofs.

[0070] FIG. 3 is a flowchart illustrating example process or method 300 or method of the access control system 100, according to some examples. The process or method 300 may be embodied in computer-readable instructions for execution by one or more processors such that the operations of the process or method 300 may be performed in part or in whole by the functional components of the system 100; accordingly, the process or method 300 is described below by way of example with reference thereto. However, in other examples, at least some of the operations of the process or method 300 may be deployed on various other hardware configurations. Some or all of the operations of process or method 300 can be in parallel, out of order, or entirely omitted.

[0071] At operation 301, the server / controller 140 (e.g., a PACS server), the access control device 110, and / or client device 120 prior to establishing a secure channelbetween a first device and a second device, establish, between the first device and the second device, a first static privacy key, as discussed above.

[0072] At operation 302, the server / controller 140 and / or the access control device 110 accesses a first random nonce that has been generated by the client device 120, as discussed above.

[0073] At operation 303, the server / controller 140 and / or the access control device 110 and / or client device 120 computes a first session key based on the first static privacy key and the first random nonce, as discussed above.

[0074] At operation 304, the controller 140 generates a first one-time authorization code based on the first session key and a current counter value, the current counter value representing a quantity of requests sent by the first device, as discussed above.

[0075] At operation 305, the server / controller 140 and / or the access control device 110 transmits, to the client device 120, a first request that is combined with the first one-time authorization code, as discussed above.

[0076] FIG. 4 is a block diagram illustrating an example software architecture 406, which may be used in conjunction with various hardware architectures herein described. FIG. 4 is a non-limiting example of a software architecture and it will be appreciated that many other architectures may be implemented to facilitate the functionality described herein. The software architecture 406 may execute on hardware such as machine 500 of FIG. 5 that includes, among other things, processors 504, memory 514, and input / output (I / O) components 518. A representative hardware layer 452 is illustrated and can represent, for example, the machine 500 of FIG. 5. The representative hardware layer 452 includes a processing unit 454 having associated executable instructions 404. Executable instructions 404 represent the executable instructions of the software architecture 406, including implementation of the methods, components, and so forth described herein. The hardware layer 452 also includes memory and / or storage devices memory / storage 456, which also have executable instructions 404. The hardware layer 452 may also comprise other hardware 458. The software architecture 406 may be deployed in any one or more of the components shown in FIG. 1.

[0077] In the example architecture of FIG. 4, the software architecture 406 may be conceptualized as a stack of layers where each layer provides particular functionality. For example, the software architecture 406 may include layers such as an operatingsystem 402, libraries 420, frameworks / middl eware 418, applications 416, and a presentation layer 414. Operationally, the applications 416 and / or other components within the layers may invoke API calls 408 through the software stack and receive messages 412 in response to the API calls 408. The layers illustrated are representative in nature and not all software architectures have all layers. For example, some mobile or special purpose operating systems may not provide a frameworks / middl eware 418, while others may provide such a layer. Other software architectures may include additional or different layers.

[0078] The operating system 402 may manage hardware resources and provide common services. The operating system 402 may include, for example, a kernel 422, services 424, and drivers 426. The kernel 422 may act as an abstraction layer between the hardware and the other software layers. For example, the kernel 422 may be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, and so on. The services 424 may provide other common services for the other software layers. The drivers 426 are responsible for controlling or interfacing with the underlying hardware. For instance, the drivers 426 include display drivers, camera drivers, BLE drivers, UWB drivers, Bluetooth® drivers, flash memory drivers, serial communication drivers (e.g., Universal Serial Bus (USB) drivers), Wi-Fi® drivers, audio drivers, power management drivers, and so forth depending on the hardware configuration.

[0079] The libraries 420 provide a common infrastructure that is used by the applications 416 and / or other components and / or layers. The libraries 420 provide functionality that allows other software components to perform tasks in an easier fashion than to interface directly with the underlying operating system 402 functionality (e.g., kernel 422, services 424 and / or drivers 426). The libraries 420 may include system libraries 444 (e.g., C standard library) that may provide functions such as memory allocation functions, string manipulation functions, mathematical functions, and the like. In addition, the libraries 420 may include API libraries 446 such as media libraries (e.g., libraries to support presentation and manipulation of various media format such as MPREG4, H.264, MP3, AAC, AMR, JPG, PNG), graphics libraries (e.g, an OpenGL framework that may be used to render two-dimensional (2D) and three-dimensional (3D) in a graphic content on a display), database libraries (e.g., SQLite that may providevarious relational database functions), web libraries (e.g., WebKit that may provide web browsing functionality), and the like. The libraries 420 may also include a wide variety of other libraries 448 to provide many other APIs to the applications 416 and other software components / devices.

[0080] The frameworks / middl eware 418 (also sometimes referred to as middleware) provide a higher-level common infrastructure that may be used by the applications 416 and / or other software components / devices. For example, the frameworks / middleware 418 may provide various graphic user interface functions, high-level resource management, high-level location services, and so forth. The frameworks / middleware 418 may provide a broad spectrum of other APIs that may be utilized by the applications 416 and / or other software components / devices, some of which may be specific to a particular operating system 402 or platform.

[0081] The applications 416 include built-in applications 438 and / or third-party applications 440. Examples of representative built-in applications 438 may include, but are not limited to, a contacts application, a browser application, a book reader application, a location application, a media application, a messaging application, and / or a game application. Third-party applications 440 may include an application developed using the ANDROID™ or IOS™ software development kit (SDK) by an entity other than the vendor of the particular platform, and may be mobile software running on a mobile operating system such as IOS™, ANDROID™, WINDOWS® Phone, or other mobile operating systems. The third-party applications 440 may invoke the API calls 408 provided by the mobile operating system (such as operating system 402) to facilitate functionality described herein.

[0082] The applications 416 may use built-in operating system functions (e.g., kernel 422, services 424, and / or drivers 426), libraries 420, and frameworks / middleware 418 to create user interfaces to interact with users of the system. Alternatively, or additionally, in some systems, interactions with a user may occur through a presentation layer, such as presentation layer 414. In these systems, the application / component "logic" can be separated from the aspects of the application / component that interact with a user.

[0083] FIG. 5 is a block diagram illustrating components of a machine 500, according to some examples, able to read instructions from a machine-readable medium (e.g., a machine-readable storage medium) and perform any one or more of the methodologiesdiscussed herein. Specifically, FIG. 5 shows a diagrammatic representation of the machine 500 in the example form of a computer system, within which instructions 510 (e.g., software, a program, an application, an applet, an app, or other executable code) for causing the machine 500 to perform any one or more of the methodologies discussed herein may be executed.

[0084] As such, the instructions 510 may be used to implement devices or components described herein. The instructions 510 transform the general, non-programmed machine 500 into a particular machine 500, such as the client device 120, access control device 110, or server / controller 140, programmed to carry out the described and illustrated functions in the manner described. In alternative examples, the machine 500 operates as a standalone device or may be coupled (e.g., networked) to other machines. In a networked deployment, the machine 500 may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine 500 may comprise, but not be limited to, a server computer, a client computer, a personal computer (PC), a tablet computer, a laptop computer, a netbook, a set-top box (STB), a personal digital assistant (PDA), an entertainment media system, a cellular telephone, a smart phone, a mobile device, a wearable device (e.g., a smart watch), a smart home device (e.g., a smart appliance), other smart devices, a web appliance, a network router, a network switch, a network bridge, or any machine capable of executing the instructions 510, sequentially or otherwise, that specify actions to be taken by machine 500. Further, while only a single machine 500 is illustrated, the term "machine" shall also be taken to include a collection of machines that individually or jointly execute the instructions 510 to perform any one or more of the methodologies discussed herein.

[0085] The machine 500 may include processors 504, memory / storage 506, and I / O components 518, which may be configured to communicate with each other such as via a bus 502. In an example, the processors 504 (e.g., a CPU, a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP), an ASIC, a radiofrequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, a processor 508 and a processor 512 that may execute the instructions 510. The term “processor” is intended to include multi-core processors504 that may comprise two or more independent processors (sometimes referred to as “cores”) that may execute instructions contemporaneously. Although FIG. 5 shows multiple processors 504, the machine 500 may include a single processor with a single core, a single processor with multiple cores (e.g., a multi-core processor), multiple processors with a single core, multiple processors with multiple cores, or any combination thereof.

[0086] The memory / storage 506 may include a memory 514, such as a main memory, or other memory storage, database, and a storage unit 516, all accessible to the processors 504 such as via the bus 502. The storage unit 516 and memory 514 store the instructions 510 embodying any one or more of the methodologies or functions described herein. The instructions 510 may also reside, completely or partially, within the memory 514, within the storage unit 516, within at least one of the processors 504 (e.g., within the processor’s cache memory), or any suitable combination thereof, during execution thereof by the machine 500. Accordingly, the memory 514, the storage unit 516, and the memory of processors 504 are examples of machine-readable media.

[0087] The I / O components 518 may include a wide variety of components to receive input, provide output, produce output, transmit information, exchange information, capture measurements, and so on. The specific I / O components 518 that are included in a particular machine 500 will depend on the type of machine. For example, portable machines such as mobile phones will likely include a touch input device or other such input mechanisms, while a headless server machine will likely not include such a touch input device. It will be appreciated that the I / O components 518 may include many other components that are not shown in FIG. 5. The I / O components 518 are grouped according to functionality merely for simplifying the following discussion and the grouping is in no way limiting. In various examples, the I / O components 518 may include output components 526 and input components 528. The output components 526 may include visual components (e.g., a display such as a plasma display panel (PDP), a LED display, a LCD, a projector, or a cathode ray tube (CRT)), acoustic components (e.g., speakers), haptic components (e.g., a vibratory motor, resistance mechanisms), other signal generators, and so forth. The input components 528 may include alphanumeric input components (e.g., a keyboard, a touch screen configured to receive alphanumeric input, a photo-optical keyboard, or other alphanumeric input components),point-based input components (e.g., a mouse, a touchpad, a trackball, a joystick, a motion sensor, or other pointing instrument), tactile input components (e.g., a physical button, a touch screen that provides location and / or force of touches or touch gestures, or other tactile input components), audio input components (e.g., a microphone), and the like.

[0088] In further examples, the I / O components 518 may include biometric components 539, motion components 534, environmental components 536, or position components538 among a wide array of other components. For example, the biometric components539 may include components to detect expressions (e.g., hand expressions, facial expressions, vocal expressions, body gestures, or eye tracking), measure biosignals (e.g., blood pressure, heart rate, body temperature, perspiration, or brain waves), identify a person (e.g., voice identification, retinal identification, facial identification, fingerprint identification, or electroencephalogram based identification), and the like. The motion components 534 may include acceleration sensor components (e.g., accelerometer), gravitation sensor components, rotation sensor components (e.g., gyroscope), and so forth. The environmental components 536 may include, for example, illumination sensor components (e.g., photometer), temperature sensor components (e.g., one or more thermometer that detect ambient temperature), humidity sensor components, pressure sensor components (e.g., barometer), acoustic sensor components (e.g., one or more microphones that detect background noise), proximity sensor components (e.g., infrared sensors that detect nearby objects), gas sensors (e.g., gas detection sensors to detection concentrations of hazardous gases for safety or to measure pollutants in the atmosphere), or other components that may provide indications, measurements, or signals corresponding to a surrounding physical environment. The position components 538 may include location sensor components (e.g., a GPS receiver component), altitude sensor components (e.g., altimeters or barometers that detect air pressure from which altitude may be derived), orientation sensor components (e.g., magnetometers), and the like.

[0089] Communication may be implemented using a wide variety of technologies. The I / O components 518 may include communication components 540 operable to couple the machine 500 to a network 537 or devices 529 via coupling 524 and coupling 522, respectively. For example, the communication components 540 may include a network interface component or other suitable device to interface with the network 537. In furtherexamples, communication components 540 may include wired communication components, wireless communication components, cellular communication components, NFC components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components to provide communication via other modalities. The devices 529 may be another machine or any of a wide variety of peripheral devices (e.g., a peripheral device coupled via a USB).

[0090] Moreover, the communication components 540 may detect identifiers or include components operable to detect identifiers. For example, the communication components 540 may include RFID tag reader components, NFC smart tag detection components, optical reader components (e.g., an optical sensor to detect one-dimensional bar codes such as Universal Product Code (UPC) bar code, multi-dimensional bar codes such as Quick Response (QR) code, Aztec code, Data Matrix, Dataglyph, MaxiCode, PDF417, Ultra Code, UCC RSS-2D bar code, and other optical codes), or acoustic detection components (e.g., microphones to identify tagged audio signals). In addition, a variety of information may be derived via the communication components 540, such as location via IP geo-location, location via Wi-Fi® signal triangulation, location via detecting a NFC beacon signal that may indicate a particular location, and so forth.Glossary:

[0091] " CARRIER SIGNAL" in this context refers to any intangible medium that is capable of storing, encoding, or carrying transitory or non-transitory instructions for execution by the machine, and includes digital or analog communications signals or other intangible medium to facilitate communication of such instructions. Instructions may be transmitted or received over the network using a transitory or non-transitory transmission medium via a network interface device and using any one of a number of well-known transfer protocols.

[0092] " CLIENT DEVICE" in this context refers to any machine that interfaces to a communications network to obtain resources from one or more server systems or other client devices or that communicates directly with such other devices or server systems. A client device may be, but is not limited to, a mobile phone, desktop computer, laptop, PDA, smart phone, tablet, ultrabook, netbook, laptop, multi-processor system,microprocessor-based or programmable consumer electronics, game console, STB, or any other communication device that a user may use to access a network.

[0093] "COMMUNICATIONS NETWORK" in this context refers to one or more portions of a network that may be an ad hoc network, an intranet, an extranet, a VPN, a LAN, a BLE network, a UWB network, a WLAN, a WAN, a WWAN, a MAN, the Internet, a portion of the Internet, a portion of the PSTN, a POTS network, a cellular telephone network, a wireless network, a Wi-Fi® network, another type of network, or a combination of two or more such networks. For example, a network or a portion of a network may include a wireless or cellular network and the coupling may be a CDMA connection, a GSM connection, or other type of cellular or wireless coupling. In this example, the coupling may implement any of a variety of types of data transfer technology, such as IxRTT, EVDO technology, GPRS technology, EDGE technology, 3 GPP including 3G, 4G networks, UMTS, HSPA, WiMAX, LTE standard, others defined by various standard setting organizations, other long range protocols, or other data transfer technology.

[0094] "MACHINE -RE AD ABLE MEDIUM" in this context refers to a component, device, or other tangible media able to store instructions and data temporarily or permanently and may include, but is not limited to, RAM, ROM, buffer memory, flash memory, optical media, magnetic media, cache memory, other types of storage (e.g., Erasable Programmable Read-Only Memory (EEPROM)) and / or any suitable combination thereof. The term "machine-readable medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) able to store instructions. The term "machine-readable medium" shall also be taken to include any medium, or combination of multiple media, that is capable of storing instructions (e.g., code) for execution by a machine, such that the instructions, when executed by one or more processors of the machine, cause the machine to perform any one or more of the methodologies described herein. Accordingly, a "machine-readable medium" refers to a single storage apparatus or device, as well as "cloud-based" storage systems or storage networks that include multiple storage apparatus or devices. The term "machine-readable medium" excludes signals per se.

[0095] " COMPONENT" in this context refers to a device, physical entity, or logic having boundaries defined by function or subroutine calls, branch points, APIs, or other technologies that provide for the partitioning or modularization of particular processing or control functions. Components may be combined via their interfaces with other components to carry out a machine process. A component may be a packaged functional hardware unit designed for use with other components and a part of a program that usually performs a particular function of related functions. Components may constitute either software components (e.g., code embodied on a machine-readable medium) or hardware components. A "hardware component" is a tangible unit capable of performing certain operations and may be configured or arranged in a certain physical manner. In various examples, one or more computer systems (e.g., a standalone computer system, a client computer system, or a server computer system) or one or more hardware components of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) as a hardware component that operates to perform certain operations as described herein.

[0096] A hardware component may also be implemented mechanically, electronically, or any suitable combination thereof. For example, a hardware component may include dedicated circuitry or logic that is permanently configured to perform certain operations. A hardware component may be a special-purpose processor, such as a FPGA or an ASIC. A hardware component may also include programmable logic or circuitry that is temporarily configured by software to perform certain operations. For example, a hardware component may include software executed by a general-purpose processor or other programmable processor. Once configured by such software, hardware components become specific machines (or specific components of a machine) uniquely tailored to perform the configured functions and are no longer general-purpose processors. It will be appreciated that the decision to implement a hardware component mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations. Accordingly, the phrase "hardware component"(or "hardware-implemented component") should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a certain manner or to perform certain operations described herein. Considering examples in which hardware components are temporarily configured(e.g., programmed), each of the hardware components need not be configured or instantiated at any one instance in time. For example, where a hardware component comprises a general-purpose processor configured by software to become a specialpurpose processor, the general-purpose processor may be configured as respectively different special-purpose processors (e.g., comprising different hardware components) at different times. Software accordingly configures a particular processor or processors, for example, to constitute a particular hardware component at one instance of time and to constitute a different hardware component at a different instance of time.

[0097] Hardware components can provide information to, and receive information from, other hardware components. Accordingly, the described hardware components may be regarded as being communicatively coupled. Where multiple hardware components exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses) between or among two or more of the hardware components. In examples in which multiple hardware components are configured or instantiated at different times, communications between such hardware components may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple hardware components have access. For example, one hardware component may perform an operation and store the output of that operation in a memory device to which it is communicatively coupled. A further hardware component may then, at a later time, access the memory device to retrieve and process the stored output.

[0098] Hardware components may also initiate communications with input or output devices and can operate on a resource (e.g., a collection of information). The various operations of example methods described herein may be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented components that operate to perform one or more operations or functions described herein. As used herein, "processor-implemented component" refers to a hardware component implemented using one or more processors. Similarly, the methods described herein may be at least partially processor-implemented, with a particular processor or processors being an example of hardware. For example, at least some of the operationsof a method may be performed by one or more processors or processor-implemented components. Moreover, the one or more processors may also operate to support performance of the relevant operations in a "cloud computing" environment or as a "software as a service" (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), with these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., an API). The performance of certain of the operations may be distributed among the processors, not only residing within a single machine, but deployed across a number of machines. In some examples, the processors or processor- implemented components may be located in a single geographic location (e.g., within a home environment, an office environment, or a server farm). In other examples, the processors or processor-implemented components may be distributed across a number of geographic locations.

[0099] " PROCESSOR" in this context refers to any circuit or virtual circuit (a physical circuit emulated by logic executing on an actual processor) that manipulates data values according to control signals (e.g., "commands," "op codes," "machine code," etc.) and which produces corresponding output signals that are applied to operate a machine. A processor may, for example, be a CPU, a RISC processor, a CISC processor, a GPU, a DSP, an ASIC, a RFIC, or any combination thereof. A processor may further be a multicore processor having two or more independent processors (sometimes referred to as "cores") that may execute instructions contemporaneously.

[0100] Changes and modifications may be made to the disclosed examples without departing from the scope of the present disclosure. These and other changes or modifications are intended to be included within the scope of the present disclosure, as expressed in the following claims.

[0101] The Abstract of the Disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in a single example for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed examples require more features than are expressly recited in each claim. Rather, as thefollowing claims reflect, inventive subject matter may lie in less than all features of a single disclosed example. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate example.

Claims

WHAT IS CLAIMED IS:

1. A method comprising: prior to establishing a secure channel between a first device and a second device, establishing, between the first device and the second device, a first static privacy key; accessing, by the first device, a first random nonce that has been generated by the second device; computing, by the first and second devices, a first session key based on the first static privacy key and the first random nonce; generating, by the first device, a first one-time authorization code based on the first session key and a current counter value, the current counter value representing a quantity of requests sent by the first device; and transmitting, by the first device to the second device, a first request that is combined with the first one-time authorization code.

2. The method of claim 1, further comprising: computing, by the second device, an expected value for the first one-time authorization code based on the current counter value and the first request; determining that the expected value for the first one-time authorization code matches the first one-time authorization code; and in response to determining that the expected value for the first one-time authorization code matches the first one-time authorization code, establishing the secure channel between the first device and the second device.

3. The method of claim 1, further comprising: determining that a configuration setting has been set to prevent leakage of privacysensitive information via passive eavesdropping; and in response to determining that the configuration setting has been set to prevent leakage of privacy-sensitive information via passive eavesdropping, encrypting the first request that is transmitted to the second device using at least one of the first session key or the first static privacy key.

4. The method of claim 1, further comprising: transmitting, by the first device to the second device, a request to select a first context; and generating the first random nonce in response to the second device receiving the request to select the first context, the first random nonce being transmitted by the second device in response to successfully selecting the first context.

5. The method of claim 1, further comprising: determining that a current context on the second device is a first context; receiving, from the first device, a request to switch the current context from the first context to a second context; and generating the first random nonce in response receiving, from the first device, the request to switch the current context from the first context to the second context.

6. The method of claim 5, wherein the first context is at least one of a global context or a local context, and wherein the second context is at least a different one of the global context or the local context.

7. The method of claim 1, wherein the first request includes privacy-sensitive information.

8. The method of claim 7, wherein the privacy-sensitive information comprises at least one of an authentication object reference for an authentication request or a file reference identifier for a file access request.

9. The method of claim 1, further comprising: establishing, between the first device and the second device, a second static privacy key, the first static privacy key being associated with a first context and the second static privacy key being associated with a second context; determining whether a current context corresponds to the first context or the second context; andcomputing the first session key based on either the first static privacy key or the second static privacy key in response to determining whether the current context corresponds to the first context or the second context.

10. The method of claim 9, further comprising: determining that the current context corresponds to the first context; determining whether a new random nonce has been generated; and computing the first session key based on the first static privacy key and based on either the first random nonce or the new random nonce in response to determining that the current context corresponds to the first context.

11. The method of claim 10, further comprising: receiving, by the second device, a request to switch the current context from the second context to the first context; in response to receiving the request to switch the current context from the second context to the first context, generating the new random nonce; and using the new random nonce to compute the first session key.

12. The method of claim 10, further comprising: receiving, by the second device, a request to switch the current context from the second context to the first context; in response to receiving the request to switch the current context from the second context to the first context, determining that a new random nonce has not been generated; and using the first random nonce corresponding to a latest random nonce to compute the first session key.

13. The method of claim 9, further comprising: transmitting, by the first device, an additional request to switch the current context; in response to transmitting the additional request to switch the current context, receiving a second random nonce from the second device; and computing, by the first and second devices, a second session key based on the second static privacy key and the second random nonce in response to determining that the current context corresponds to the second context.

14. The method of claim 13, further comprising: updating the current counter value by incrementing the current counter value in response to generating a second request; generating, by the first device, a second one-time authorization code based on the second session key and the updated current counter value; and transmitting, by the first device to the second device, a second request that is combined with the second one-time authorization code.

15. The method of claim 1, further comprising: computing, by the second device, an expected value for the first one-time authorization code based on the current counter value and the first request; determining that the expected value for the first one-time authorization code fails to match the first one-time authorization code; and in response to determining that the expected value for the first one-time authorization code fails to match the first one-time authorization code, returning a fixed error code to the first device as response without any other data.

16. The method of claim 15, further comprising: determining whether the expected value for the first one-time authorization code matches the first one-time authorization code prior to executing any other semantic processing of the first request.

17. The method of claim 1, wherein the first request is transmitted in plain text along with the first one-time authorization code.

18. The method of claim 1, wherein the first session key is computed by encrypting the first random nonce with the first static privacy key.

19. A system comprising: one or more processors coupled to a memory comprising non-transitory computer instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising:prior to establishing a secure channel between a first device and a second device, establishing, between the first device and the second device, a first static privacy key; accessing, by the first device, a first random nonce that has been generated by the second device; computing, by the first and second devices, a first session key based on the first static privacy key and the first random nonce; generating, by the first device, a first one-time authorization code based on the first session key and a current counter value, the current counter value representing a quantity of requests sent by the first device; and transmitting, by the first device to the second device, a first request that is combined with the first one-time authorization code.

20. A non-transitory computer readable medium comprising non-transitory computer- readable instructions that, when executed by one or more processors, configure the one or more processors to perform operations comprising: prior to establishing a secure channel between a first device and a second device, establishing, between the first device and the second device, a first static privacy key; accessing, by the first device, a first random nonce that has been generated by the second device; computing, by the first and second devices, a first session key based on the first static privacy key and the first random nonce; generating, by the first device, a first one-time authorization code based on the first session key and a current counter value, the current counter value representing a quantity of requests sent by the first device; and transmitting, by the first device to the second device, a first request that is combined with the first one-time authorization code.

Images