System for and method of authenticating and permitting device

Abstract

To provide a system for and a method of authenticating and permitting a device and / or distributing a key.SOLUTION: In a system 100, a device 110, an SCM 120, a device component 140 and a cloud 130 or a user or an electronic system component as combination of them operate as an arbitrary one or more of those devices are used for achieving one or more of operations of authenticating electronic system components, safely transferring a message between the electronic system components, establishing a safe communication channel through a restricted link, authenticating a message content, approving an action, and distributing authentication and setting data between the electronic system components of the user in a device as a key system.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present application relates to systems and methods for authenticating and authorizing devices and / or distributing keys. [Background technology]

[0002] There have been many efforts to enable smartphones to be used as keys to direct access and operation of equipment devices such as doors and vehicles. However, these conventional systems rely on what is considered a simple form of security that relies on an equipment device with network access to authenticate whether the smartphone has the authority to direct the operation of the equipment device. Such conventional equipment devices cannot authenticate and / or authorize at least one of a key, a device, and a user when an authorization device has not previously communicated with the equipment device to identify the authority of the key, the device, or the user. In other words, if there is no communication link between the authorization device and the equipment device, i.e., if there is a lack of connectivity, the equipment device of this conventional system cannot determine whether a smartphone attempting to communicate with the equipment device is authorized by the authorization device.

[0003] In traditional key fob systems utilized by vehicle manufacturers, authentication information for the key and / or key fob is delivered to an authorization device before the key fob is authenticated and / or authorized, and the authorization device can send the authorization information to an equipment device.

[0004] Similar conventional systems may not be able to authenticate and / or authorize a key, device, or user while the communication link is not present, for example, because the system may rely on an equipment device being able to communicate with a cloud system (or other system components that are unreachable due to lack of connectivity) during the authentication and / or authorization process. This scenario (lack of connectivity) may not seem common. However, it is actually quite common if you think of a car parked in a parking lot, in a remote area, or at a cottage in the woods, without a cellular connection. Lack of connectivity in such a situation may prevent the ability to grant a smartphone or other device permission to operate the car or access the cottage. Summary of the Invention

[0005] The present disclosure relates primarily to systems and methods for a distributed security model that may be used to accomplish one or more of authenticating system components, securely transferring messages between system components, establishing secure communication channels over constrained links, authenticating message content, authorizing actions, and distributing authorization and configuration data among user system components in a Device-as-a-Key system.

[0006] A system according to one embodiment can facilitate authentication using potentially unique identifiers for one or more of portable devices, cloud or network servers or systems, hardware, modifications and revocations.

[0007] In one embodiment, the system may allow for the transfer of information between system components in a secure and private manner. In one embodiment, there may be end-to-end encryption provided across all communication links. The system may form a distributed system where some data may be sent over unencrypted channels, but the data itself is fully encrypted.

[0008] In one embodiment, the system can provide authorization based on a) one or more chains of signatures by authenticated entities, b) potentially independent clouds, and c) potentially a separation between roots of trust and roots of authentication. Authorization can be differentiated between owners and guests and provide transfer of ownership.

[0009] A system according to one embodiment can facilitate authorization and distribution of one or more associated features including new key generation, identification of changed keys, blacklisting / revocation notification, key rotation, ownership transfer, reset, root of trust configuration, keys, and other data.

[0010] A system according to one embodiment may provide one or more security checks including, for example, configuration ordering, time deltas, and jailbreak detection.

[0011] In one embodiment, the system may provide a key attribute authorization model where each authorization has one or more attributes that are deemed necessary to identify the authorization as active. Examples of such one or more attributes include time, number of uses, location, and custom attributes.

[0012] The system of one embodiment lends itself to a sharing model where authorizations are provided and granted per device, per device+account, and / or per account (eg, even at an organizational level).

[0013] In one embodiment, the system can provide time synchronization at a trusted device level and / or at a cloud level.

[0014] A system according to one embodiment may enable authentication and authorization between devices without a working Internet connection, even at first glance.

[0015] The system may provide a mobile software trusted execution environment, a hardware TEE, or a secure element (secure storage) to facilitate secure operation.

[0016] In one embodiment, a system for communicating commands from a first device to a second device is provided. The first device can be configured to wirelessly communicate with a network server in an online mode and to obtain authorization setting information from the network server. The authorization setting information relates to authorization for the first device to issue commands to the second device, and the authorization setting information can include data encrypted by a first key associated with the second device.

[0017] The second device may be to an equipment component and may be configured to instruct the equipment control to execute a command.

[0018] The second device can be configured to wirelessly communicate with the first device in an offline mode in which neither the first device nor the second device can effectively communicate with a network server, the first device and the second device are configured to establish a communication link for exchanging communications, and prior to establishing the communication link, the second device has not received information indicating that the first device has obtained authorization setting information relating to authorization for the first device to issue commands to the second device.

[0019] The first device can communicate authorization setting information to the second device over the communication link. The first device can also communicate command information regarding a request to execute a command over the communication link. The second device can authenticate the identity of the first device based on the authorization setting information and determine the authority of the first device to issue a command to the second device.

[0020] In one embodiment, a control unit for controlling operation of an equipment component includes a communication interface, a memory, an equipment interface, and a controller. The communication interface is operable to wirelessly communicate with a remote device, and the memory may be configured to store one or more cryptographic keys related to authentication and authorization of the remote device. The equipment interface may be operable to direct operation of the equipment control in response to commands received from the remote device.

[0021] The controller of the control unit may be configured to establish a communication link with the remote device via the communication interface and to receive authorization setting information from the remote device, the authorization setting information including encrypted authorization data, from which only the controller can decrypt the authorization data.

[0022] Based at least in part on the authorization data, the controller can authenticate the identity of the remote device and determine the authority of the remote device to issue commands to the remote device.

[0023] According to one embodiment, a method of communication between a first device and a second device is provided. The method can include obtaining authorization setting information from a network server at the first device, the authorization setting information including data encrypted by a first key associated with the second device. The method can include establishing a communication link for exchanging communications between the first device and the second device, where the second device has not received information indicating that the first device has obtained the authorization setting information prior to establishing the communication link.

[0024] The method may include receiving, at the second device, authorization setting information; and decrypting, at the second device, the authorization setting information to obtain a device key and authorization data related to one or more authorizations for the first device to direct operation of the second device.

[0025] The second device can authenticate the identity of the first device based on a device key derived from the authorization configuration information and receive commands from the first device.

[0026] The method may include determining whether the first device is authorized to issue the command, and in response to the first device determining that it is authorized to issue the command, instructing the equipment component to execute the command.

[0027] In one embodiment, a system is provided that differs from traditional key distribution systems that rely on a centralized cloud and connectivity to the cloud. For example, in one embodiment of the present disclosure, a key may be sent to a device and verified by an authorizer (e.g., a lock).

[0028] In one embodiment, a security model can be provided in which there are no high-value targets and no components can be compromised without knowledge (no single component holes that compromise the security of the system).

[0029] Before the embodiments of the invention are described in detail, it should be understood that the invention is not limited to the details of operation or the details of construction and arrangement of components set forth in the following description or illustrated in the drawings. The invention can be embodied in various other embodiments and can be practiced or carried out in other ways not expressly disclosed herein. It should also be understood that the phraseology and terminology used herein are for purposes of description and should not be regarded as limiting. The use of "including" and "comprising" and variations thereof means to encompass the items listed thereafter and their equivalents, as well as additional items and their equivalents. Furthermore, enumeration may be used in the description of various embodiments. Unless otherwise stated, the use of enumeration should not be construed as limiting the invention to a certain order or number of components. Nor should the use of enumeration be construed as excluding from the scope of the invention any additional steps or components that can be combined with or within the listed steps or components. [Brief description of the drawings]

[0030] [Figure 1] FIG. 1 is a representation of a system according to one embodiment.

[0031] [Diagram 2] FIG. 2 is a representative diagram of system components in one embodiment.

[0032] [Diagram 3] FIG. 3 illustrates a microlocation system according to one embodiment.

[0033] [Figure 4] FIG. 4 illustrates an ACP container according to one embodiment.

[0034] [Diagram 5]FIG. 5 illustrates an ACP container and an ACP container version package according to one embodiment.

[0035] [Figure 6] FIG. 6 illustrates a trust and authorization tree according to one embodiment.

[0036] [Figure 7] FIG. 7 illustrates another trust and authorization tree according to one embodiment.

[0037] [Figure 8] FIG. 8 illustrates a method for issuing authorization for SCM according to one embodiment.

[0038] [Figure 9] FIG. 9 illustrates a method for registering a device according to one embodiment.

[0039] [Figure 10] FIG. 10 illustrates a method for creating a user account according to one embodiment.

[0040] [Figure 11] 11A-B are representative diagrams of data distribution according to one embodiment.

[0041] [Figure 12] FIG. 12 is a method for rotating keys according to one embodiment.

[0042] [Figure 13] FIG. 13 illustrates a method for establishing a microlocation connection according to one embodiment.

[0043] [Figure 14] FIG. 14 illustrates a method for establishing a secure and reliable communication link according to one embodiment.

[0044] [Figure 15]FIG. 15 illustrates a block fan distribution scheme for granting rights, according to one embodiment.

[0045] [Figure 16] FIG. 16 shows a representative diagram of data distribution according to one embodiment.

[0046] [Figure 17] FIG. 17 shows a representative diagram of a system according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0047] The present disclosure relates to systems and methods for a distributed security model that may be used to accomplish one or more of authenticating system components, securely transferring messages between system components, establishing secure communication channels over constrained links, authenticating message content, authorizing actions, and distributing authorization and configuration data among user system components in a device-as-a-key system. One or more portions of the system may be implemented with one or more portions of the microlocation system described in U.S. patent application Ser. No. 14 / 620,959, filed Feb. 12, 2015 and issued as U.S. Patent No. 9,666,005, entitled "SYSTEM AND METHOD FOR COMMUNICATING WITH A VEHICLE," to J. Michael Ellis et al., and U.S. patent application Ser. No. 15 / 488,136, filed Apr. 14, 2017 and issued as U.S. Patent No. 9,794,753, entitled "SYSTEM AND METHOD FOR ESTABLISHING A REAL-TIME LOCATION," to Raymond Michael Stitt. The disclosures of these disclosures are incorporated herein in their entireties, and the hardware may be a monitor or master device, resulting in authentication verification, authorization verification, and location-verified portable device interactions with other systems using end-to-end encryption (secure, trusted, private). I. System Architecture

[0048] A system according to one embodiment is shown in Figures 1 and 17 and is generally designated 100. System 100 may be comprised of the following system components: a) one or more users 10 (e.g., people); b) one or more devices 110, such as portable devices (e.g., smart phones, cards or fobs, or a combination thereof) and / or stationary devices (e.g., computers / servers, wall-mounted panels / displays, or a combination thereof); c) one or more system control modules (SCMs) 120, also described as hardware; d) a cloud 130 (e.g., a collection of clouds), which may include one or more back-end servers or a collection of computers from one or more vendors; and e) one or more equipment components 140, which may be configured to control the operation of equipment, initiate services, relay information to or retrieve information from another portion of system 100, or a combination thereof. In the illustrated embodiment, cloud 130 and / or equipment 140 are optional.

[0049] The system 100 can enable one or more users 10 to interact with or access equipment 140 using a device 110. The device 110 can communicate with equipment 140 (such as a vehicle, lock, or table) by communicating with the SCM 120. The SCM 120 of an embodiment can authenticate the device 110, provide or receive configuration data, authorize actions (e.g., connect, or send and / or receive requests, commands, updates, or responses, or combinations thereof), or communicate with equipment components to accomplish a desired action, or combinations thereof. The device 110 can communicate with the cloud 130 to obtain, modify, or distribute authorizations and other configuration data (as described herein) between the associated device and user, or combinations thereof. There are other system interactions that are less relevant to the security model, but for purposes of disclosure are not shown or described in further detail. For example, there are factory tools that communicate with the SCM 120 and the cloud 130 that can interact with other system clouds. A. Overview of Communications and Interactions

[0050] 1 may be wireless or wired, or both. One system component, such as device 110, may be local or remote to another system component, such as SCM 120. System 100 may include any number of each system component, including embodiments where the number is zero, such as when there are no clouds and / or appliances.

[0051] In one embodiment, the roles of the system components of the system 100 are not necessarily fixed as one type of component. For example, a system component may dynamically change roles during operation, or a system component may assume the role of more than one component of the system 100. For example, the SCM 120 may be an instrument component 140 for another SCM 120. In a more specific form of this example, the SCM 120 may be an instrument component 140 that communicates with other SCMs 120. It should be understood that one or more of these system components may not be present, but for purposes of disclosure, the remaining discussion focuses on the system 100 in which one or more instrument components 140 and the cloud 130 are present. B. Component Overview

[0052] The system 100 in the illustrated embodiment may include one or more system components as outlined herein. The system components may be users or electronic system components, which may be the device 110, the SCM 120, the equipment component 140, and the cloud 130, or a combination thereof. As discussed herein, the electronic system components may be configured to operate as any one or more of those devices. In this sense, in one embodiment, there may be some aspects or features that are common among the device 110, the SCM 120, the equipment component 140, and the cloud 130. For purposes of disclosure, these features are described with reference to the electronic components shown in FIG. 2 and generally designated 200.

[0053] The electronic system component 200 (e.g., all system components except the user) may include, among other electronic hardware, one or more processors 210 that execute one or more applications 232 (including software and / or firmware), one or more memory units 212 (e.g., RAM and / or ROM), and one or more communication units 214. The electronic system component 200 may or may not have an operating system 230 that controls access to lower level devices / electronics via the communication units 214. The electronic system component 200 may or may not have a hardware-based encryption unit 222, and if not present, the encryption functions may be performed in software. The electronic system component 200 may or may not have (or may or may not have access to) a secure memory unit 220 (e.g., a secure element or hardware security module (HSM)). Optional components and communication paths are shown in phantom in the illustrated embodiment.

[0054] The illustrated embodiment of system 100 does not rely on the presence of secure memory unit 220 in any component. In the optional absence of secure memory unit 220, data stored in secure memory unit 220 (e.g., private and / or secret keys) may be encrypted at rest (when possible). Both software-based and hardware-based countermeasures may be utilized to substantially prevent access to such data, as well as to substantially prevent and / or detect the onset of a security breach of the overall system components. Examples of such countermeasures include implementing physical barriers or shields, disabling JTAG and other ports, hardening software interfaces to eliminate attack vectors, using a trusted execution environment (hardware and / or software), detecting operating system root access or onset of a security breach, etc.

[0055] For purposes of this disclosure, secure is generally considered to be private (encrypted), authenticated, and integrity verified, however, it should be understood that this disclosure is not so limited and that the term "secure" may be a subset of these aspects or may include additional aspects related to data security.

[0056] The communication interface 214 can be any type of communication link, including any of the types of communication links described herein, including wired or wireless. The communication interface 214 can facilitate external or internal communication, or both. For example, the communication interface 214 can provide a wireless communication link with another system electronic device 200 in the form of the device 110, such as wireless communication via the Bluetooth® low energy standard or the cloud 130 via a Wi-Fi Ethernet® communication link. In another example, the communication interface 214 can be configured to communicate with an equipment component 140 (e.g., a vehicle component) via a wired link, such as a CAN-based wired network that facilitates communication between multiple devices. The communication interface 214 of one embodiment can include a display and / or input interface for communicating information to and / or receiving information from the user 10.

[0057] 2, the electronic system component 200 may be configured to communicate with one or more auxiliary devices 300 other than another electronic system component 200 or a user. The auxiliary device 300 may be configured differently than the electronic system component 200, for example, the auxiliary device 300 may not include a processor 210, but instead may include at least one direct connection and / or communication interface for sending and / or receiving information with the electronic system component 200. For example, the auxiliary device 300 may be a solenoid that accepts input from the electronic system component 200, or the auxiliary device 300 may be a sensor (e.g., a proximity sensor) that provides analog and / or digital feedback to the electronic system component 200. C. Microlocation

[0058] The system 100 of the illustrated embodiment may be configured to determine location information in real time with respect to the device 110. In the illustrated embodiment of FIG. 1, a user 10 may carry the device 110 (e.g., a smartphone). The system 100 may facilitate locating the device 110 relative to an equipment 140 (e.g., a vehicle) in real time with sufficient accuracy to determine whether the user is located in a location where permission for equipment access or equipment commands should be granted.

[0059] For example, in the vehicle field where the equipment 140 is a vehicle, the system 100 can facilitate a determination of whether the device 110 is outside the vehicle but in close proximity, for example, within 5 feet, 3 feet, or 2 feet or less to the driver's door. This determination can form the basis for the system 100 to identify whether the vehicle should be unlocked. On the other hand, if the system 100 determines that the device 110 is outside the vehicle and not in close proximity to the driver's door (e.g., outside of 2 feet, 3 feet, or 5 feet), the system 100 can decide to lock the driver's door. As another example, if the system 100 determines that the device 110 is in close proximity to the driver's seat but not near the passenger seat or the rear seat, the system 100 can decide to allow the vehicle to start. Conversely, if the device 110 is determined to be outside the proximity range of the driver's seat, the system 100 can decide to immobilize or keep the vehicle immobilized.

[0060] The vehicle in this context may also include other types of equipment 140, such as one or more sensors similar to the remote device 310 described in connection with the illustrated embodiment of FIG. 3 and shown in FIGS. 16 and 17 along with the sensor and sensor hub configuration. The equipment 140 forming the sensor and sensor hub configuration of FIG. 16 may include one or more keys as described herein to facilitate authentication of information received from the sensors and sensor hubs. It should be noted that one or more keys may be incorporated into the system 100 for use with the sensors or remote device 310 and / or sensor hubs. One or more additional keys similar in structure to the equipment devices or other components of the system 100 may be present in the SCM 120 and sensors / sensor hubs in the sensor network. Additionally or alternatively, one or more of these keys and / or one or more other keys of the system 100 may be used to identify the authenticity of the sensor / sensor hub in the sensor network and authorize its participation.

[0061] The microlocation of the equipment 140 can be determined in a variety of ways, such as using information obtained from a global positioning system, one or more signal characteristics of the communication from the device 110, and one or more sensors (e.g., a proximity sensor, a limit switch, or a visual sensor), or a combination thereof. One example of a microlocation technology that can comprise the system 100 is described in U.S. Patent Application No. 15 / 488,136, filed April 14, 2017, entitled "System and Method for Establishing Real-Time Location," to Raymond Michael Stitt et al., the disclosure of which is incorporated herein by reference in its entirety. More particularly, in one example depicted in the illustrated embodiment of FIG. 3, the SCM 120 and multiple remote devices 310 (similar in some respects to the device 110) can be located in fixed locations relative to the equipment component 140. Exemplary use cases for the equipment component 140 include the vehicles identified in the previous examples, or buildings to which access is controlled by the equipment component 140.

[0062] The device 110 may communicate wirelessly (e.g., via Bluetooth low energy) with the SCM 120 via a communication link. The multiple remote devices 310 may be configured to eavesdrop on the communication between the device 110 and the SCM 120 to determine one or more signal characteristics of the communication, such as signal strength. The determined signal characteristics may be communicated, or analyzed and then communicated, to the SCM 120 via a communication link separate from the communication link between the device 110 and the SCM 120. Additionally or alternatively, the device 110 may establish a direct communication link with one or more remote devices 310, and the one or more signal characteristics may be determined based on the direct communication link.

[0063] As an example, as shown in the illustrated embodiment, the propagating waves of a communication from device 110 to SCM 120 are shown and designated 302, 304, 306. The greater the distance from device 110 (the source), the less the strength of the wireless communication. The strength of the communication on propagating wave 306 is less than the strength of propagating wave 302. Furthermore, if a communication is transmitted at time T0, the travel time (TP1-T0) for the communication on propagating wave 302 is less than the travel time (TP3-T0) for the communication on propagating wave 306. As a result, when remote device 320 receives the communication on propagating wave 302, the timestamp of arrival of the communication will be earlier than if the communication was received on propagating wave 306. One or more signal characteristics, such as signal strength and time of arrival, may be analyzed to determine location information for device 110 relative to SCM 120. For example, the time difference of arrival between remote device 310 and SCM 120 may be processed to determine the relative location of device 110. The position of one or more remote devices 310 relative to the SCM 120 may be known such that the relative position of the device 110 can be converted to an absolute position relative to the remote device 310 and the SCM 120. Additional or alternative examples of signal characteristics may be obtained to facilitate determining a position according to one or more algorithms including a distance function, a trilateration function, a triangulation function, a multilateration function, a fingerprint function, a differential function, a time of flight function, a time of arrival function, a time difference of arrival function, an angle of arrival function, an angle of departure function, a geometric function, or the like, or any combination thereof.

[0064] For purposes of illustration, the propagating waves 302, 304, 306 are depicted as uniformly circular, however, it should be noted that the propagating waves may change shape depending on other factors such as interference or the use of directional antennas.

[0065] In one embodiment, information regarding communications between device 110 and SCM 120 may be provided to multiple remote devices 320. For example, connection parameters regarding a Bluetooth Low Energy channel may be provided to multiple remote devices 320 so that the multiple remote devices 320 can monitor the communications. For example, the communication channel may change one or more parameters during a communication, such as the frequency of transmission, for each packet or among the bits transmitted within a packet. These one or more variable parameters may be communicated to the remote devices 320 to enable reception of the packets or communications.

[0066] The system 100 can utilize a security model as described herein to facilitate one or more of authenticating system components, securely transferring messages between system components, establishing secure communication channels over constrained links, authenticating message content, authorizing actions, and distributing authorization and configuration data among user system components in a device-as-a-key system. II. Approval

[0067] As described herein, the system 100 can associate one or more rights with the device 110, facilitating authorization to utilize one or more rights within the system. As discussed herein, an authorization is an access right or a general right that allows a device 110 (acting on behalf of a particular user 10) to interact with an SCM 120 (acting on behalf of a particular piece of equipment) within one or more constraints (also described as access attributes), which may be specific to the SCM 120 and / or the device 110.

[0068] In one embodiment, a key (either a credential or a virtual / electronic / mobile key) is delivered to the device 110 and the key is passed to the SCM 120 at the time of use for validation (or some variation thereof).

[0069] In the illustrated embodiment of the system 100, the device 110 itself (its identity) is the key, and the SCM 120 can authorize the desired actions of the device 110 based on one or more authorizations that the SCM 120 can set for the device 110. The "identity" of the device 110 may be (or may be based on) one or more cryptographic identities or any other identifiers unique to the device 110, or a composite and / or any combination thereof. Examples of cryptographic identifiers include a unique public / private key, such as a key pair generated with asymmetric cryptography, a shared secret key, such as a key generated with symmetric cryptography. Examples of other identifiers unique to the device 110 include a hardware serial number, a hardware security module (HSM), and one or more application instance identifiers. Examples of combinations of one or more cryptographic identities and / or one or more other identifiers of the device 110 include multiple cryptographic identities and cryptographic and non-cryptographic identities.

[0070] A device 110 may have zero or more authorizations at any given time, including multiple authorizations to the same SCM 120 or different authorizations to different SCMs 120. Authorization is a useful part of the security model described herein because it provides information that can facilitate one or more of: allowing a device 110 to communicate with an SCM 120; mutually authenticating multiple devices 110 and multiple SCMs 120; and specifying conditions under which a device 110 may interact with an SCM 120. In addition to useful information for authentication, authorization can define access attributes for each device 110 to an SCM 120. Access attributes according to one embodiment can include one or more of the following: 1) Type (e.g., Owner, Guest, Valet, etc.) - Standard. Various authorization types result in different authorization distribution / sharing privileges (e.g., an Owner can make another device an Owner, but not a Guest, etc.). There may be commands or other system-level functionality that can only be accessed by users with Owner (or other types of) privileges. See Authorization Types Section VII for additional information. 2) Valid timestamp range start - Standard. 3) Valid Timestamp Range End - Optional. If present, the authorization may be automatically revoked at a certain date / time. 4) Valid Schedule - optional. If present, the authorization can only be used per a defined schedule (e.g., a recurring weekly schedule that specifies when it is available each day of the week, a monthly schedule, or a custom schedule). 5) Valid Use Count - Optional. If present, the authorization can only be used up to a set number of times (e.g., number of commands, number of days / times it has been used). 6) Additional Authentication Types and Identifiers - Optional. If present, authorization may utilize additional (active or passive) authentication beyond what the system already provides (e.g. device unlock / login / button press / passcode entry / thumb print / requiring the presence of another device to issue a specific command, etc.). 7) Distribution Rights - Optional. If present, it refers to an authorization authority in a rights management service (see description herein) that identifies and / or describes the rights that the device 110 has to issue a new authorization to another device 110 for the SCM 120. In other words, the distribution rights relate to the rights of the device 110 to share the authorization with other devices. If not present, it may be based fully or partially on at least the authorization types described in clause 1) and section VII. In an alternative embodiment, both the authorization types and the digital rights management service may be used together, such as by performing a cross-check. 8) Command Rights - Optional. If present, references an authorization authority in a rights management service (see description herein) that identifies and / or describes the rights that device 110 has to issue and / or receive certain commands and / or responses. For example, device 110 can issue a command to open a door but cannot close it. Rights can be granted on a per-command or per-class basis. If not present, command rights may be based fully or partially on at least the authorization types described in clause 1) and section VII. In alternative embodiments, both authorization types and digital rights management services may be used together, such as by cross-checking. In another alternative embodiment, a list of authorized commands (and other metadata that may be required) may be provided instead. In yet another alternative embodiment, a list of prohibited commands (and other metadata that may be required) may be provided instead. 9) Other possible attributes for which SCM 120 allows or denies interaction. Although in one embodiment, device 110 may communicate securely with SCM 120 only if device 110 possesses authorization for such secure communication, it should be understood that there may be scenarios or circumstances in which device 110 may communicate insecurely with SCM 120.

[0071] Note that not all attributes need to be communicated to SCM 120 or device 110. For example, some attributes may only reside in cloud 130.

[0072] The SCM 120 can authorize the device 110 to send and / or receive one or more of requests, commands, updates, and responses based on at least one of the following: 1) One or more authorizations have been granted (e.g., see at least the ACP in Section III). 2) All or some of the potentially necessary conditions are met in one or more validated authorizations. 3) The device 110 is authenticated. Thus, in addition to the above conditions, each authorization may include cryptographic keys (e.g., a Device-SCM-Key and / or a User-SCM-Key) and data used by the device 110 to establish an encrypted communications link with the target SCM 120, by the device 110 to authenticate the target SCM 120, and by the target SCM 120 to authenticate the device 110. The data used for the device 110 in such circumstances is described in further detail in the System Key Description section, also identified as the Key System in Section XII. III. Approval Package

[0073] In one embodiment, the information may be communicated to the SCM 120 in a secure manner via an authorization configuration package (ACP), shown in accordance with one embodiment of Figure 4 and designated at 400. The ACP 400 may include authorizations or other configuration data, or both, that may be transmitted to the SCM 120. It should be understood that one or more devices 110 may transmit the ACP 400 to the SCM 120, although the ACP 400 may be transmitted to the SCM via other devices and the present disclosure is not limited to transmission via the device 110.

[0074] The ACP 400 may be encapsulated in an ACP container 410, which may be encapsulated within an ACP container collection 414, as shown according to one embodiment of FIG. The ACP 400, ACP container 410, and / or ACP container collection 414 may be based on sequenced multi-layer encryption. The ACP container 410 may include nested layers, each of which may be encrypted differently, such as encrypting each layer according to a different encryption key. In this manner, the nested layers may be conceptualized as layers of an onion, where each inner layer cannot be accessed without decrypting the outer layer.

[0075] In one embodiment, the ACP container 410 may be a secure means for distributing configuration data over a distributed system to the SCM 120. The ACP container 410 in the illustrated embodiment may be distributed to the device 110 by the cloud 130. The ACP container 410 may utilize sequenced multi-layer encryption in a manner that provides one or more of the following: · Confidentiality and integrity substantially guaranteed regardless of device or communications security (e.g., insecure devices using insecure communications links). Substantially guaranteed authenticity and that multiple authorized system components have approved the contents of the ACP 400 (e.g., the owner device 110, its user, and one or more cloud services 130, including, e.g., two or more cloud services 130, if separate cloud authorization request and cloud authorization approval services are used as described herein). · Virtual assurance that the ACP400 is intended for the target SCM120 and that other system components cannot decrypt unauthorized content in the ACP400. · Substantial assurance of the state of the system 100 (e.g., that the appropriate system components have approved their configurations in a defined order). Allowing authentication and authorization to be performed using only the communications link between the device 110 and the target SCM 120, even if the target SCM 120 has not previously communicated with the device 110 (e.g., authentication may be performed when disconnected from the Internet, when neither the device 110 nor the SCM 120 is accessing any cloud services 130, in other words, when both the device 110 and the SCM are offline).

[0076] The structure of the ACP container 410, together with the authorization change process and the encryption sequence of the package layers implemented by the cloud 130, can ensure that only the target SCM 120 can decrypt the ACP container 410 in its entirety and that multiple system components (e.g., the user 10, the cloud 130, and the owner device 110, or a combination thereof) have approved the ACP 400. The encryption sequence of the ACP container 410 is described in further detail below, from the innermost layer (decrypted last) to the outermost layer (decrypted first). The structure of the ACP container 410 may vary depending on the application. However, in the illustrated embodiment, the ACP container 410 can include at least one of an integrity hash (e.g., a cryptographic hash and / or a signature), a timestamp, a version, a sender identity, a receiver identity, and other data location and encapsulation attributes (not shown in FIG. 4 or FIG. 5).

[0077] After all necessary authorized layers have been decrypted, authenticated, integrity verified, and attributes checked across layers for consistency, the ACP container 410 or any layers (including ACP 400) are processed and / or stored by SCM 120. In the illustrated embodiment, SCM 120 is authorized to process and decrypt all layers of ACP container 410, but it should be understood that there may be additional layers of ACP container 410 that SCM 120 is not authorized or configured to process or decrypt. It should also be noted that while ACP container 410 is described herein as having multiple layers, the number of layers and the composition or structure of the ACP container may vary depending on the application. It should also be understood that while any portion of ACP container 410 (including ACP 400) may be stored, such layers may be stored in the format in which they were received (encrypted), in the format in which they were received but decrypted, in an alternate format (e.g., optimized for storage efficiency or run-time retrieval), or in any combination thereof. A.ACP outer layer 1

[0078] 4, the ACP 400 is contained within an ACP Outer Layer 1 designated at 401. The ACP Outer Layer 1 can verify that the ACP 400 originated from the cloud 130 and was intended for the target SCM 120. The cloud 130 can encrypt the ACP Outer Layer 1 with a key (such as a Cloud-SCM-Key key, described in more detail in at least Section XII herein), which can be unique to a pair defined by the target SCM 120 and the cloud 130. In one embodiment, optionally, only the cloud 130, the target SCM 120, and devices 110 with authorization for that target SCM 120 may be able to decrypt this ACP Outer Layer 1.

[0079] In an alternative embodiment, the key utilized to encrypt the ACP outer layer 1 may be a Cloud-SCM-Key key that is not specific to the pair defined by the target SCM 120 and the cloud 130. For example, a common key shared among all SCMs 120 in a system of multiple SCMs 120 may be utilized. In an embodiment, in the absence of a Cloud-SCM-Key key, verification that the ACP originates from the cloud 130 and is intended for the target SCM 120 may be accomplished in another manner that is not limited to the use of the Cloud-SCM-Key. In an alternative embodiment, the system 100 may not utilize validation of the ACP outer layer 1 based on the Cloud-SCM-Key, but may instead rely on other layers of encryption and sequencing or authentication of the cloud 130 (as described herein). B.ACP outer layer 2

[0080] In the illustrated embodiment of FIG. 4, ACP Outer Layer 1 is contained within ACP Outer Layer 2 designated at 402. ACP Outer Layer 2 can verify that the ACP 400 (originating from the cloud 130) for the target SCM 120 has been viewed and approved by the user 10 at the owner device 110 for the target SCM 120. The user account service of the cloud 130 can encrypt the ACP Outer Layer 2 with a key, such as a User-SCM-Key key described in more detail in at least Section XII herein, which can be unique to the pair defined by the target SCM 120 and the user account associated with the device 110. In one embodiment, authorization can be issued to the user account for the target SCM 120, thereby authorizing all devices 110 associated with that user account.

[0081] In one embodiment, optionally, only the cloud 130, target SCM 120, and devices 110 associated with a user account that has approved the ACP 400 can decrypt the ACP outer layer 2.

[0082] In an alternative embodiment, the device 110 can encrypt the ACP outer layer 2 with a key, such as a Device-SCM-Key key, described in more detail in at least Section XII herein, which key can be specific to a pair defined by the target SCM 120 and the device 110. In one embodiment, authorization may be issued for the target SCM 120 to a specific device 110. Optionally, in one embodiment, only the cloud 130, the target SCM 120, and the specific owner device 110 for the target SCM 120 that has approved the ACP 400 can decrypt the ACP outer layer 2.

[0083] In alternative embodiments, the ACP outer layer 2 may be encrypted with a Device-SCM-Key or User-SCM-Key key that is not specific to the pair defined by the target SCM 120 and device 110 or user account. For example, a common key shared among all SCMs 120 in a system of multiple SCMs 120 may be utilized. In one embodiment, if the Device-SCM-Key or User-SCM-Key key is different from the Cloud-SCM-Key key, or if the Device-SCM-Key or User-SCM-Key does not exist, verification that the ACP 400 has been viewed and approved by the user 10 of the owner device 110 for the target SCM 120 may be accomplished in another manner that is not limited to the use of the Cloud-SCM-Key. In alternative embodiments, the system 100 may not utilize ACP outer layer 2 verification based on the Cloud-SCM-Key or User-SCM-Key, and may instead rely on other layers of encryption and sequencing or cloud authentication (described herein). C.ACP outer layer 3

[0084] In the illustrated embodiment of FIG. 4, ACP Outer Layer 2 is contained within ACP Outer Layer 3 designated at 403. ACP Outer Layer 3 can verify that ACP 400 (originating from cloud 130) for target SCM 120 has been viewed and approved by user 10 at owner device 110 for target SCM 120, and verified by cloud 130 as unaltered and approved by user 10 at owner device 110 for target SCM 120 via out-of-band authentication mechanisms (described herein). Cloud 130 can encrypt this layer with a key, such as an SCM-Key key described in more detail herein at least in Section XII, which key can be unique to target SCM 120. In one embodiment, only target SCM 120 can decrypt ACP Outer Layer 3. Because the ACP outer layer 2 may be encrypted by one of potentially multiple owner accounts (User-SCM-Key) and / or devices 110 (Device-SCM-Key), the metadata in this layer includes an indication of which account and / or device 110 signed the ACP outer layer 2 (e.g., Device-SCM-ED or User-SCM-ID).

[0085] In alternative embodiments, the ACP outer layer 3 may be encrypted with an SCM-Key key that is not specific to the target SCM 120, and a common key shared among all SCMs 120 in a system of multiple SCMs 120 may be utilized. In one embodiment, if the SCM-Key key is not different from the Device-SCM-Key key, or if the SCM-Key does not exist, verification that the cloud 130 has authorized the ACP 400 by the user 10 without modification via an out-of-band authentication mechanism (described herein) at the owner device 110 for the target SCM 120 may be accomplished in another manner that is not limited to the use of the SCM-Key key. In alternative embodiments, the system 100 may not utilize verification of the ACP outer layer 3 based on the SCM-Key, and may instead rely on encryption and sequencing of other layers or cloud authentication (described herein). In all embodiments where out-of-band authentication is included in this verification, there are alternative configurations where out-of-band authentication is removed entirely or is only required for certain types of modifications. D.ACP outer layer 4

[0086] In the illustrated embodiment of FIG. 4, ACP Outer Layer 3 is contained within ACP Outer Layer 4 designated at 404. ACP Outer Layer 4 can verify that the completed ACP container 410 originated from and was approved by cloud 130 and is destined for target SCM 120. Cloud 130 can encrypt ACP Outer Layer 4 with a key, such as a Cloud-SCM-Approval-Key key described in more detail herein at least in Section XII, which can be specific to the pair defined by target SCM 120 and cloud 130. In one embodiment, optionally, only cloud 130, target SCM 120, and devices 110 with authorization for that target SCM 120 can decrypt ACP Outer Layer 4.

[0087] In one embodiment, because the cloud authorization request and cloud authorization approval services cannot be separated, the ACP outer layer 4 may be encrypted with a Cloud-SCM-Key key, described in more detail herein at least in Section XII, which may be specific to the pair defined by the target SCM 120 and the cloud 130.

[0088] In one embodiment, the ACP outer layer 4 may be encrypted with a Cloud-SCM-Approval-Key or Cloud-SCM-Key key that is not specific to the pair defined by the target SCM 120 and the cloud 130. For example, a common key shared among all SCMs 120 in a system of multiple SCMs 120 may be utilized. In one embodiment, if the Cloud-SCM-Approval-Key or Cloud-SCM-Key key is not distinct from the SCM-Key key, or if the Cloud-SCM-Approval-Key or Cloud-SCM-Key is not present, validation that the completed ACP container 410 originated from and was approved by the cloud 130 and is intended for the target SCM 120 may be accomplished in another manner. In an alternative embodiment, the system 100 may not utilize validation of the ACP outer layer 4 based on the Cloud-SCM-Approval-Key or Cloud-SCM-Key, and may instead rely on other layers of encryption and sequencing or cloud authentication (as described herein).

[0089] The structure of the ACP container 410 utilized within the security model may achieve or substantially achieve a separation of authentication and authorization. Although the security model may separate these actions into different services and structures, the security model may not explicitly separate authentication and authorization into two separate trees (i.e., separate trust roots) that are separately authenticated. Instead, the authentication and authorization trees may be separately authenticated by distributed encryption and sequence decryption. The separation of authentication and authorization may be approximated by requiring a hacker to obtain keys from multiple separate physical cloud servers 130 (in addition to the device 110) in order to generate and / or decrypt the ACP container 410.

[0090] One example configuration to approximate the separation of authentication and authorization is to separate a) a service (cloud authorization request service) that generates the initial ACP 400 and requests the user 10 to approve the ACP 400, and b) a service (cloud authorization approval service) where the user 10 approves the initial ACP 400 and generates the final ACP container 410. In one embodiment, the key used in ACP outer layer 4 (e.g., Cloud-SCM-Approval-Key used by the cloud authorization approval service) may be different than the key used in ACP outer layer 1 (e.g., Cloud-SCM-Key used by the cloud authorization request service). In one embodiment, the cloud service 130 that signs the ACP outer layer 4, such as the cloud authorization approval service, is on a different server than the cloud service 130 that signs the ACP outer layer 1, such as the cloud authorization request service. IV. ACP Container Delivery

[0091] In one embodiment, the ACP container 410 may contain all current authorizations for the target SCM 120. The cloud 130 may generate and / or update a complete (i.e., not a partial update) ACP container 410 and automatically distribute it to all associated devices 110 whenever data contained within the ACP 400 for an SCM 120 changes via a push mechanism. Examples of changes include: a) data and authorizations in the ACP 400 that are added, changed, and / or revoked for an SCM 120, b) an SCM 120 instructed to factory reset, c) an authorized original owner device, and d) an encryption key that is rotated. A. Pushing ACP container

[0092] The push mechanism may be used for delivery of all ACP containers 410, or the use of the push mechanism may be limited to delivery of ACP containers 410 in response to certain changes and / or events. An associated device 110 may be considered a device 110 that has a current authorization, or that previously had one or more authorizations, but has not yet been sent an updated ACP container 410 (e.g., the SCM 120 has a newer ACP 400) for the target SCM 120. A current authorization is an authorization that has not been revoked (i.e., removed, disabled, deleted) and has not expired (i.e., an authorization that is valid). The push mechanisms used may include, but are not limited to, any combination of mobile, web, or desktop platform push notification services (e.g., WebSockets, Apple Push Notification Service (APNS), Google Cloud Messaging (GCM) and Urban Airship), persistent polling based device-cloud connections or long polling based device-cloud connections or similar device-cloud connections, mesh, star, and / or other topology device-to-cloud messaging, and SMS, and may vary based on the type of device 110.

[0093] The push mechanism may deliver the ACP container 410 directly (so that the device 110 can request the ACP container 410 immediately or at a later time) or may notify the device 110 of an updated ACP container 410. The device 110 may be configured to disallow certain types of push mechanisms (e.g., APNS) if the cloud 130 is using an alternative push mechanism (e.g., SMS) or is not using a push mechanism (e.g., the device 110 periodically queries for updates to the ACP container 410). In another embodiment, the system 100 may always use a push mechanism for delivery of the ACP container 410. In another embodiment, the system 100 may not or does not always use a push mechanism for delivery of the ACP container 410. In another embodiment, the system 100 may use a push mechanism to deliver the ACP container 410 to all devices 110 that have authorization (current or not) within the associated device. In another embodiment, the system 100 may distribute the ACP container 410 to distribute only the current authorizations in the associated device. In another embodiment, the scope of the current authorizations may be expanded to include authorizations that have expired within a fixed or configurable predetermined time (e.g., per cloud, per device, per SCM, per appliance). For example, the current authorizations distributed may include authorizations that have expired within the last two days.

[0094] In the illustrated embodiment, the cloud 130 can deliver the current ACP container 410 to associated devices 110 without current authorization. In another embodiment, the cloud 130 may send the first version of the ACP container 110 to each associated device 110 without current authorization if the device 110 no longer has any current authorization.

[0095] The device 110 can automatically request the currently authorized ACP 400 for an SCM 120 (or for all SCMs 120 for which the device 110 has current authorization) from the cloud 130 when a particular event occurs. Exemplary events include when an application changes execution state (e.g., starts, pauses, resumes, stops, or terminates), periodically when a connection to the SCM 120 and / or cloud 130 is established, or when requested by a user, immediately thereafter reset. In one or more alternative embodiments, all permutations of the above delivery and / or request trigger combinations may be performed.

[0096] One or more SCMs 120 or one or more devices 110, or any combination thereof, may be located in an environment where a communications link to the cloud 130 is unavailable. For example, the communications link may not exist or may be unavailable by some means, including indirectly through other system components, such as by routing the communications link through another device or equipment component 140. Such lack of a communications link may be permanent or temporary.

[0097] In one embodiment, the security model of the system 100 does not suffer significantly from the lack of communication, primarily because it is not strictly required that the SCM 120 have communicated with the cloud 130 prior to authorizing the device 110. The SCM 120 need only expect that the device 110 has communicated with the cloud 130 at some point prior to communicating with the SCM 120. One problem that may arise in this situation is that if the SCM 120 does not store the ACP 400 that contains the authorization for the device 110, the SCM 120 may not be able to establish a secure communication link with the device 110. However, due at least in part to the cryptographic sequencing and / or layering of the ACP container 410, and because the ACP container 410 can only be decrypted by the target SCM, the ACP container 410 may be transmitted to the SCM 120 over an insecure communication link. In this manner, the SCM 120 may receive an updated ACP 400 from any source over any communication link, including from devices 110 with which the SCM 120 has never communicated and from devices 110 (or other system components / sources) for which it does not possess authorization. For example, a device 110 whose authorization has been revoked may communicate an ACP container 410 that includes an updated ACP 400.

[0098] In one embodiment, the device 110 may send an updated ACP 400 to the SCM 120 before establishing a secure communication link. The device 110 may send an updated ACP 400 to the SCM 120 after a secure communication link is established. If the updated ACP 400 does not include authorization for the connected device 110, such an existing secure communication link may be terminated. In one embodiment, the SCM 120 may refuse to establish a secure communication link with a system component that has a newer version of the ACP container 410 than the version stored by the SCM 120. In one embodiment, the SCM 120 may refuse to establish a secure communication link with a system component that has a version of the ACP container 410 that does not match the version stored by the SCM 120. B.ACP Container Version Package

[0099] To facilitate eliminating the need for SCM 120 to receive and process ACP container 410 on every connection from every device 110 to determine if device 110 has a different ACP 400, the first N bytes of ACP container 410 (where N is the number of bytes required to obtain the needed information, also known herein as ACP container version package 412) may be sent as part of the connection establishment process between device 110 and SCM 120 (described herein) and SCM 120 can decrypt to obtain the needed information, which may include the ACP version and / or other attributes used for comparison, such as an integrity hash or signature, or both. In one embodiment, as described herein, ACP container version package 412 is delivered to device 110 as the first N bytes of ACP container 410 (where N is the number of bytes deemed necessary to obtain the needed information). If the SCM 120 determines that the device 110 has a newer version of the ACP 400, the SCM 120 may utilize the device 110 to provide the updated ACP 400 before a secure connection is established. In an alternative embodiment, the SCM 120 may decide to perform an ACP update process if the device 110 has a different ACP 400, which may not be newer than the ACP 400 stored in the SCM 120. If the SCM 120 is not in a factory reset mode waiting for the first owner device 110 to associate with the SCM 120 and the ACP container version package 412 has not been provided, the connection to the device 110 may be denied or terminated, or both. This factory reset mode operation is described in further detail herein, at least in section XD.

[0100] If device 110 has already established a secure connection with SCM 120, SCM 120 periodically requests device 110 to send ACP container version package 412, and if an updated ACP 400 exists, SCM 120 either disconnects from device 110 and requests device 110 to reconnect (thus sending the updated ACP 400) or requests device 110 to send the updated ACP 400 via the secure connection. Additionally or alternatively, if device 110 has already established a secure connection with SCM 120, device 110 may notify SCM 120 of the updated ACP 400 (along with ACP container version package 412) and, if SCM 120 determines that the update is appropriate (as described herein), disconnect from device 110 and expect device 110 to reconnect (thus sending the updated ACP 400) or request device 110 to send the updated ACP 400 over the secure connection. If device 110 fails to respond (e.g., within a certain period of time) to a request to send ACP container version package 412, SCM 120 may disconnect from it.

[0101] In one embodiment, the ACP container version package 412 may be delivered by the cloud 130 to a sender, most likely device 110, as a separate encrypted package for delivery to an SCM as part of the connection establishment process described herein at least in Section XIV. The ACP container version package 412 may be delivered along with the ACP container 410 or as the first part of the ACP container 410, as illustrated in FIG. 5 by ACP container collection 414. It should be noted that ACP container 410 and ACP container collection 414 may be used interchangeably throughout this disclosure. It should also be noted that where delivery of an ACP 400 is described, such delivery may be accomplished via the ACP container 410.

[0102] In one embodiment shown in FIG. 5, the ACP container version package 412 may include an ACP version, one or more embedded identifiers, such as a large random or sequence number, and a message authentication code or signature. One or more of the embedded identifier, message authentication code, signature, and some or all of the ACP-Version-Key may be stored in the ACP container 410 for verification. The ACP container version package 412 may be encrypted with a key, such as an ACP-Version-Key key generated by the cloud 130 and specific to the target SCM 120 as described herein. In an alternative embodiment, the ACP container version package 412 may be encrypted with the ACP-Version-Key key and then further encrypted with one or more other keys, such as a Device-SCM-Key key or an SCM-Key key, or both.

[0103] In an alternative embodiment, the ACP container version package 412 is simply an ACP version of the ACP 400 that the device 110 possesses without the corresponding encryption key in the ACP container 410, previously generated or provided by the device 110. As an example, in this embodiment, the SCM 120 can trust the version provided by the device 110 and use that version to determine whether to request the ACP container 410. The ACP version may be defined by a number or string that may or may not be encrypted with a shared encryption key via the device 110.

[0104] It is recognized that this alternative embodiment is much less secure than the previous embodiment and has a potential vulnerability that allows device 110 to say that it has any version of ACP 400 that it desires. However, in general, this is unlikely to happen, and the most likely drawback may be that device 110 will either (a) not send ACP 400 for update (because the version is older than the current one) or (b) send ACP 400 for update (which will be rejected after processing every time if the version number is very high). It would be virtually impossible for device 110 to manufacture ACP 400. Thus, the most likely drawback is that SCM 120 would have to shoulder a lot of extra work, i.e., denial of service (DoS). C. Verification

[0105] When SCM 120 receives ACP container 410, SCM 120 may verify the authenticity of ACP container 410 by decrypting each of its layers in turn, ensuring that the contents of ACP container 410 have not been tampered with and have been properly decrypted by computing and comparing integrity hashes (signatures), verifying that the provided ACP container version package 412 and its contents match the corresponding contents (e.g., ACP version and any other applicable attributes) at the various layers of ACP container 410, and performing other consistency and data integrity / validity checks (not enumerated) as ACP container 410 is processed at each layer.

[0106] If at any point validation of the ACP container 410 fails, the ACP container 410 may be considered invalid and rejected (not stored). If the new ACP container 410 is accepted (e.g., all validations are completed successfully and the new ACP 400 is considered different from the current ACP 400), it is stored in the SCM 120 and is immediately activated or becomes the current ACP 400.

[0107] The ACP container 410 (or ACP 400) itself may or may not be stored in memory 212 of SCM 120 upon receipt, since decrypting the ACP container 410 may be an intensive process and there may be more optimal data structures / data configurations for use in a real-time system. The ACP container 410 or ACP 400 may be stored in secure memory 220, or in an equivalent hardware module such as a secure enclave or hardware security module (HSM). The ACP container 410 or ACP 400 may be stored in whole or only in part. Alternatively, the ACP container 410 or ACP 400 may be encrypted with an alternate encryption key in ROM (and decrypted during execution and stored in RAM), or may be stored unencrypted in protected ROM, or some combination of the above or other techniques. Examples of additional or other techniques include software- or hardware-based approaches that can prevent access to such data, can provide hardware barriers or shields, can provide physical barriers or shields, can disable JTAG and other ports, can harden software interfaces to eliminate attack vectors, can establish a trusted execution environment (hardware or software), and can detect attempts to root access or security breach the operating system.

[0108] In an alternative embodiment, the contents of ACP container 410 may be stored unencrypted in ROM, rather than in the original format of ACP container 410. In another alternative embodiment, ACP container 410 may be stored in ROM when received (with all layers of encryption) and decrypted and stored in RAM during operation. D. Acquire ACP Container - Delivery Path

[0109] The ACP container 410 and / or ACP container version package 412 according to one embodiment of the disclosure may be received or obtained by the device 110 or SCM 120, or both, in a variety of ways.

[0110] In one embodiment, the ACP container version package 412 is optionally provided by the device 110 to the SCM 120. If the ACP container version package 412 is not provided to the SCM 120, the SCM 120 may be required to obtain and decrypt the first layer of the ACP container 410 to determine the ACP version of the encapsulated ACP 400. In an alternative embodiment, the ACP container version package 412 may not be provided by the device 110. In this case, the device 110 or the SCM 120 may be required to notify or request an update to the ACP container 410 and process the entire ACP container 410.

[0111] In another alternative embodiment, device 110 may request from SCM 120 the ACP container version package 412 that SCM 120 currently possesses. Device 110 may then compare the version of ACP 400 identified in ACP container version package 412 to the version of ACP 400 stored in memory and determine whether to send the ACP container 410 to SCM 120. In this embodiment, the request for the ACP container version package 412 may not be sent as part of the connection establishment process for device 110 and SCM 120, as described herein, at least in section XIV.

[0112] In one embodiment, the device 110 may send a complete version of the entire ACP container 410 to the SCM 120. In one embodiment, the device 110 may send the ACP container 410 to the SCM 120 at the discretion of the device 110, which may be based on a user request, a cloud request, or a device process, or any combination thereof. In one embodiment, the ACP container 410 may be delivered to the SCM 120 by a system component other than the device 110, such as an equipment component 140 or other accessory connected to the device 110, using an available communication link. The available communication link may vary from application to application or under different circumstances and may be a physical medium, a wireless link, a wired link, or any combination thereof.

[0113] In one embodiment, the ACP container 410 may be delivered directly to the SCM 120 via the cloud 130. Additionally or alternatively, the ACP container 410 may be delivered to an alternative and / or intermediate system component, such as the equipment component 140 or another device, and then delivered to the SCM 120 using an available communication link. The available communication link may vary depending on the situation and may be at least one of a physical medium, a wireless link, and a wired link.

[0114] In the illustrated embodiment, the full ACP container 410 may be sent to SCM 120 because there are potential risks of partial updates and inconsistent system states, including unintended behavior due to unprincipled Internet connections and the possibility of partial updates being missed. Exemplary risk scenarios include a situation in which if an owner adds device A and then removes device B, the resulting configuration in SCM 120 may not be accessible to either device A or device B. In other words, the initial update may have been missed. However, these risks may be overcome or reduced by adding attributes that track the version and ordering of partial updates.

[0115] In one embodiment, partial or incremental updates to the ACP container 410 may be obtained from the cloud 130. The updates may include at least one of adding, deleting, or changing authentication, or a combination thereof, and rotating encryption keys. In one embodiment, partial or incremental updates to the ACP container 410 may be sent to the SCM 120. In an alternative embodiment, the ACP container 410 may be split into smaller configuration packages, such as an SCM identity configuration package and an ACP 400.

[0116] In one embodiment, it may be necessary or desirable to reduce the size of the ACP container 410 that is transmitted. One approach to do so is to use a delta update, where only the differences between two particular ACP containers 410 are transmitted. Given that there are multiple versions of the ACP container 410 and the delta update image is specific to the previous or next version of the ACP container 410, the delta update image (the image transmitted to the SCM 120 that performs the update) may be generated by a system component (e.g., device 110) that transmits the delta update image to the SCM 120. In one embodiment, the delta update image may be used to transmit the ACP container 410 to the SCM 120, where the delta update image is generated by a system component (e.g., device 110) that transmits the delta update image to the SCM 120. In one embodiment, the delta update image may be used to transmit the ACP container 410 to the SCM 120, where the delta update image is created by the cloud 130. In one embodiment, the delta update image may be used for other messages and configuration packages in the system 100.

[0117] Additionally or alternatively, reducing the size of the transmitted ACP container 410 may be achieved through compression. Compression may be performed by either the cloud 130 or a system component (e.g., device 110) that transmits the ACP container 410. In one embodiment, compression may be used to transmit the ACP container 410 to the SCM 120. In one embodiment, both compression and delta update images may be used to transmit the ACP container 410 to the SCM in either order (compression first, then delta, or delta first, then compression). In one embodiment, compression may be used for other messages and configuration packages in the system 100.

[0118] In one embodiment, the SCM 120 may connect to the cloud 130, in which case the SCM 120 does not store the authorizations in the ACP 400, but instead requests the cloud 130 to determine whether a particular device 110 is authorized when appropriate or necessary. For example, the cloud 130 may be requested to determine that the identity of the device 110 is authorized. If the device 110 has authorization, then the authorizations may be cached on the SCM 120 for the duration of the device 110's connection to the SCM 120 (or longer if memory permits). Additionally or alternatively, the authorizations may be cached on a local server (or set of servers) to reduce network latency.

[0119] In one embodiment, an ACP 400 stored on a device 110 for a particular SCM 120 may include only the authorizations for that device 110. Additionally or alternatively, the SCM 120 may merge authorizations from multiple devices 110 into a unified ACP 400 stored on the SCM 120.

[0120] In one embodiment, each SCM 120 may receive and store multiple ACPs 400, where each ACP 400 includes a subset of all sets of authorizations issued to the SCM 120. This may prevent the ACP 400 from becoming too large in an environment where many devices 110 are authorized (e.g., a building access control system where hundreds or thousands of employees are authorized to unlock specific locks, or a fleet environment). The contents of each subset ACP 400 may include only authorizations for a particular set of user accounts and / or devices 110. For example, in one embodiment, a subset ACP 400 may be created for each user account (where the ACP 400 includes only devices 110 associated with that user account). For example, in another embodiment, a subset ACP 400 may be created for each set of 10 user accounts. For example, in yet another embodiment, a subset ACP 400 may be created for each set of 100 devices 110. The subset ACPs 400 may be delivered as part of an aggregate ACP container 410 that includes all subset ACPs, an aggregate ACP container 410 that includes any number of subset ACPs 400 (e.g., modified subset ACPs 400), individual ACP containers 410 (i.e., one for each subset ACP 400), or any combination thereof. In one embodiment, each ACP container 410 may have one ACP container version package 412 that includes version information deemed necessary for each subset ACP 400. In another embodiment, each ACP container 410 may have multiple ACP container version packages 412. V. Managing and Delivering Replacement Packages

[0121] There may be other packages of data defined for SCM 120 that are configured and generated in accordance with one or more embodiments described herein with respect to ACP container 410, including similar semantics, processing, and encoding as ACP container 410. As a result, it should be understood that other configuration (and other) packages may be utilized and may be managed and / or distributed in a similar manner. There may also be packages defined for other system components (e.g., device 110 or equipment component 140). The following are examples of packages that may exist (some of which are described in further detail herein): 1) Application settings 2) Firmware update package 3) Subcomponent Settings 4) The equipment protocol setting 5) Equipment model 6) Blacklist Package 7) System Log Package

[0122] In embodiments in which the security model / system described herein is applied to a micro-rotation system, examples are described in U.S. patent application Ser. No. 14 / 620,959, filed Feb. 12, 2015, by J. Michael Ellis et al., entitled "System and Method for Communicating with a Vehicle," and U.S. patent application Ser. No. 15 / 488,136, filed Apr. 14, 2017, by Raymond Michael Stitt, entitled "System and Method for Establishing a Real-Time Location," the disclosures of which are incorporated herein by reference in their entireties. Examples of information that may be provided according to one embodiment of a micro-location system include the following: 1) The zone configuration or associated data may identify one or more areas or spaces to the SCM 120 that are deemed relevant for use by a user or owner of equipment 140. For example, an area or space within 5 feet of a door may be deemed relevant for operation of the door, and presence within this zone may trigger, for example, to enable access through the door. 2) The monitoring device configuration and configuration or associated data may identify settings for the remote device 310 as described in connection with the embodiment illustrated in FIG. 3, such as connection parameters for communicating with the SCM 120 and for positioning the remote device 310 relative to the SCM 120. 3) The algorithm tuning settings or associated data may indicate one or more compensation factors for an algorithm used in determining the position of the device 110 relative to the SCM 120. 4) The algorithmic model or associated data may indicate the algorithm utilized in determining the location of the device 110 relative to the SCM 120 . VI. Candidate ACP

[0123] In the illustrated embodiment, cloud 130 may maintain a copy (candidate ACP) of the currently active ACP 400 for each SCM 120. Candidate ACPs may be identifiable by the version of ACP 400 under version control, where the version changes each time a change is made. For example, a new version may be created and the version of ACP 400 may be incremented each time a change is made.

[0124] When a new candidate ACP identified for approval for the owner account is created, each of the owner account devices 110 (and corresponding users 10) may be notified, for example via push notification or SMS, that a new ACP 400 has been created for approval. The users 10 can then retrieve the updated candidate ACP at the devices 110 for approval. The users 10 can approve the candidate ACP from any of the devices 110 associated with the owner user account (i.e., the user account that is authorized as the owner of the SCM 120).

[0125] In one embodiment, authorization is issued only to a particular device 110 (i.e., on behalf of a user account). That way, when a new candidate ACP is created that is identified for authorization of the owner device 110, the owner device 110 (and the corresponding user 10) can be notified, for example via push notification or SMS, that a new ACP 400 has been created for authorization. The user 10 can then retrieve the latest candidate ACP on the device 110 for authorization.

[0126] In one embodiment, the candidate ACP may include additional changes from other owners 10, some or all of which may be undesirable. As a result, the user 10 can either (a) reject the candidate ACP by not approving it, in which case nothing happens, or (b) edit the candidate ACP until it is acceptable, submit the changes to the cloud 130 (pushing another approval request to the owner device 10), and then approve the ACP. The editing, submission, and approval steps may be integrated into the user interface of the device 110. If the candidate ACP is rejected, it remains and future changes may be made to the rejected version.

[0127] If edits to a candidate ACP are submitted and the ACP version of the candidate ACP is no longer the current ACP version, cloud 130 may reject the submission and allow device 110 to obtain a more recent candidate ACP for evaluation. For example, if the candidate ACP was updated by another device 110 during the approval process, the edits at device 110 may have been made on an older version of ACP 400, and thus cloud 130 may reject all changes submitted by device 110 and restart the approval process to accept and edit the candidate ACP based on the current version of ACP 400.

[0128] After or in response to approval of the candidate ACP by the user 10 using the owner device 110, the candidate ACP may be signed by the Device-SCM-Key (private) key of the approval device 110. In one embodiment, the candidate ACP may be further signed by a User-SCM-Key key associated with the approval device 110. In another embodiment, the candidate ACP may be instead signed by a User-SCM-Key key associated with the approval device 110. The signed version of the candidate ACP may be submitted to the cloud 130, which may determine that the signed version of the candidate ACP matches the current version of the candidate ACP stored in the cloud 130 and / or that the appropriate device 110 has approved (signed) it. Optionally, the cloud 130 may determine whether the user 10 of the owner device 110 has disabled two-factor authentication (2FA), and if so, the cloud 130 may send the 2FA code to the user 10 (via one or more selected mediums, such as the device 110 of the user 10 or another device associated with the user 10).

[0129] If the signed version of the candidate ACP submitted by the device 110 to the cloud 130 does not match the current version of the candidate ACP stored in the cloud 130 or is not approved by the appropriate device 110, the submission may be rejected (and the approval process may be repeated). If the signed version of the candidate ACP submitted by the device 110 matches the current version of the candidate ACP in the cloud 130, the candidate ACP is identified as approved by the appropriate device 110, the user 10 does not enable 2FA, and the submission is accepted. Optionally, if the user receives a 2FA code, the user may enter the 2FA code into the owner device 110, which then submits the entered 2FA code to the cloud 130. The cloud 130 may then verify that the submitted 2FA code matches the sent 2FA code. If there is a match, the submission is considered accepted if other criteria are also met. If there is no match, the submission is rejected (and the approval process may be repeated). In alternative embodiments, cloud 130 may base acceptance on receipt of one or more user-associated keys, such as at least those described herein in Section XII.N (e.g., retina, face, and / or touch ID).

[0130] After cloud 130 determines to accept a submission by device 110 of a signed version of a candidate ACP, cloud 130 marks the corresponding candidate ACP as approved, generates final ACP container 410, and distributes ACP container 410 to various devices associated with SCM 120. In one embodiment, if the submitted ACP version is older than the candidate ACP, the submission is rejected.

[0131] The candidate ACP approach can provide the system 110 with both a blockchain-type ledger of the ACP 400 and an approach that can avoid potential concurrency or blocking issues that can arise if multiple versions of the ACP 400 are available for approval or if only one version of the ACP 400 is available for approval at a time. The ledger of the ACP 400 can provide an audit history, where each edit results in a new version, and each version is associated with a particular device 110.

[0132] In an alternative embodiment, a candidate ACP process may not be utilized to distribute and approve ACPs 400. Instead, a new ACP 400 may be generated for approval each time a change is made that elicits approval. Additionally or alternatively, a new ACP 400 may be generated for approval each time a change is made that elicits approval if subsequent changes prior to approval of the new ACP 400 are rejected. VII. Authorization Types

[0133] In one embodiment, system 100 may utilize or associate one or more rights associated with device 110, defined as one or more authorizations and discussed herein in at least Section II. An authorization may have a type associated with it, known as an authorization type (see, e.g., Sections 1) and VII).

[0134] Authorization may be associated with a pairing defined between a device 110 and an SCM 120. It should be understood that for purposes of disclosure, authorizations and authorization types are described with respect to one device 110 paired with one SCM. However, there are many possible combinations of pairings between multiple devices 110 and multiple SCMs 120, including multiple devices 110 associated with one or more SCMs 120.

[0135] In one embodiment, an authorization type may be associated with a user account for each SCM 120 to which the user account is authorized. The authorization type may then flow to authorizations created for each device 110 and associated with the user's account. For example, a user account service may create authorizations for each of the user's devices 110 and apply the user account authorization type for a particular SCM 120 to each created authorization. In one embodiment, a user account may have zero or more authorization types (e.g., guest-admin next week, guest thereafter), each valid at different times and / or under different conditions, according to the authorizations associated with the user account, for each SCM 120 to which the user account is authorized.

[0136] In yet another embodiment, the authorizations may be associated only with a particular device 110. For example, one or more or all authorizations may not be associated with multiple user accounts and / or may not be shared among devices 110 associated with a single user account.

[0137] The authorization type may ultimately indicate the type of role that a particular device 110 has with respect to a particular SCM 120. In the system 100, the authorization type may also determine the authorization rights associated with a particular authorization, including, but not limited to, the right to do one or more of "grant another right," "transfer ownership," "make someone the owner," "add a guest," "share with others," and "issue a particular command." In alternative embodiments, the authorization type and the authorization rights may be managed separately, such as, for example, for management of block fan rights, in accordance with one or more embodiments described herein at least in Section XX. The authorization type may be a useful aspect of a security model, since it may control the various actions that a particular device 110 (and, on its behalf, its user 10) may perform with respect to a particular SCM 120 (and, on its behalf, the equipment components that communicate with the SCM 120). Exemplary authorization types are listed below for disclosure purposes and include, but are not limited to, an owner authorization type, a guest-administrator authorization type, a guest authorization type, a valet authorization type, and an organization authorization type. A. Owner

[0138] An owner authorization type may be reserved for user accounts and / or devices 110 that have full authority for a given SCM 120. A user account with an owner authorization type is known as an owner account. A device 110 that has owner authorization is known as an owner device 110. Each account and / or device 110 may be associated with at most one owner authorization for a given SCM 120. However, an SCM 120 may be associated with multiple owner accounts and / or devices 110. In one embodiment, an owner account and / or device 110 for a given SCM 120 may have no other valid authorizations for the same SCM 120. If an account and / or device 110 is issued an owner authorization after other authorizations have been issued, all other authorizations may be revoked, such as in accordance with the authorization issuance methodology described herein in at least Section VIII.

[0139] In an alternative embodiment, the SCM 120 may have a maximum of one owner account.

[0140] In an alternative embodiment, the SCM 120 may have at most one owner device.

[0141] In the illustrated embodiment of FIG. 1, the owner account and / or device 110 can view, issue (create), modify, and revoke (delete) any authorizations for a given SCM 120. The owner account and / or device 110 can transfer the SCM 120 to a new account and / or device 110, thereby revoking all authorizations for the SCM 120 that originated from the owner account and / or device 110, and can create owner authorizations for the target account and / or device 110, respectively. In one embodiment, the owner account and / or device 110 may be configured such that the owner account and / or device 110 must approve all authorization changes for a given SCM 120. The user 10 may or may not need to be involved depending on the type of change. In one embodiment, any owner account and / or device 110 may approve the authorization changes. When the owner authorization for an account and / or device 110 is revoked, all authorizations originating from that account and / or device 110 may also be revoked.

[0142] In an alternative embodiment, when the owner authorization of an account and / or device 110 is revoked, all authorizations accrued from that account and / or device 110 may be moved to another owner account and / or device 110 for SCM 120, or to a guest-administrator account and / or device 110.

[0143] As discussed herein, an authorization may be associated with one or more access attributes, including whether the authorization includes an owner authorization type. A modification that restricts or changes the access attributes for an issued authorization may apply to all issued authorizations that include the access attributes (including all authorizations issued based on the access attributes being restricted or changed). For example, if the owner authorization type or access attributes are changed, any authorizations issued from this owner authorization type may be modified in a similar manner. In alternative embodiments, a modification that restricts the access attributes of an issuing authorization (e.g., changing the start / end dates) may not affect any of the issued authorizations based on the access attributes of the issuing authorization.

[0144] In one embodiment, all or a subset of the SCMs 120 in the system 100 may be configured such that each SCM 120 has at least one owner account and / or device 110, except when in a factory reset state, in which case the SCM 120 is in a transitional state while awaiting assignment of its first owner account and / or device 110. It should be understood that not all embodiments are configured in this manner. After at least one owner account and / or device 110 is associated with a given SCM 120, that at least one owner account and / or device 110 may remain associated with the given SCM 120. As an example, the last owner authorization for a given SCM 120 may not be revoked unless the given SCM 120 is transferred to a new owner account and / or device 110. In an alternative embodiment, the last owner authorization for the SCM 120 may be revoked, and when the last owner authorization is revoked, the SCM 120 enters a factory reset mode.

[0145] In one embodiment, once an owner authorization is created, it cannot be changed to another authorization type. In alternative embodiments, the owner authorization may be changed to any other authorization type. Changing to another authorization type may result in previously issued authorizations being no longer permitted. These authorizations may be automatically or manually moved to alternative accounts and / or devices 110 with applicable authorizations, or may be revoked. B. Guest-Administrator

[0146] A guest-administrator authorization type may be associated with an account and / or device 110 that has nearly complete privileges for a given SCM 120. A device 110 with guest-administrator authorization is known as a guest-administrator device (or a guest device, if there are no operational differences with respect to the guest authorization type). A user account with a guest-administrator authorization type is known as a guest-administrator account (or a guest account, if there are no operational differences with respect to the guest authorization type). Each account and / or device 110 may have at most one guest-administrator authorization for a given SCM 120. However, a given SCM 120 may have multiple guest-administrator accounts and / or devices. A guest administrative account and / or device 110 for a given SCM 120 may not have other valid authorizations for the same SCM 120. In one embodiment, if an account and / or device 110 is issued a guest-administrator authorization after other authorizations have already been issued, all other authorizations may be revoked, such as in accordance with the authorization issuance method described herein at least in Section VIII.

[0147] In an alternative embodiment, each account and / or device 110 may have zero or more guest-administrator authorizations for a given SCM 120. In another alternative embodiment, each account and / or device 110 may be issued zero or more other permissible authorizations for the same SCM 120. In yet another alternative embodiment, an account and / or device 110 may not be issued a guest-administrator authorization if other authorizations have already been issued. In yet another alternative embodiment, if an account and / or device 110 is issued a guest-administrator authorization after other authorizations have already been issued, the redundant or impermissible authorizations may be revoked, such as in accordance with the authorization issuance methods described herein, at least in Section VIII.

[0148] 1, guest-administrator accounts and / or devices 110 can issue (create) non-owner authorizations, but can only view, modify, and revoke (delete) the authorizations that they issue (or have been issued) to a given SCM 120. Guest-administrator accounts and / or devices 110 may be issued authorizations with limited access attributes. For example, guest-administrator accounts and / or devices 110 may be issued authorizations with limited expiration dates.

[0149] A guest-administrator account and / or device 110 may not issue authorizations with broader access attributes than the authorizations of the guest-administrator account and / or device 110. To provide an example, a guest-administrator account and / or device 110 may not issue authorizations with expiration dates outside of the expiration dates associated with a guest-administrator authorization type.

[0150] If the authorization access attributes of a guest-administrator account and / or device 110 are modified to be more restrictive, the authorizations issued by the guest-administrator account and / or device 110 may be modified accordingly to remain permissible or may be revoked. In one embodiment, when a guest-administrator authorization for an account and / or device 110 is revoked, all authorizations derived from the guest-administrator authorization from that account and / or device 110 are also revoked. A guest-administrator account and / or device 110 for an SCM 120 may not issue authorizations to itself (i.e., the same account and / or device 110) for the same SCM 120.

[0151] In an alternative embodiment, a guest-administrator account and / or device 110 for an SCM 120 may issue authorizations to itself (i.e., the same account and / or device 110) for the same SCM 120. In one embodiment, a guest-administrator authorization may not have limited access attributes. In one embodiment, a guest-administrator account and / or device 110 issued an authorization from an issuing account and / or device 110 (e.g., an owner account and / or device 110) may view authorizations issued to other accounts and / or devices 110 that include or exclude the issuing account and / or device 110 that was issued an authorization from the issuing account and / or device 110 for a given SCM 120, at the discretion of the issuing account and / or device 110. In an alternative embodiment, when the guest-administrator authorization of an account and / or device 110 is revoked, all authorizations derived from the guest-administrator authorization of the account and / or device 110 may be moved to another owner account and / or device 110, or to a guest-administrator account and / or device 110, for SCM 120.

[0152] In one embodiment, a guest-administrator account and / or device 110 may submit an authorization change request for approval by an issuing account and / or device 110 (eg, an owner account and / or device 110).

[0153] In one embodiment, once a guest-administrator authorization is created, the guest-administrator authorization cannot be changed to another authorization type. In one embodiment, a guest-administrator authorization may be changed to any other authorization type, which may result in one or more authorizations issued from the guest-administrator authorization being no longer permitted. Such authorizations may be automatically or manually moved to an alternative account and / or device 110 with applicable authorizations, or revoked. C. Guest

[0154] A guest authorization type may be associated with an account and / or device 110 that has limited privileges for a given SCM 120. A device 110 that has a guest authorization is known as a guest device 110. A user account that has a guest authorization type is known as a guest account. Each account and / or device 110 may have zero or more guest authorizations for a given SCM 120, and an SCM 120 may have multiple guest accounts and / or devices 110. A guest account and / or device 110 of a given SCM 120 may not have an owner or guest-admin authorization valid for the same SCM 120. If an account and / or device 110 is issued a guest authorization after other authorizations have already been issued, the redundant or impermissible authorization may be revoked, such as in accordance with the authorization issuance methodology described herein in at least Section VIII.

[0155] In an alternative embodiment, each account and / or device 110 may have up to one guest authorization for a given SCM 120. In another alternative embodiment, if an account and / or device 110 is issued a guest authorization after other authorizations have already been issued, all other authorizations may be revoked, such as in accordance with the authorization issuance method described herein in at least Section VIII. In yet another alternative embodiment, each account and / or device 110 may be issued zero or more other permissible authorizations for the same SCM 120. In yet another alternative embodiment, an account and / or device 110 may not be issued a guest authorization if other authorizations have already been issued. In yet another alternative embodiment, if an account and / or device 110 is issued a guest authorization after other authorizations have already been issued, redundant or impermissible authorizations may be revoked, such as in accordance with the authorization issuance method described herein in at least Section VIII.

[0156] 1, a guest account and / or device 110 can issue (create) valet authorizations, but can only view and revoke (delete) authorizations issued to the guest account and / or device 110 for a given SCM 120. A guest account and / or device 110 may be issued one or more authorizations with limited access attributes. For example, a guest account and / or device 110 may be issued an authorization with a limited expiration date.

[0157] A guest account and / or device 110 may not issue an authorization with broader access attributes than the authorization of the guest account and / or device 110. To provide an example, a guest account and / or device 110 may not issue an authorization with an expiration date outside of the expiration date associated with a guest authorization type provided to the guest account and / or device 110.

[0158] If the authorized access attributes of a guest account and / or device 110 are modified to be more restrictive, the authorizations issued by the guest account and / or device 110 may be modified accordingly to remain permissible or may be revoked. When a guest authorization for an account and / or device 110 is revoked, all authorizations derived from that guest authorization may also be revoked.

[0159] In an alternative embodiment, a guest account and / or device 110 cannot revoke its own guest authorization. A guest account and / or device 110 for an SCM 120 may not issue authorizations to itself (i.e., the same account and / or device 110) for the same SCM 120.

[0160] In an alternative embodiment, a guest account and / or device 110 issued an authorization from an issuing account and / or device 110 (e.g., an owner account and / or device 110) may view authorizations issued to other accounts and / or devices 110 that include or exclude the issuing account and / or device 110 that was issued the authorization from the issuing account and / or device 110 for a given SCM 120, at the discretion of the issuing account and / or device 110. In an alternative embodiment, when a guest authorization for an account and / or device 110 is revoked, all authorizations from the guest authorization for the account and / or device 110 may be moved to another owner account and / or device 110, or a guest-administrator account and / or device 110, for the SCM 120. In one embodiment, a guest account and / or device 110 may submit an authorization change request for approval by the issuing account and / or device 110.

[0161] In the illustrated embodiment, after a guest authorization is created, it cannot be changed to another authorization type. In alternative embodiments, a guest authorization may be changed to any other authorization type, which may result in one or more authorizations issued from the guest authorization being no longer acceptable. Such one or more authorizations may be automatically or manually moved to an alternative account and / or device 110 with applicable authorizations or revoked. D. Barrett

[0162] A valet authorization type may be considered a special purpose authorization type for accounts and / or devices 110 that have limited privileges for a given SCM 120. A device 110 with valet authorization is known as a valet device. A user account with a valet authorization type is known as a valet account. Each account and / or device 110 may have zero or more valet authorizations for a given SCM 120. However, an SCM 120 may have multiple valet accounts and / or devices 110. A valet account and / or device 110 of a given SCM 120 may not have owner authorization, guest-admin authorization, or guest authorization valid for the same SCM 120. If an account and / or device 110 is issued a valet authorization after other authorizations have already been issued, redundant or impermissible authorizations may be revoked, such as in accordance with the authorization issuance methods described herein at least in Section VIII.

[0163] A valet account and / or device 110 may only view authorizations that the valet account and / or device 110 has been issued for a given SCM 120. A valet account and / or device 110 may be issued authorizations with limited access attributes. For example, a valet account and / or device 110 may be issued authorizations with limited expiration dates.

[0164] In an alternative embodiment, valet authorizations may not exist. In another alternative embodiment, a limited number of valet authorizations may be provided to a given SCM 120 account and / or device 110. The number may be a fixed number (e.g., one). In yet another alternative embodiment, valet authorizations may be transferred to another account and / or device 110 that belongs to or is associated with the same entity (e.g., a valet service organization) as the valet account and / or device 110.

[0165] In one embodiment, valet authorization may be automatically revoked when some event occurs (e.g., a non-valet account and / or device 110 is connected to SCM 120 or equipment component 140 indicates that SCM 120 has moved beyond some reasonable threshold).

[0166] In the illustrated embodiment, after a valet authorization is created, it cannot be changed to another authorization type. Alternatively, a valet authorization may be changed to any other authorization type, which may result in one or more authorizations issued from the valet authorization being no longer permitted. Such authorizations may be automatically or manually moved to an alternative account and / or device 110 with applicable authorizations or may be revoked. E. Organization

[0167] In one embodiment, an organization authorization type may comprise the ability for a set of accounts and / or devices 110 to grant owner authorization to one or more other accounts and / or devices 110 for one or more SCMs 120 associated with the organization. F. Transfer

[0168] In one embodiment, as described herein, a transfer authorization type may be used during the ownership transfer process of SCM 120. This authorization type is transitory. It is used to signal that such a transfer is desired so that appropriate approvals and revocations can be performed, and based on the approval, owner authorizations may be applied to the target account (and its device 110). G. Other Potentially Dynamic Types

[0169] In one embodiment, the authorization types available for use in system 100 may be dynamic. The set of authorization types may be changed at run-time, via pre-run-time configuration, or programmatically. For example, new authorization types not previously used in system 100 may be introduced via ACP 400 to accounts and / or devices 110 and SCM 120. H. Authorization Tree

[0170] It should be understood that, in accordance with one or more embodiments described herein, and particularly with respect to one or more authorization types, authorization types and associated access rights may be granted from a first account and / or device 110 to a second account and / or device 110, and so on, depending on the rights granted to the first and second accounts and / or devices 110. In this manner, a tree of authorizations may be created that dynamically changes over time as new authorizations are granted and older authorizations are revoked or modified. Examples of two types of such trees are shown in the illustrated embodiments of FIGS. 6 and 7.

[0171] 6 and 7, there are multiple SCMs 120 in the system 100, each associated with one or more owner accounts and / or devices 110. The one or more owner accounts and / or devices 110 directly or indirectly provide authorization for guest-administrator accounts and / or devices 110, guest accounts and / or devices 110, and valet accounts and / or devices 110. VIII. Authorization Issuance Sequence

[0172] In the illustrated embodiment of FIG. 1, a user 10 can issue, modify, and revoke various types of authorizations to multiple SCMs for a user account (and, via a user account service, a device 110) and / or the device 110. The security model can utilize the involvement of multiple system components for issuing authorizations, including the user 10 (to accept both the authorization issuance request and the resulting ACP 400). Modifying and revoking authorizations may not necessarily require the involvement of a user.

[0173] A method for issuing one or more authorizations according to one embodiment is shown in Figure 8 and generally designated 800. The method 800 includes various steps including step 801) a user 10 with the right to issue an authorization sends an authorization issuance request using a device 110 (for which it has the right) to a recipient user account and / or device 110 for a particular SCM 120, step 802) the recipient user accepts the authorization issuance request using the respective device 110 (e.g., any device 110 associated with the respective user account, the particular device 110), and step 803) the owner device 110 for the SCM 120 accepts the changes to the ACP 400 resulting from the issued authorization.

[0174] In addition to the above, as described herein, two-factor authentication (2FA) may be added as a system level requirement in one or more of the steps above. However, for ease of understanding, 2FA messages are not shown in the sequence diagrams above. Note that the two-factor authentication request may be completed using any device 110 associated with the applicable user account.

[0175] In one embodiment, a communication path is provided for a first user 10 to send an authorization issuance request to a second user 10 that does not have an existing user account and / or original equipment manufacturer (OEM) cloud account. The communication path may be based at least in part on email and / or SMS communication. A message delivered to the second user 10 may request the second user 10 to obtain an application for the device 110 of the second user 10 (if appropriate) or visit a website to create a user account and / or OEM account and accept the request.

[0176] As described herein in connection with one or more embodiments, an ownership transfer request can be considered a special case of a typical authorization issuance process because it results in the issuance of an owner authorization, with the cancellation of all other authorizations for a given SCM 120. In the illustrated embodiment of Figure 8, both the new owner and the previous owner may be required to approve the ownership transfer request, although due to the nature of the ownership transfer request, the candidate ACPs cannot be changed until the transfer request is approved.

[0177] In at least the illustrated embodiment shown in step 803, the owner account and / or device 110 (and, on its behalf, its user 10) can approve changes to the ACP 400 initiated by any user 10 to the SCM 120. If the owner account and / or device 110 issues a non-owner authorization (e.g., guest), the issuing user 10 may not be required to be involved in the approval process of the ACP 400. Even in cases where user 10 involvement is not required (e.g., no 2FA or pressing of an approval button is not required), the owner device 110 may be involved (e.g., by running a process in the background without user intervention).

[0178] There may be other authorization and / or authorization processes that desirably do not require user involvement. Any of the authorization and / or authorization processes described herein may be adapted in such a manner that does not require user involvement. It is desirable to improve the user experience by not requiring the user 10 to be involved in the approval of anything that the user initiates. If the user 10 has multiple devices 110 associated with their user account, it is desirable to request approval from another user device 110 even if they initiate a change. In an alternative embodiment, the scope of changes to the ACP 400 may be limited such that a) the user 10 may be required to be involved in the approval for the SCM 120, or b) the user 10's involvement in the SCM 120's approval process may only be required when a new owner authorization is issued. When a new owner authorization is issued, user involvement may be required. Even when user involvement is not required, such as when 2FA is not enabled or pressing an approval button is not enabled, the owner device 110 may still be involved (e.g., by running the process in the background without user intervention).

[0179] In an alternative embodiment, changes to the ACP 400 may be delegated. As discussed herein, the owner account and / or device 110 may be configured to approve the ACP 400 for the SCM 120. The owner account and / or device 110 may delegate approval authority for the ACP 400 to another account and / or device 110 attempting to issue an authorization. The approval authority may be limited to a subset of the authorization types available to the owner account and / or device 110, or may include all available authorization types. For example, if Owner C grants Guest A a guest authorization and the authority to delegate guest authorizations, Guest A can issue a guest authorization to Guest B without Owner C's involvement. In another example, approval authority may be delegated if there are no other changes to the ACP 400. Otherwise, the owner account and / or device 110 or a non-owner issuing account and / or device 110 in the issuing chain may approve the changes to the ACP 400.

[0180] If a system component, such as device 110, is determined to be jailbroken, the system component (or the system component that detected the anomaly) may alert cloud 130. A jailbroken device 110, or other component, may be defined as a component whose operating system or its infrastructure software (e.g., standard libraries or applications) have been compromised. Cloud 130 may consider the jailbroken device 110 to be stolen and intended for malicious use, and therefore revoke authorizations issued to or by the jailbroken device 110. In one embodiment, cloud 130 may revoke authorizations issued to or by a user account associated with the jailbroken device 110.

[0181] The illustrated embodiment of Figure 8 includes several steps highlighted herein, including sending a request to issue an authorization, accepting the request to issue an authorization, and accepting changes to the ACP 400 resulting from the issued authorization (steps 801, 802, 803). The illustrated embodiment highlights that one or more of these steps may include one or more additional steps.

[0182] For example, step 801 for sending an authorization issuance request may be defined by user A currently being classified as an owner, with user A's device A being the owner device 110. User B and her device 110, labeled device B, may be eligible for authorization issuance. User A may request user B's username (e.g., "B"), to which user B may respond (steps 821, 822). User A may instruct her device A to issue a guest authorization to user B. The device 110 sends the request to the cloud 130 (step 823). The cloud 130 verifies that user A's device 110 is authorized to issue authorizations for a given SCM 120 (step 824). In one embodiment, the authorization applies to all of user B's devices 110. In another embodiment, if user B has multiple devices 110, user A may select which of user B's devices 110 the authorization is sent to (step 825). The cloud 130 requests one of the devices 110 of user B to accept or reject the authorization (step 826). If user B accepts the authorization, the device 110 of user B generates a Device-SCM-Key and sends the relevant part (e.g., public key) to the cloud 130, which uses it to update the candidate ACP (step 827). The existence of the updated candidate ACP is communicated (via the device 110) to user A, who accepts the change to the candidate ACP. The device 110 used by user A signs the approved candidate ACP and sends it to the cloud 130 to approve the change (step 828). This approval step can be considered a requirement in one embodiment if the change is a transfer of ownership, even if the originator is the owner device.

[0183] Cloud 130 verifies the signed candidate ACP, generates final ACP 400, and announces its existence to all applicable devices 110 (step 829). Devices 110 obtain (e.g., via ACP container 410, ACP container collection 414, or other medium) the updated ACP 400 (step 830). User B's device 110 sends (e.g., via ACP container 410 or any other medium) the updated ACP 400 to SCM 120 (step 831). IX. User Account Model and Device Registration

[0184] In one embodiment, the system 100 may utilize the familiarity of the user with accessing the service via an account model, such as a username and password-based account model. Additionally or alternatively, the system 100 may utilize a key-based identification system (i.e., cryptographic identity) based on the identity of the device 110. The key-based identification (i.e., cryptographic identity) may provide a degree of anonymity to the user while facilitating tracking of changes or transactions to the ACP 400 according to a blockchain ledger. Similar to, and based at least in part on, a cryptographic system in which a user is identified and authenticated using an anonymous public key as part of an asymmetric cryptography / cryptographic identity, and a blockchain ledger that tracks transactions, the system 100 may utilize the device identity as a key in the authorization issuance sequence. The device identity may be dynamic or fixed based on one or more characteristics of the device, potentially avoiding identification, tracking, and authentication of the user 10 by an account and password. The system 100 may substantially equate the physicality of the device 110 with that of a mechanical key, and may consider the identity of the device 110 as a proxy for the user 10.

[0185] The device identities utilized in the system 100 may be defined to purposefully omit as much user and device identifying information as possible from the various system components in order to protect both the identity of the user 10 and the device 140, as well as to substantially prevent hackers from obtaining that information in the event of a security breach. However, to facilitate business and user experience for grouping devices 110 with users 10, each device 110 may be provided with a Cloud-User-ID by the cloud 130 (user account service) when the device 110 is registered.

[0186] The Cloud-User-ID may be the same for each device associated with the same OEM user identifier (OEM-ED). As a result, it is possible to determine the set of devices 110 associated with a particular Cloud-User-ID. The user account service of the cloud 130 may use a secure database approach to abstractly tie the OEM user account (via the OEM user identifier) ​​to the Cloud-User-ID, and the service of the cloud 130 that stores and performs this mapping (the user account service) is isolated or separated from other services of the cloud 130 and the OEM cloud, allowing user identifiable information to remain external to the OEM cloud. This approach may prevent unauthorized access by a hacker unless the hacker penetrates three separate system components (at least two of which are in separate management infrastructures, domains, or control areas) to compile personally identifiable information (PII), such as the mapping of the user 10 to the OEM user account, the mapping of the user 10 to the device 110, and the mapping of the user 10 to the SCM 120 or equipment 140.

[0187] In alternative embodiments, cloud 130 may not use a secure database approach, but may still provide a separate user account service integrated with other services of cloud 130. For example, the user account service may potentially operate over the same infrastructure, network, or virtual private network. In another embodiment, cloud 130 may not separate OEM account information from other user information. To provide an example, cloud 130 may not use a secure database approach, and the OEM user identifier and Cloud-User-ID may not exist or be abstracted.

[0188] In the illustrated embodiment, cloud 130 may not maintain personally identifiable account information. As a result, cloud 130 may not have a traditional concept of a user account and may lack a non-OEM cloud login API that allows direct access. Device 110 may be registered with the OEM cloud and associated with an OEM user account, which in turn may interact with cloud 130.

[0189] A method for registering a device according to one embodiment is described in the illustrated embodiment of FIG. 9 and generally designated 900. The device 110 securely connects (e.g., via TLS) with the OEM Cloud (step 901). Using input from the user 10, the device 110 sends the user's username and password to the OEM Cloud (step 902). If the username and password are verified (i.e., correct), the OEM Cloud provides the device 110 with a Cloud-User-ED, an OEM identifier, any required tokens (e.g., a session token and / or a cloud token), and any other data required to successfully register the device. The OEM Cloud may interact with other parts of the cloud 130 (step 903). The device 110 sends a registration request to the OEM Cloud (step 904), including a session token (which can be mapped to a specific Cloud-User-ID and OEM-ED, allowing the device 110 to not send them separately or to request them separately as additional validation), any other required tokens (such as a push notification service token), a device rights public key (if using a device rights service such as the block fan system described herein), and a device-specific signature (e.g., obtained from the device's operating system software). In one embodiment, a device-specific signature (e.g., an identifier or vendor application identifier) ​​may be utilized in the registration process to substantially avoid or prevent a malicious device from registering the same device multiple times.

[0190] In the method 900, the OEM cloud may verify the registration request (step 905). If the registration request is successful, the OEM cloud provides a Device-ID to the registered device 110 (step 906).

[0191] To help protect against accidental duplicate registration of the same device 110, a device-specific signature is provided as part of the device registration request. The device signature need not be a cryptographic signature, nor need it be truly device-specific (e.g., it may be application installation specific). Rather, the device signature may be an identifier that can be used to attempt to uniquely identify a particular device (e.g., a serial number or application instance number, such as a randomly generated number or a number provided by an operating system). If successful, the device registration process may provide the generated Device-ED to the device 110 for use in subsequent processing, such as issuing authorizations.

[0192] In an alternative embodiment, the OEM cloud may not be utilized. The cloud 130 may allow the device 110 to register with a randomly generated (possibly unique) Cloud-User-ED. The Cloud-User-ED in this case may include a specific globally defined or configurable OEM identifier, and the device 110 may be responsible for maintaining or providing all facilities utilized to obtain device aggregation information and information to perform desired inter-device processing.

[0193] In many cases, the OEM provides the user interface for the device component 140, such as, but not limited to, a branded website and mobile applications. Thus, the OEM can manage the corresponding system components required to deliver to the device component 140, including OEM-branded user accounts and device-related services provided by the OEM cloud.

[0194] Through a set of Application Programmer Interfaces (APIs) using appropriate privacy and trust (encryption, authentication, and authorization), the OEM Cloud can obtain from the Cloud 130 which devices 110 are associated with a particular user, manage authorization, and perform any device ownership adjustments required over the product life of the OEM's equipment components 140. Privacy and trust can be established in a variety of ways, including TLS 1.2+ mutual authentication using X.509 certificates, and via OAuth2 or a proxy / custom challenge / response mechanism (OEM Cloud). An example OAuth2 challenge / response flow, or method 1000, for interactions between the OEM Cloud, the user 10, and the Cloud 130 is shown in the illustrated embodiment of FIG.

[0195] In the illustrated embodiment, the user 10 may obtain a user account from the OEM cloud 135, which may be configured similarly to the cloud 130 described herein (step 1002). The user 10 may then log into the OEM cloud 135 to obtain a temporary OEM cloud identifier and / or cloud token (e.g., for use in an OAuth2 authentication process) (step 1004). The user 10 may provide the temporary OEM cloud identifier and / or cloud token previously obtained from the OEM cloud 135 to the cloud 130 to request a Cloud-User-ID from the cloud 130 (step 1006). The cloud 130 may verify with the OEM cloud 135 the cloud token and / or temporary OEM cloud identifier provided by the user 10 (step 1008). If the cloud token and / or temporary OEM cloud identifier are verified, cloud 130 may send a Cloud-User-ID to user 10, possibly along with an OEM cloud identifier (OEM user identifier) ​​(which may also be a temporary OEM cloud identifier, but with its temporary status cleared). The temporary OEM cloud identifier used above may simply be used as a means to verify that OEM cloud 135 and cloud 130 refer to the same user. The temporary OEM cloud identifier may also be used for other purposes, such as to direct which server to connect to, or to allow OEM cloud 135 to use a different OEM cloud identifier (Cloud-User-ID) than cloud 130.

[0196] In an alternative embodiment, privacy and trust may be established via TLS 1.2+ server-side (cloud) authentication using X.509 certificates and OAuth2 or a delegated or custom challenge and response mechanism (OEM Cloud) established with the OEM Cloud 135. In another alternative embodiment, privacy and trust may be established using TLS 1.2+, or a custom or delegated encryption and authentication protocol with OAuth2, or a delegated or custom challenge and response mechanism.

[0197] As described herein, in one embodiment, the cloud 130 may not provide a user account service that allows users to create an account and then associate their device 110 with the account using a web or mobile application. Instead, the OEM cloud may provide these services. The user account service provides the ability to identify devices 110 associated with an OEM user account (via an OEM user identifier) ​​for use by the OEM cloud. The user account service of the cloud 130 may provide anonymous user accounts. In one embodiment, the cloud 130 may provide traditional user account management and device 110 related services (e.g., via a user account management service) that may be used by the OEM cloud, other OEM services, applications, and system components such as users 10, devices 110, SCM 120, equipment 140, and the cloud 130 itself. This embodiment may or may not use the secure database approach described herein and may or may not expose cloud-generated OEM user identifiers (or OEM cloud identifiers) for use by the OEM in each system. User account management and device-related services provided by the user account management service of cloud 130 may include (but are not limited to): 1) Create and activate user accounts (by name, email, phone number, and password) with two-factor authentication and email verification. 2) Add or remove devices to and / or from a user account. 3) View the devices associated with the user account and the authorizations associated with the devices.

[0198] In one embodiment, authorizations may be shared across all devices 110 associated with the user account of the user 10. Authorization changes may be approved by any device 110 associated with the user account associated with the owner device 110 of the SCM 120. The user 10 may or may not be able to configure how authorizations are shared between those devices 110. For example, the user 10 may or may not be able to configure which devices 110 receive authorization for which SCMs 120. The user account service can ensure that these operations are performed on behalf of the user per any configured preferences and system rules. X. Monetization

[0199] The system 100 in one embodiment may be configured to request payment from the user 10 for certain operations performed by the system 100. In this manner, the system 100 may monetize aspects or functionality provided by the system 100. Maintaining the technology and infrastructure for system components to operate and communicate securely can be a difficult and expensive process. Additionally, the user 10 may expect technological advancements, improvements, compatibility with new products and technologies offered in the market, and security patches or enhancements, all of which may require funding. There are numerous system operations described herein that are computationally expensive but have no direct or specific involvement by the user 10. There are many computationally expensive system operations (i.e., services) that involve the user 10, such as issuing, modifying, or revoking authorizations, registration, transferring ownership or factory resetting the SCM 120, updating firmware, etc. Payment for services may be made by the user 10, the OEM, or other entities. The following actions may be monetized with respect to the operation of the security model / system described herein: issuance of authorization, registration of device 110, transfer of ownership of SCM 120, factory reset of SCM 120, and firmware update. It should be understood that monetization is not limited to these events and other events or circumstances may form the basis for monetization. A. Issuance of Permit

[0200] The OEM may be billed for each authorization successfully issued by the user 10, where an invoice is generated for charges accrued and collected over a predefined period of time, such as daily, weekly, or monthly. Alternatively, the OEM may be billed in real-time for each authorization successfully issued. This real-time billing model may result in micropayments.

[0201] The user 10 may be billed for each authorization successfully issued by the user 10, where an invoice may be generated for charges accrued and collected over a predefined period, such as daily, weekly, or monthly. Alternatively, the user 10 may be billed in real-time for each authorization successfully issued by the user 10, resulting in monetization based on micropayments. In this embodiment, payment may be approved by the user 10 indicating that the user 10 consents to being billed. Consent may be obtained when the authorization request is sent, and the user may be billed either when the recipient accepts the authorization or when the resulting changes to the ACP 400 are approved. Proof of consent may be provided as part of the request, which may be rejected in the absence of proof of payment approval.

[0202] In an alternative embodiment, if the authorization giving sequence is not successful, the user 10 may be charged immediately, but the transaction may be reversed / refunded.

[0203] In one embodiment, the user 10 may be billed for each authorization that the cloud 130 successfully issues to the user 10, where an invoice may be generated for charges accrued and collected during a predefined period, such as daily, weekly, or monthly. In one embodiment, the user 10 may be billed in real time for each authorization successfully received or requested by the user 10, creating a micropayment based monetization system. In this embodiment, payment may be approved by the user 10 indicating that the user 10 agrees to be billed. Consent may be obtained in conjunction with receipt of the authorization request. Evidence of consent may be provided as part of a request acceptance response, which may be rejected in the absence of evidence of payment approval. The user 10 may be billed either when the request acceptance response is received by the cloud 130 or when the resulting changes to the ACP 400 are approved. In an alternative embodiment, if the sequence is not successful, the user may be billed immediately, but the transaction may be reversed or refunded. B. Registering the Device

[0204] The OEM may be billed for each device successfully registered by a user 10, where an invoice may be generated for charges accrued and collected during a predefined period, such as daily, weekly, or monthly. In one embodiment, the OEM may be billed in real time for each device 10 successfully registered resulting in a micropayment type system.

[0205] In one embodiment, the user 10 may be billed for each device 10 successfully registered by the user 10, where a bill may be generated for charges accrued and collected during a predefined period, such as daily, weekly, or monthly. In one embodiment, the user 10 may be billed in real time for each device 10 successfully registered by the user, resulting in a micropayment type system. In this configuration, payment may be approved by the user 10 indicating that the user consents to being billed. Consent may be obtained in conjunction with the submission of a device registration request, and proof of consent may be provided as part of the request. In the absence of proof of payment approval, the request may be rejected and the user may be billed when the device registration is successfully processed. In an alternative embodiment, the user 10 may be billed immediately, but the transaction may be reversed or refunded if the device registration sequence is not successful. C. Transfer of SCM Ownership

[0206] The OEM in one embodiment may be billed for each successful transfer of ownership of the SCM 120 by the OEM's user 10. Invoices may be generated for billing amounts accrued and collected during a predefined period (e.g., daily, weekly, monthly, etc.). The OEM may be billed in real time for each successful transfer of ownership of the SCM resulting in a micropayment based monetization system.

[0207] The user 10 in one embodiment may be billed for each successful transfer of ownership of the SCM 120. An invoice may be generated for the collected billing amount accrued during a predefined period, such as daily, weekly, or monthly. In one embodiment, the user 10 may be billed in real time for each successful transfer of ownership of the SCM 120 resulting in a micropayment based monetization system. In this configuration, payment may be approved by the user indicating that the user consents to being billed. Consent may be obtained in conjunction with the submission of the device registration request and proof of consent may be provided as part of the request. In the absence of proof of payment approval, the request may be rejected and the user may be billed when the device registration is successfully processed. In an alternative embodiment, the user 10 may be billed immediately, but the transaction may be reversed or refunded if the device registration sequence is not successful. D. Factory reset of SCM

[0208] The OEM may be billed for each successful factory reset of the SCM 120 by a user associated with the OEM. Invoices may be generated for billing amounts collected accrued during a predefined period, such as daily, weekly, or monthly. In one embodiment, the OEM may be billed in real time for each successful factory reset of the SCM resulting in a micropayment based monetization system.

[0209] In one embodiment, the user 10 may be billed for each successful factory reset of the SCM 120, in which case an invoice may be generated for the billed amount collected over a predefined period, such as daily, weekly, or monthly. In one embodiment, the user 10 may be billed in real time for each successful factory reset of the SCM resulting in a micropayment based monetization system. In this configuration, payment may be approved by the user 10 indicating that the user 10 agrees to be billed. Consent may be obtained when the new owner initiation request is submitted, and proof of consent may be supplied as part of the request. In the absence of proof of payment approval, the request may be rejected. The user 10 may be billed when the cloud 130 generates the resulting ACP 400. In an alternative embodiment, the user 10 may be billed immediately, but the transaction may be reversed or refunded if the sequence is not successful. E. Firmware Update

[0210] The OEM may be billed for each successful firmware update by the user 10, where an invoice may be generated for the bill amounts collected accrued during a predefined period, such as daily, weekly, or monthly. The OEM in one embodiment may be billed in real time for each successful firmware update, which would result in a micropayment based monetization system.

[0211] The user 10 may be billed for each successful firmware update, in which case a bill is generated for the charges accrued and collected during a predefined period, such as daily, weekly, or monthly. The user 10 in one embodiment may be billed in real time for each successful firmware update (e.g., micropayment). In this configuration, payment may be approved by the user 10 (indicating that the user 10 agrees to be billed) when the firmware update is submitted or initiated. Proof of approval may be provided as part of the request, and the request is rejected if there is no proof of payment approval. The user 10 may be billed when a component of the system 100 detects that the firmware update was successful. In an alternative embodiment, the user 10 may be billed immediately, but the transaction may be reversed or refunded if the sequence is not successful. XI. Distributed Trust Model

[0212] The system 100 according to one embodiment can utilize a distributed trust model that can allow the devices 110, SCM 120, and appliance system components 140 to be either online and / or offline while still being able to establish trust, communicate securely, and operate. For example, the devices 110, SCM 120, and appliance system components 140 can enable authentication of system components and authorization of actions online and / or offline. A. Overview

[0213] In one embodiment, the system 100 can incorporate the principle of least privilege to enforce confidentiality and privacy, isolate system components, and reduce the attack surface. Communication between and data storage within system components can be achieved securely and confidentially through a unique combination of security criteria and processes, where the criteria include encryption, authentication, integrity verification, and / or security protocols, and where the processes include protocols, workflows, and / or system state management or verification.

[0214] For purposes of this disclosure, a system component is online if it can communicate with a service over the Internet, including, for example, if it can communicate with a certification authority.

[0215] In a sense, encryption can only provide a certain degree of confidentiality: the encrypted message or ciphertext can only be viewed or decrypted by an entity with the appropriate key. The key may be a shared secret or a key may be part of an asymmetric pair defined by a public key and a private key.

[0216] A secure (cryptographic) hash may be stored in the encrypted message to verify the integrity of the message or to ensure that the message has not been tampered with. Originator identification information may be stored in the encrypted message to verify the authenticity of the message. Message integrity and authenticity can be verified simultaneously by including a symmetric cipher, a message authentication code (MAC), or an asymmetric cipher (e.g., public key cryptography), or a digital signature in (or with) the encrypted message.

[0217] In asymmetric cryptography, a digital signature does not, by itself, guarantee that the creator signed and encrypted the message. Such a guarantee can be described as cryptographic non-repudiation or proof of authorship and / or origin.

[0218] Traditional sign-encrypt (SE) approaches are considered vulnerable to secrecy transfer; that is, anyone with the originator's public key can decrypt and then re-sign and re-encrypt the message using an alternate private key. The encryption (-E) step may or may not occur at one or more steps of the encryption process. For example, the encryption step may occur immediately as part of the message packaging, or the message may be a configuration or command message that is signed and encrypted. The encryption step may occur as part of a communication channel transport, such as TLS. The encryption step may not be present, such as when confidentiality of the packaging is not required or is provided by other means, such as the communication channel. A concrete example of unnecessary confidentiality may be simply a signed message.

[0219] If the public key was delivered with the message, the recipient may not be aware of any changes to the creator. Digital certificates (X.509), possibly managed by a Public Key Infrastructure (PKI), can provide evidence that a particular public key is the key of a particular creator, and therefore that a particular digital signature was created by a particular creator. In the absence of digital certificates, proof of creator, and possibly of intended destination, may be established by including the identity of the creator, the identity of the destination, or both, as appropriate, in the encrypted message when using the SE approach. The SE approach may include both a) signing the message more than twice, such as signing the SE message (SSE), and b) encrypting the message more than twice, such as encrypting the encrypt-then-sign (ES) message, as the EES message can be designed to do.

[0220] Symmetric cryptography may not suffer from secret transmission. The recipient can be assured that the creator is known and that the sender intended to send the message to the recipient. However, symmetric cryptography may not provide cryptographic non-repudiation since both parties have a shared secret. Systems based on symmetric cryptography may address and mitigate this issue through one or more layers of the selected security protocol, message packaging or storage, and communication method.

[0221] Symmetric and / or asymmetric encryption, using message integrity and authentication mechanisms, with and / or without digital certificates, is used throughout system 100 to communicate between and store data within system components. Many examples are described herein. Whenever asymmetric encryption is implemented, one or more of the following features may be used in system 100 to substantially overcome identified weaknesses of asymmetric encryption, as well as other known vulnerabilities or considerations not explicitly identified but generally known to the security community: Digital certificates

[0222] Digital certificates (X.509) may be used to verify the identity of system components that are always or nearly always online, such as cloud 130. System components may implement one or more of a public certificate authority, a private cloud certification authority, or a self-signed certificate. Public certificate and key

[0223] The public certificate and / or public key that may be used to decrypt a message are never distributed with the message; that is, the recipient in one embodiment must receive and authenticate the public certificate and public key in advance from a trusted source. Instead of being per cloud 130 or per SCM 120, public keys and certificates may be targeted to specific relationships deemed practical or useful, such as between pairs defined by device 110 and cloud 130 and between pairs defined by device 110 and SCM 120. Public keys and certificates may be stored only by the system components that utilize them. 3. Signature

[0224] If digital certificates are not used, signatures may be used and creator and / or recipient identities may be included in the message as appropriate to the capabilities and security requirements of the message content. Messages may be encrypted or unencrypted, or may be more than twice signed and / or more than twice encrypted. Evidence of authorship

[0225] Because of the distributed trustworthiness of system 100, system 100 may be configured to substantially guarantee that a particular message originated from a particular source. For example, a message may be distributed by any source, so long as the identity of the creator is preserved, and the message can be authenticated as originating from that particular source. Messages can be constructed and distributed such that the internals of a message intended for a particular system component are not visible to other components, but are verified by all or some of the components as having been created by a trusted component.

[0226] Symmetric and asymmetric keys, such as shared secret keys, public / private keys, certificates, etc., may be rotated or changed. This rotation or change may be performed as part of a breach recovery procedure or through normal processing of the system 100. The system 100 may rotate keys periodically. The system components and message definitions may support the action of providing updated keys as part of a key rotation protocol among system components or system communications, including online system components, offline system components, and components that switch between offline and online. Exemplary online system components or communications include cloud 130 or pairing between cloud 130 and device 110. Exemplary offline system components or communications include device 110, pairing between device 110 and SCM 120, SCM 120, pairing between appliance 140 and SCM 120, and appliance 140. In one embodiment, key rotation instructions and one or more keys may be delivered within message content, such as ACP 400.

[0227] System components or communications that use digital certificates, such as cloud 130 and communications between cloud 130 and device 110, may register revoked certificates using a certificate revocation list (CRL) of an appropriate certificate authority. Revoked certificates may be registered in real-time using the CRL. In alternative embodiments, revoked certificates may be registered in batches at a predefined period, such as hourly, four hourly, or daily. In alternative embodiments, revoked certificates may not be registered using the CRL.

[0228] System components or communications that use digital certificates, such as cloud 130 and communications between cloud 130 and device 110, can verify during the authentication process that the certificate has not expired or been revoked. Verification can be done using the CRL of the appropriate certificate authority. In an alternative embodiment, certificate revocation may not be checked. In another alternative embodiment, certificate expiration dates may not be checked.

[0229] In yet another alternative embodiment, the Online Certificate Status Protocol (OCSP) may be used instead of the CRL of the appropriate certificate authority. The OCSP responder may be a certificate authority, a third-party service, or may reside in the cloud 130.

[0230] In one embodiment, the system components may verify identity or creator using symmetric and / or asymmetric cryptography along with one or more of challenge / response security protocols, encrypted identity-containing messages, envelope public key cryptography (EPKE), and / or other means such as process and / or two-factor authentication. Additionally, multiple hardware or software-based security and authentication layers may be utilized, with or without certificates. To provide examples, there may be one or more layers of one or more security and authentication layers utilized to authenticate and encrypt the underlying communication channel, such as BLE authentication, DTLS, TLSS, NFC, or RFID, or a combination thereof.

[0231] Identity changes and revocations (and changes in identity verification or authentication) may be delivered to or from the cloud, or to or from all or some of the system components, such as via ACP 400, a factory reset procedure, or key rotation, or a combination thereof.

[0232] In one embodiment, certificates may be used for identity verification of online system components, while "raw" asymmetric encryption may be used for system components that may be offline. Although certificates may seem useful, they may involve significant resources that may not be available on constrained devices, such as system components with little ROM, RAM, processing power, or communications bandwidth / throughput.

[0233] In the illustrated embodiment system 100, the SCM 120, the device 110, and the equipment 140 can be considered constrained devices. While one or two certificates may be feasible, the number of certificates required to verify the authenticity of each authorization and the identity of each connected device 110 may not be feasible. Therefore, such system components may use "raw" asymmetric and / or symmetric encryption, because this type of encryption uses significantly less memory with a significantly lower processing overhead. Less memory usage can also result in a reduction in communication bandwidth for transferring information.

[0234] In one embodiment, device 110 may generate one or more self-signed digital certificates to establish the identity of device 110, as opposed to generating an asymmetric private / public key pair.

[0235] In alternative embodiments, symmetric cryptography may be used wherever raw public key cryptography is utilized, for example in the case of non-certificate based uses.

[0236] In one embodiment, P-256 (secp256rl) Elliptic Curve (ECC) (asymmetric) and AES-128 (symmetric) encryption is used. One or more alternative embodiments may utilize one or more of the following types of encryption: P-192 (secp192rl) Elliptic Curve (asymmetric) encryption (ECC), P-384 (secp384rl) Elliptic Curve (asymmetric) encryption (ECC), P-521 (secp521rl) Elliptic Curve (asymmetric) encryption (ECC), RSA (asymmetric) encryption, AES-192 (symmetric) encryption, and AES-256 (symmetric) encryption. It should be noted that the system is not limited to the encryption algorithms listed above. B. Certificate Validation

[0237] In one embodiment, one or more certificates may be used to verify the authenticity or origin of all or a subset of system components (online and offline), authorizations, and other critical data items and settings. In alternative embodiments, certificates may be chained (or signatures are chained on certificates) to ensure that the appropriate party approved a message or delegated authentication or authority for both online and offline system components, authorizations, and other critical data items and settings.

[0238] In another alternative embodiment, the identity and authorization (and potentially other classes or subclasses) of system components may be separate entities represented as certificates, with each class and / or subclass (e.g., identity and authorization) having a different certification authority. For example, each entity may have a separate authentication and authorization tree. In one embodiment, the authentication and authorization certification authorities may reside on different servers.

[0239] In an alternative embodiment, each class may use the same certificate authority. In another alternative embodiment, attribute (authorization) certificates (RFC5755) may be used to represent authorizations or other information, such as configuration parameters or identifiers. XII. Distributed Key Systems

[0240] There are multiple encryption keys distributed to the system components in the system 100 so that each system component can authenticate each other and distribute data privately and securely so that the data is accessible to the components (presumably only to those components that are deemed to need the data). The data can be communicated online and / or offline. Distribution of keys or identifiers according to one embodiment is illustrated in FIGS. 11A-B, which includes multiple system components and the encryption keys (and some identifiers) that they possess. Additionally, the illustrated embodiment of FIG. 16 also illustrates the system 100 with each system component and only the private / symmetric encryption key that it possesses. Each of the encryption keys according to one or more embodiments is described in more detail below. A. SCM-Key and SCM-ID

[0241] The SCM-Key key can uniquely identify a particular SCM 120. The SCM-Key key can be an asymmetric private / public key pair that is generated and stored either directly by the SCM 120 or only during the manufacturing process by a manufacturing tool. The SCM-Key private key can be securely stored in a secure memory 220 or secure element at the SCM 120, including a secure hardware module such as a secure enclave or a hardware security module (HSM).

[0242] The SCM-Key private key is not transmitted to other system components, whereas the SCM-Key public key may be securely transmitted and stored in system components that utilize the SCM-Key public key, such as device 110 or cloud 130. The SCM-Key private key may be used by the SCM 120 to encrypt and / or sign messages sent by the SCM 120 to other system components, and may be used to decrypt and / or verify messages sent to the SCM 120 from other system components. The SCM-Key public key may be used by system components to decrypt and / or verify messages originating from a particular SCM 120, and may be used to encrypt and / or sign messages directed to a particular SCM 120.

[0243] In one embodiment, the SCM-ED may serve a different but related purpose compared to the SCM-Key key. The SCM-ED may be considered unique to a particular SCM 120. However, the SCM-ED may not directly participate in the security model of the system 100. The SCM-ED may be relatively small in size compared to the SCM-Key key in terms of storage and / or representation (e.g., 32 or 64 bits vs. 256 bits). The SCM-ED may be transferred through the system 100 to and used by other system components to assist the user 10 in identifying the SCM 120. As a result, the SCM-ID may be transferred and stored in a secure manner. The SCM-ED may be stored (cached) in other system components, such as the device 110 and the cloud 130, to further assist the user 10 or other system services in identifying the SCM 120.

[0244] Because changes to the SCM-ED are not expected, system components may report the changes to users 10 as a security anomaly, such as an indication of tampering, a spoofing attempt, or a protocol violation. Changes may instead be reported to owners 10 of the SCM 120 as an indication of a product failure, such as memory corruption.

[0245] The SCM-ED may be a randomly generated identifier used solely for identification of the SCM 120, or the SCM-ED may serve other purposes as well. One example of such another purpose is to act as a media access control (MAC) address and / or a communication protocol identifier, such as a Global / Universal Unique Identifier (GUED / UUED) shared with other services, including, for example, Bluetooth Low Energy (BLE). Another example purpose of the SCM-ID is as a human / machine readable identifier, such as a serial number, Manufacturer Part Number (MPN), Universal Product Code (UPC), International / European Article Number (EAN), Vehicle Identification Number (VEST), or any other identifier unique to a particular SCM 120.

[0246] In alternative embodiments, the SCM-ED may not be specific to a particular SCM 120. Examples of non-specific types of SCM-ED include an International Standard Book Number (ISBN), a USB device identifier, and a product model, class, or type.

[0247] In one embodiment, the SCM-ED may not be stored securely. For example, secure storage may not be used because the SCM-ED is used only for logging or reporting purposes, or as an additional piece of identity information that is not relied upon by any system component. In yet another alternative embodiment, the SCM-ED may not exist.

[0248] In one embodiment, there may be multiple identifiers similar to the SCM-ID, each of which may or may not be unique to a particular SCM 120. For example, an SCM 120 may include one or more cellular identifiers, including a random internal SCM-ID, an externally visible serial number, an Ethernet MAC, a BLEUUID, an Electronic Serial Number (ESN) and an International Mobile Station Equipment Identity (IMEI), and / or a Mobile Equipment Identifier (MEED).

[0249] In an alternative embodiment, the SCM-Key may be shared across all SCMs 120 in use.

[0250] In one embodiment, the SCM-Key public key may not be securely transmitted and / or stored to the system components that utilize it.

[0251] In one embodiment, the SCM-Key private key is not stored in secure memory 220 or a secure element or equivalent hardware module, but is still securely stored. For example, the SCM-Key private key may be encrypted at rest, software-based and / or hardware-based measures may be implemented, or hardware and / or physical barriers or shields may be implemented, to prevent access to such data. JTAG and other ports may be disabled. Hardened software interfaces may be implemented to eliminate attack vectors. A trusted execution environment, hardware or software, may be instituted, and a detection system may be implemented to detect the onset of operating system root access or security breaches. In another embodiment, the SCM-Key private key is not securely stored.

[0252] In one embodiment, the SCM-Key public / private keys may be changed and / or generated as a result of a key rotation or a factory reset.

[0253] In one embodiment, one or more certificates may be used as the SCM-Key. In another embodiment, the SCM-Key is a symmetric key. In another alternative embodiment, the SCM-Key is an OAuth2 token. In yet another alternative embodiment, another authentication key or token type and / or challenge / response mechanism may be used in place of the SCM-Key.

[0254] In an alternative embodiment, one or more SCM-Key keys may be created and stored in SCM 120 for later use. This approach may be useful if SCM 120 does not have the ability to generate such keys during normal operation. In one embodiment, multiple keys may be utilized so that SCM 120 can support key rotation and / or different keys after a factory reset. In this embodiment, SCM 120 can manage which SCM-Key keys are available but not in use, in use, retired, or retired. Alternatively, SCM-Key keys may be generated by cloud 130 (or other system components) and stored in SCM 120 during normal operation, such as on-demand (one at a time) or in batches (for use at a later time as described herein).

[0255] In one embodiment, the SCM-Key key does not exist, in which case other means may be used for system components to communicate with SCM 120 and / or verify the authenticity of SCM 120. B. Equipment-Key

[0256] The Equipment-Key key may or may not be utilized. It is intended for equipment manufacturers (OEMs) who wish to generate their own keys held by the SCM 120 to communicate with one or more equipment 140 systems. The SCM-Equipment-Key key is a reverse usage model (and is likely preferred).

[0257] The Equipment-Key can uniquely identify a particular device 140 to an attached SCM 120. The Equipment-Key may be an asymmetric private / public key pair that is generated only during the device manufacturing process, either directly by the device 140 or by a manufacturing tool. The Equipment-Key private key may be securely stored on the device, in secure memory 220 or in a secure element or equivalent hardware module, such as a secure enclave or hardware security module (HSM).

[0258] The Equipment-Key private key is not transmitted to other system components in the illustrated embodiment. The Equipment-Key public key may be securely transmitted and stored in system components that utilize the Equipment-Key public key, such as the SCM 120. The Equipment-Key public key may be transmitted to the SCM 120 (or other equipment) during manufacture of the equipment 140 or SCM 120 by a manufacturing tool. The Equipment-Key public key may be transmitted to the SCM 120 (or other equipment) by the equipment 140 or other system component over a communications link or physical medium. The Equipment-Key private key may be used by a particular equipment 140 to encrypt and / or sign messages that the equipment 140 sends to other system components, and to decrypt and / or verify messages sent to the equipment 140 from other system components.

[0259] The Equipment-Key public key is used by system components to decrypt and / or verify messages that originate from a particular device 140, and may be used to encrypt and / or sign messages that are intended for a particular device 140.

[0260] In an alternative embodiment, the Equipment-Key public key is not securely transmitted and / or stored to the system components that utilize the Equipment-Key public key.

[0261] The Equipment-Key public key in one embodiment may be sent (or accepted) to a system component, such as SCM 120, only if the system component does not already have the Equipment-Key public key stored. This may occur at manufacturing time or following a factory reset. Additionally or alternatively, the Equipment-Key public key may only be sent to another system component by a manufacturing tool. In an alternative embodiment, the Equipment-Key public key may not be sent to another system component by a manufacturing tool.

[0262] In an alternative embodiment, the Equipment-Key may be shared across all equipment 140 in use.

[0263] In one embodiment, the Equipment-Key public key may not be transmitted to and / or used by a system component without approval by one or more other system components. For example, the SCM 120 may not communicate with a particular equipment 140 without approval from the device 110, the user 10, or the cloud 130. Additionally or alternatively, the equipment 140 may not approve itself.

[0264] The Equipment-Key private key of one embodiment is not stored in secure memory 220 or a secure element or equivalent hardware module. However, the Equipment-Key private key may still be securely stored. For example, the Equipment-Key private key may be encrypted at rest, software-based and / or hardware-based measures may be implemented, or hardware and / or physical barriers or shields may be implemented to prevent access to such data. JTAG and other ports may be disabled. Hardened software interfaces may be implemented to eliminate attack vectors. A trusted execution environment, hardware or software, may be instituted, and a detection system may be implemented to detect the onset of operating system root access or security breaches. In another embodiment, the Equipment-Key private key is not securely stored.

[0265] In one embodiment, the Equipment-Key public / private keys may be changed and / or generated as a result of a key rotation or a factory reset.

[0266] In one embodiment, one or more certificates may be used for the Equipment-Key key. In an alternative embodiment, the Equipment-Key key is a symmetric key. In another alternative embodiment, the Equipment-Key key is an OAuth2 token. In yet another alternative embodiment, a different authentication key or token type and / or challenge / response mechanism is used in place of the Equipment-Key key.

[0267] In one embodiment, a system component, including SCM 120, may communicate with multiple equipment 140 and, as a result, the system component may possess multiple different Equipment-Key public keys.

[0268] In one embodiment, the Equipment-Key key may not be present, in which case other means may be used for the SCM to communicate with the equipment 140 and / or verify authenticity. C.SCM-Equipment-Key

[0269] The SCM-Equipment-Key key may or may not be used. It is intended for equipment manufacturers who wish to use an externally generated key provided by the SCM 120 to communicate with one or more equipment 140 systems. The Equipment-Key key is a reverse usage model.

[0270] The SCM-Equipment-Key key can uniquely identify the SCM 120 to the attached equipment 140. The SCM-Equipment-Key key can be an asymmetric private / public key pair that is generated and stored either directly by the SCM 120 or by a manufacturing tool only during the manufacturing process.

[0271] The SCM-Equipment-Key key may be separate from the SCM-Key key to allow equipment manufacturers to use any security model they deem desirable, including a model in which they deem equipment 140 to be insufficiently protected and therefore prefer not to even reveal the SCM-Key public key.

[0272] The SCM-Equipment-Key private key may be securely stored in the SCM 120, in secure memory 220, or in a secure element or equivalent hardware module, such as a secure enclave or hardware security module (HSM). The SCM-Equipment-Key private key is not transmitted to other system components in the illustrated embodiment of Figure 11. Furthermore, in the illustrated embodiment, the SCM-Equipment-Key public key may be transmitted and stored only on the installed equipment 140, via a manufacturing tool, a communications link, or a physical medium.

[0273] The SCM-Equipment-Key private key may be used by SCM 120 to encrypt and / or sign messages that it sends to device 140, and to decrypt and verify messages sent from device 140 to SCM 120. The SCM-Equipment-Key public key may be used by device 140 to decrypt and / or verify messages originating from a particular SCM 120, and to encrypt and / or sign messages intended for a particular SCM 120.

[0274] In one embodiment, the SCM-Equipment-Key public key may be securely transmitted to and stored in a system component other than the attached equipment 140, including, for example, the device 110, the cloud 130, or the SCM 120, or a combination thereof.

[0275] In one embodiment, the SCM-Equipment-Key public key may not be securely transmitted or stored in the system components.

[0276] There may be one or more instruments 140 attached to a particular SCM 120. In this manner, the system 100 may define a one-SCM multi-instrument system in which a device 110 may obtain status for, issue commands to, and / or receive responses from, individual instruments 140 or any combination thereof.

[0277] An SCM-Equipment-Key that is shared across all or part of the SCM in use may be implemented according to one embodiment.

[0278] In one embodiment, the SCM-Equipment-Key public key may not be accepted by a system component (eg, device 140) if the system component already has an Equipment-Key public key stored.

[0279] In one embodiment, the SCM-Equipment-Key public key may not be transmitted to and / or used by equipment 140 without approval by one or more other system components. For example, equipment 140 may not communicate with a particular SCM 120 without approval from device 110, user 10, or cloud 130. Additionally or alternatively, SCM 120 may not approve itself.

[0280] In one embodiment, instead of using the SCM-Equipment-Key, an SCM-Key may be utilized, in which case the various specified SCM-Equipment-Key operations may also be applied to the SCM-Key.

[0281] In one embodiment, the SCM-Equipment-Key private key is not stored in secure memory 220 or a secure element or equivalent hardware module. The SCM-Equipment-Key private key may still be securely stored. For example, the SCM-Equipment-Key private key may be encrypted at rest, and software-based and / or hardware-based measures may be implemented, or hardware and / or physical barriers or shields may be implemented, to prevent access to such data. JTAG and other ports may be disabled. Hardened software interfaces may be implemented to eliminate attack vectors. A trusted execution environment, hardware or software, may be instituted, and a detection system may be implemented to detect the onset of operating system root access or security breaches. In an alternative embodiment, the SCM-Equipment-Key private key is not securely stored.

[0282] In one embodiment, the SCM-Equipment-Key public key is not securely stored by the system components that utilize it.

[0283] The SCM-Equipment-Key public / private keys may be changed and / or generated as a result of a key rotation or factory reset according to one embodiment of the present disclosure.

[0284] Multiple system components (eg, equipment 140) may communicate with a single SCM 120 and multiple SCM-Equipment-Key public / private key pairs may be utilized.

[0285] One or more certificates may be used for the SCM-Equipment-Key. Alternatively, the SCM-Equipment-Key may be a symmetric key. In another alternative embodiment, the SCM-Equipment-Key may be an OAuth2 token. In yet another alternative embodiment, another authentication key or token type and / or challenge / response mechanism may be used in place of the SCM-Equipment-Key.

[0286] In an alternative embodiment, one or more SCM-Equipment-Key keys may be created and stored in SCM 120 for later use. This approach may be useful if SCM 120 does not have the ability to generate such keys during normal operation. In one embodiment, multiple keys may be utilized so that SCM 120 can support key rotation and / or different keys after a factory reset. In this embodiment, SCM 120 can manage which SCM-Equipment-Key keys are available but not in use, in use, retired, or retired. Alternatively, SCM-Equipment-Key keys may be generated by cloud 130 (or other system components) and stored in SCM 120 during normal operation, such as on-demand (one at a time) or in batches (for use at a later time as described herein).

[0287] In one embodiment, the SCM-Equipment-Key key is not present, in which case other means may be used for equipment to communicate with the SCM 120 and / or verify the authenticity of the SCM 120 . D. Device-SCM-Key, Device-ID, and Device-SCM-ID

[0288] The Device-SCM-Key key can uniquely identify a particular pairing (Device / SCM pair) between the device 110 and the SCM 120. The Device-SCM-Key key in the illustrated embodiment is an asymmetric private / public key pair that is generated and stored by the device 110. The Device-SCM-Key key may be generated when the cloud 130 requests to issue an authorization to the device 110 for a new SCM 120, such as an SCM 120 for which the device 110 has not been issued an authorization. The Device-SCM-Key key may also be generated when the device 110 is requesting to become the owner of a factory-reset SCM 120 or when transferring ownership, such as during manufacturing.

[0289] This approach can limit exposure of each compromised Device-SCM-Key to a single SCM 120, so that a substantially unique Device-SCM-Key can be used for each device / SCM pair, as opposed to exposure to all SCMs 120 associated with a particular device 110, as would be the case if a single key were used (e.g., with a Device-Key) for all SCMs 120 associated with a particular device 110.

[0290] The Device-SCM-Key private key of an embodiment may be securely stored at device 110 in secure memory 220 or in a secure element or equivalent hardware module, such as a secure enclave or hardware security module (HSM). The Device-SCM-Key private key may not be transmitted to other system components, while the Device-SCM-Key public key may be securely transmitted and stored in system components that utilize the Device-SCM-Key public key, such as cloud 130.

[0291] The Device-SCM-Key private key may be used by the device 110 to encrypt and / or sign messages for the associated SCM 120 and may be used to decrypt and / or verify messages sent from the associated SCM 120 to the device 110, which may or may not be sent directly to the device 110, such as during the process of issuing an authorization or when the owner device 110 signs an ACP 400 for the associated SCM 120 and sends the signed ACP 400 to the cloud 130. The Device-SCM-Key public key may be used by the SCM 120 to decrypt and / or verify messages originating from the associated device 110 and may be used to encrypt and / or sign messages from the SCM 120 destined for the associated device 110.

[0292] The Device-ID may serve a different but related purpose compared to the Device-SCM-Key key. The Device-ID is substantially unique to a particular device 110 (rather than to a particular device / SCM pair) and may be generated by the cloud 130. The Device-ID may not directly participate in the security model of the system 100. The Device-ID may be relatively small in size, in terms of storage and / or representation (e.g., 32 or 64 bits vs. 256 bits), compared to the Device-SCM-Key key. The Device-ID may be transferred to and used by other system components (such as the cloud 130, the SCM 120, and the user 10) via the system 100 to help identify the device 110 and enable device-specific services. Examples of device-specific services include SMS and push notifications. As a result, efforts may be made to ensure that the Device-ID is securely transferred and stored.

[0293] Although Device-ID changes are not expected, some system components may be able to report changes to the device owner 10 as a security anomaly or product failure. A security anomaly may be the result of tampering, a spoofing attempt, or a protocol violation. A product failure may result from memory corruption, since a given device 110 may cycle through many unique Device-IDs throughout its product life, as applications are removed and reinstalled, memory is wiped, or upgraded, even for the same physical device 110.

[0294] The Device-ID may be a randomly generated identifier used purely for device identification. Alternatively, the Device-ID may serve other purposes. One example of such another purpose is to act as a communication protocol identifier, such as a Media Access Control (MAC) address, a Global / Universal Unique Identifier (GUED / UUED) shared with other services including Bluetooth Low Energy (BLE). Another example purpose of the Device-ID is as a human / machine readable identifier, such as a serial number, Manufacturer Part Number (MPN), Universal Product Code (UPC), International / European Article Number (EAN), Vehicle Identification Number (VEST), a user-defined string, or any other identifier unique to a particular device 110.

[0295] In alternative embodiments, the Device-ID may not be unique to a particular device 110. Examples of non-unique types of Device-IDs include an International Standard Book Number (ISBN), a USB device identifier, and a product model, class, or type.

[0296] In one embodiment, the Device-ID may not be stored securely, for example, the Device-ID may only be used for logging or reporting purposes or as a piece of additional identification information that is not relied upon by any system component, and therefore secure storage may not be utilized.

[0297] It should be understood that in one or more embodiments, the Device-ID may not be present or utilized.

[0298] In an alternative embodiment, the Device-ID may be generated by the device 110 .

[0299] In one embodiment, there may be multiple identifiers similar to the Device-ID, and each identifier may or may not be unique to a particular device 110. For example, a device 110 may include a random internal Device-ID, an externally visible serial number, an Ethernet MAC, a BLEUUID, an Electronic Serial Number (ESN) and an International Mobile Station Equipment Identity (IMEI), and / or a cellular identifier including a Mobile Equipment Identifier (MEED), a device name, or a user identifier, or any combination thereof.

[0300] The Device-SCM-ED may be similar to the Device-ED, but in the illustrated embodiment, the Device-SCM-ED is intended for use with constrained devices and / or constrained bandwidth interfaces. The Device-SCM-ED, in one embodiment, may be substantially unique to a particular device / SCM pair, may be generated by the cloud 130, and does not directly participate in the security model of the system 100. The Device-SCM-ED may be relatively small in size in terms of storage and / or representation (e.g., 8 or 16 bits vs. 32 or 64 bits) compared to the Device-ED.

[0301] The Device-SCM-ED may be transferred through system 100 to and used by other system components, such as cloud 130, device 110, and SCM 120, to assist in establishing a secure communication channel between device 110 and SCM 120. In one embodiment, the Device-SCM-ED may be stored only in cloud 130 such that it may be distributed within ACP 400 and / or ACP container 410. The Device-SCM-ID may not be transferred or stored securely in some cases.

[0302] Changes in the Device-SCM-ED are not expected. As a result, some system components may be able to report changes to the Device Owner 10 as security anomalies or product failures. Security anomalies may be the result of tampering, spoofing attempts, or protocol violations. Product failures may result from memory corruption, as a given device 110 may cycle through many unique Device-SCM-IDs throughout its product life, as applications are removed and reinstalled, memory is wiped, or upgraded, even for the same physical device 110.

[0303] In one embodiment, the Device-SCM-ED may be a small randomly generated identifier used purely for device identification and may be unique within the environment of a particular SCM 120. Alternatively, the Device-SCM-ED may not exist.

[0304] The Device-SCM-ED, in one embodiment, may be generated by the device 110. In some cases, there are multiple identifiers similar to the Device-SCM-ED, where each of the identifiers may or may not be unique to a particular device 110. For example, the device 110 may include other small random identifiers.

[0305] In one embodiment, the Device-Key may be unique to only the particular device 110 in use, instead of the Device-SCM-Key. In this embodiment, the Device-Key may be generated during the registration process of the device 110. Alternatively, the Device-Key may be shared across all devices 110 in use, instead of the Device-SCM-Key.

[0306] In one embodiment, the Device-SCM-Key public key may not be securely transmitted to and / or stored in system components that utilize the Device-SCM-Key public key.

[0307] The Device-SCM-Key private key may not be stored in secure memory 220 or a secure element or equivalent hardware module. However, the Device-SCM-Key private key may still be securely stored. For example, secure storage without secure memory 220 may be achieved by one or more of: the Device-SCM-Key private key may be encrypted at rest; software-based and / or hardware-based measures may be implemented to prevent access to such data; and hardware and / or physical barriers or shields may be implemented. JTAG and other ports may be disabled. Hardened software interfaces may be implemented to eliminate attack vectors. A trusted execution environment, hardware or software, may be instituted and a detection system implemented to detect the onset of operating system root access or security breaches. In alternative embodiments, the Device-SCM-Key private key is not securely stored.

[0308] In one embodiment, the Device-SCM-Key public / private keys may be changed and / or generated as a result of a key rotation or a factory reset.

[0309] In one embodiment, one or more certificates may be used for the Device-SCM-Key. Alternatively, the Device-SCM-Key may be a symmetric key. In another alternative embodiment, the Device-SCM-Key may be an OAuth2 token. In yet another alternative embodiment, another authentication key or token type and / or challenge / response mechanism may be used in place of the Device-SCM-Key.

[0310] One or more Device-SCM-Key keys may be created and stored on the device 110 for later use. This approach may be useful if the device 110 does not have the ability to generate such keys during normal operation. In one embodiment, multiple keys may be utilized so that the device 110 can support key rotation and / or different keys after a factory reset. In this embodiment, the device 110 can manage which Device-SCM-Key keys are available but not in use, in use, retired, or retired. Alternatively, Device-SCM-Key keys may be generated by the cloud 130 (or another system component) and stored on the device 110 during normal operation, such as on-demand (one at a time) or in batches (for use at a later time as described herein).

[0311] In one embodiment, the Device-SCM-Key key may not be present, in which case other means may be used for system components to communicate with the device 110 and / or verify the authenticity of the device 110. E. User-SCM-Key and User-SCM-ID

[0312] In one embodiment, the User-SCM-Key key can uniquely identify a particular pairing between a user account and an SCM 120 (a user account / SCM pair). The User-SCM-Key key in the illustrated embodiment is an asymmetric private / public key pair that is generated and stored by a user account service in the cloud 130. The User-SCM-Key key may be generated when the cloud 130 requests that an authorization be issued to a device 110 associated with the user's user account for a new SCM 120, such as an SCM 120 for which the user account has not been issued authorization. The User-SCM-Key key may also be generated when a device 110 associated with the user's user account requests to become the owner of a factory-reset SCM 120, such as during manufacturing, or when transferring ownership. The User-SCM-Key is used by at least the user account service to sign the ACP 400 (and by the SCM 120 to decrypt and verify that the ACP container 410 has been approved).

[0313] This approach can limit exposure of each compromised User-SCM-Key key to a single SCM 120, so that a substantially unique User-SCM-Key key can be used for each user account / SCM pair, as opposed to exposure to all SCMs 120 associated with a particular user account, as would be the case if a single key were used (e.g., with User-Key) for all SCMs 120 associated with a particular user account.

[0314] The User-SCM-Key private key in one embodiment may be securely stored by a user account service in cloud 130. The User-SCM-Key private key may not be transmitted to other system components, while the User-SCM-Key public key may be securely transmitted and stored in system components that utilize the User-SCM-Key public key, such as SCM 120.

[0315] The User-SCM-Key private key may be used by the user account service to encrypt and / or sign messages to the associated SCM 120, and may be used to decrypt and / or verify messages sent to the user account service from the associated SCM 120. The User-SCM-Key public key may be used by the SCM 120 to decrypt and / or verify messages originating from the user account service, and may be used to encrypt and / or sign messages from the SCM 120 to the user account service.

[0316] In one embodiment, a User-SCM-Key may be used instead of a Device-SCM-Key, in which all devices 110 associated with a user account may use the same User-SCM-Key (instead of individual Device-SCM-Key keys).

[0317] In one embodiment, both the User-SCM-Key and Device-SCM-Key keys are used, in which, for example, the ACP outer layer 2 of ACP 400 may be signed using the User-SCM-Key key, but device 110 is individually authenticated using the Device-SCM-Key key.

[0318] In one embodiment, the User-Key key may be unique to only a particular user account, instead of the User-SCM-Key key. In this embodiment, the User-Key may be generated during the user account creation process. Alternatively, the User-Key key may be shared across all devices 110 associated with that user's user account, instead of the User-SCM-Key key.

[0319] In one embodiment, the User-SCM-Key public key may not be securely transmitted to and / or stored in system components that utilize the User-SCM-Key public key.

[0320] The User-SCM-Key private key may not be stored in secure memory 220 or a secure element or equivalent hardware module. However, the User-SCM-Key private key may still be securely stored. For example, secure storage without secure memory 220 may be achieved by one or more of the following: the User-SCM-Key private key may be encrypted at rest, software-based and / or hardware-based measures may be implemented to prevent access to such data, and hardware and / or physical barriers or shields may be implemented. JTAG and other ports may be disabled. Hardened software interfaces may be implemented to eliminate attack vectors. A trusted execution environment, hardware or software, may be instituted and a detection system implemented to detect the onset of operating system root access or security breaches. In an alternative embodiment, the User-SCM-Key private key is not securely stored.

[0321] In one embodiment, the User-SCM-Key public / private keys may be changed and / or generated as a result of a key rotation or a factory reset.

[0322] In one embodiment, one or more certificates may be used for the User-SCM-Key. Alternatively, the User-SCM-Key may be a symmetric key. In another alternative embodiment, the User-SCM-Key may be an OAuth2 token. In yet another alternative embodiment, another authentication key or token type and / or challenge / response mechanism is used in place of the User-SCM-Key.

[0323] In one embodiment, one or more User-SCM-Key keys may be created and stored by a user account service of the cloud 130 for a particular SCM 120 (or for all SCMs 120 as a global key pool) for later use. This approach may avoid having the user account service of the cloud 130 generate such keys during normal operation. Multiple keys may be utilized so that the user account service of the cloud 130 can support key rotation and / or multiple SCMs 120. In this embodiment, the user account service of the cloud 130 can manage which User-SCM-Key keys are available but not in use, in use, or retired or retired.

[0324] In one embodiment, the User-SCM-Key key may not be present, in which case other means may be used for system components to communicate with and / or verify the authenticity of the user account service.

[0325] In one embodiment, the User-SCM-ID may be used similar to the Device-SCM-ID. F.Cloud-SCM-Key and Cloud-SCM-Approval-Key

[0326] The Cloud-SCM-Key can uniquely identify a particular pairing (i.e., a Cloud / SCM pair) between the SCM 120 and the cloud 130. The Cloud-SCM-Key in the illustrated embodiment can be an asymmetric private / public key pair that is generated and stored by the cloud 130. The Cloud-SCM-Key can be generated when the initial owner device 110 is established with the SCM 120 after a factory reset, such as during manufacturing, or when transferring ownership.

[0327] A substantially unique Cloud-SCM-Key may be used for each cloud / SCM pair. This approach may substantially limit exposure of a compromised Cloud-SCM-Key to a single SCM 120, as opposed to all SCMs 120 associated with a particular cloud 130, as would be the case if a single key were used (e.g., with a Cloud-Key) for all SCMs 120 associated with a particular cloud 130.

[0328] The Cloud-SCM-Key private key may be securely stored in the secure memory 220 of the cloud 130 or in a secure element or equivalent hardware module, such as a secure enclave or hardware security module (HSM). The Cloud-SCM-Key private key may not be transmitted to other system components. The Cloud-SCM-Key public key may be securely transmitted and stored in a system component that utilizes the Cloud-SCM-Key public key, such as the cloud 130, the device 110, or the SCM 120. The Cloud-SCM-Key private key may be used by the cloud 130 to encrypt and / or sign messages for the associated SCM 120 and may be used to decrypt and / or verify messages sent from the associated SCM 120 to the cloud 130. The Cloud-SCM-Key public key may be used by the SCM 120 to decrypt and / or verify messages originating from the cloud 130 and may be used to encrypt and / or sign messages from the SCM 120 to the cloud 130. The message may or may not be sent directly to SCM 120. For example, during the process of issuing an authorization, the signed ACP 400 may be sent to owner device 110 for approval. After approval, cloud 130 may sign the completed ACP container 410 (including the previously signed ACP 400) that is delivered to SCM 120 via device 110.

[0329] In one embodiment, multiple Cloud-SCM-Keys may be utilized, such as one or more Cloud-SCM-Keys for different services in cloud 130. For example, there may be one Cloud-SCM-Key for a cloud authorization request service and another Cloud-SCM-Approval-Key for a cloud authorization approval service, as previously described herein.

[0330] In one embodiment, there may be a Cloud-ID (similar to a Device-ID) for each cloud 130 and / or cloud service.

[0331] In one embodiment, the Cloud-Key may be unique only to a particular cloud 130 and / or cloud service, instead of a Cloud-SCM-Key, in which case the Cloud-Key may be generated during provisioning and / or initial setup of the cloud 130.

[0332] In one embodiment, the Cloud-SCM-Key public key may not be securely transmitted and / or stored to system components that utilize the Cloud-SCM-Key public key.

[0333] The Cloud-SCM-Key private key may not be stored in secure memory 220 or a secure element or equivalent hardware module. However, the Cloud-SCM-Key private key may still be securely stored. For example, secure storage without secure memory 220 may be achieved by one or more of the following: the Cloud-SCM-Key private key may be encrypted at rest, software-based and / or hardware-based measures may be implemented to prevent access to such data, and hardware and / or physical barriers or shields may be implemented. JTAG and other ports may be disabled. Hardened software interfaces may be implemented to eliminate attack vectors. A trusted execution environment, hardware or software, may be instituted and a detection system implemented to detect the onset of operating system root access or security breaches. In alternative embodiments, the Cloud-SCM-Key private key is not securely stored.

[0334] In one embodiment, the Cloud-SCM-Key public / private keys may be changed and / or generated as a result of key rotation. The Cloud-SCM-Key public / private keys cannot be changed as a result of a factory reset.

[0335] In one embodiment, one or more certificates may be used for the Cloud-SCM-Key. Alternatively, the Cloud-SCM-Key may be a symmetric key. In another alternative embodiment, the Cloud-SCM-Key is an OAuth2 token. In yet another alternative embodiment, an alternative authentication key or token type and / or challenge / response mechanism may be used in place of the Cloud-SCM-Key.

[0336] In one embodiment, one or more Cloud-SCM-Key keys may be created and stored in the cloud 130 for a particular SCM 120 (or for all SCMs 120 as a global key pool) for later use. This approach may avoid having the cloud 130 generate such keys during normal operation. Multiple keys may be utilized so that the cloud 130 can rotate keys and / or support multiple SCMs 120. In this embodiment, the cloud 130 may manage which Cloud-SCM-Key keys are available but not in use, in use, retired, or retired.

[0337] In one embodiment, the Cloud-SCM-Key key may not exist, in which case other means may be used for system components to communicate with cloud 130 and / or verify the authenticity of cloud 130. G.Root-Cert

[0338] The Root-Cert may be a root certificate of the system 100 according to one embodiment. The Root-Cert may be a self-signed certificate that establishes the root of trust for the system 100. The private Root-Cert may be offline or securely stored on a server that is not generally accessible to the cloud 130 or other system components. The public Root-Cert may be distributed to the cloud 130 and each system component that may communicate with the cloud 130, such as the device 110 or the OEM cloud 135.

[0339] In one embodiment, the Root-Cert may be signed by a certificate authority.

[0340] In one embodiment, there may be multiple Root-Certs. For example, there may be Root-Certs for different instances of the system 100, the cloud 130, the cloud service or device 110, and the OEM cloud 135, or any combination thereof. Each of the multiple Root-Certs may be self-signed or signed by a certificate authority. In one example, the system 100 may be configured with one root of trust for online validation and another for offline validation.

[0341] In some cases, storing the Root-Cert offline is not strictly necessary, so in one embodiment the Root-Cert may be stored on an online server.

[0342] The contents and / or creation process of the Root-Cert may vary from application to application. In one embodiment, the Root-Cert may be an asymmetric public / private key pair or the Root-Cert may be a symmetric key. H. Cloud-Node-Cert

[0343] The Cloud-Node-Cert in the illustrated embodiment is a certificate signed by the private Root-Cert of the corresponding system 100. Each Cloud-Node-Cert can therefore form part of a chain of trust for verifying the identity of a particular cloud server 130. The private Cloud-Node-Cert may be securely stored on each cloud server 130. The public Cloud-Node-Cert may be distributed to the cloud 130 and each system component that may communicate with the cloud 130, including, for example, the device 110 and the OEM cloud 135. If any other encryption keys are embodied as certificates rather than encryption keys, these certificates may be signed by the Root-Cert or Cloud-Node-Cert, or an alternative root of trust certificate.

[0344] In one embodiment, there may be multiple layers of Cloud-Node-Cert, such as layers for different instances and / or clusters of system 100, cloud 130, cloud service, device 110, or OEM cloud 135, or any combination thereof. Each child Cloud-Node-Cert (i.e., lower level) may be signed by its parent, or higher level, private Cloud-Node-Cert, thereby forming a longer chain of trust.

[0345] The Cloud-Node-Cert can be signed in a variety of ways, for example, the Cloud-Node-Cert may be self-signed in one embodiment, or the Cloud-Node-Cert may be signed by a non-parent certificate or an asymmetric private / public key.

[0346] In one embodiment, the Cloud-Node-Cert is an asymmetric public / private key pair. Alternatively, the Cloud-Node-Cert may be a symmetric key. I.Device-Rights-Key

[0347] The Device-Rights-Key key can uniquely identify a particular device 110 to the rights management system of the cloud 130. The Device-Rights-Key key can be an asymmetric private / public key pair that is generated and stored by the device 110 at some point before the device 110 is initially registered with the cloud 130. The Device-Rights-Key private key can be securely stored in the secure memory 220 within the device 110, or in a secure element or equivalent hardware module, such as a secure enclave or hardware security module (HSM). The Device-Rights-Key private key may not be transmitted to other system components. On the other hand, the Device-Rights-Key public key can be securely transmitted and stored in system components that utilize the Device-Rights-Key public key, such as the cloud 130.

[0348] The Device-Rights-Key private key may be used by the device 110 to encrypt and / or sign messages that the device 110 sends to the rights management system of the cloud 130, and may be used to decrypt and / or verify messages sent to the device from the rights management system of the cloud 130. The Device-Rights-Key public key may be used by the rights management system of the cloud 130 to decrypt and / or verify messages originating from a particular device 110, and may be used to encrypt and / or sign messages destined for a particular device 110.

[0349] In one embodiment, a Device-Rights-Key key may not be substantially unique per device 110. Examples of such configurations include a Device-Rights-Key key that is substantially unique per account, that is used for certain devices 110 within an account, or that is the same globally for all devices 110 or that is unique only to a particular rights management system in the cloud 130. Another example of a Device-Rights-Key key that is not substantially unique per device is a Device-Rights-Key key that is used for all devices 110 owned by a particular organization.

[0350] In one embodiment, the Device-Rights-Key may be generated by the cloud 130 and delivered to the device 110 as part of the device 110 registration process.

[0351] In one embodiment, a Device-Rights-ID (similar to a Device-ID) may be associated with each device 110 for use with the rights management system of the cloud 130 .

[0352] In one embodiment, the Device-Rights-Key public key is not securely transmitted and / or stored to system components that utilize the Device-Rights-Key public key.

[0353] The Device-Rights-Key private key may not be stored in secure memory 220 or a secure element or equivalent hardware module. However, the Device-Rights-Key private key may still be securely stored. For example, secure storage without secure memory 220 may be achieved by one or more of: the Device-Rights-Key private key may be encrypted at rest; software-based and / or hardware-based measures may be implemented to prevent access to such data; and hardware and / or physical barriers or shields may be implemented. JTAG and other ports may be disabled. Hardened software interfaces may be implemented to eliminate attack vectors. A trusted execution environment, hardware or software, may be instituted and a detection system implemented to detect the onset of operating system root access or security breaches. In an alternative embodiment, the Device-Rights-Key private key is not securely stored.

[0354] In one embodiment, the Device-Rights-Key public / private keys may be changed and / or generated as a result of key rotation. The Device-Rights-Key public / private keys of one embodiment may not be changed as a result of a factory reset.

[0355] In one embodiment, one or more certificates may be used for the Device-Rights-Key. Alternatively, the Device-Rights-Key may be a symmetric key. In another alternative embodiment, the Device-Rights-Key may be an OAuth2 token. In yet another alternative embodiment, an alternative authentication key or token type and / or challenge / response mechanism may be used in place of the Device-Rights-Key.

[0356] One or more Device-Rights-Key keys may be created and stored on device 110 for later use. This approach may be useful if device 110 does not have the capability to generate such keys during normal operation. In one embodiment, multiple keys may be utilized so that device 110 can support different keys after key rotation and / or factory reset. In this embodiment, device 110 may manage which Device-Rights-Key keys are available but not in use, in use, retired, or retired. Alternatively, Device-Rights-Key keys may be generated by cloud 130 (or another system component) and stored on device 110 during normal operation, such as on-demand (one at a time) or in batches (for use at a later time as described herein).

[0357] In one embodiment, the Device-Rights-Key key may not be present, in which case an authorization type or some other means may be used to establish device rights, or some other means may be used to enable device 110 to communicate with and / or verify the authenticity of a rights management system in cloud 130. J.ACP-Version-Key

[0358] The ACP-Version-Key key can be used within the context of the ACP container version package 412 (a secure package that contains ACP version information) to uniquely identify a particular pairing (or cloud / SCM pair) between the cloud 130 and the SCM 120. The ACP-Version-Key key in the illustrated embodiment is an asymmetric private / public key pair that is generated and stored by the cloud 130 when the initial owner device 110 is established with the SCM 120, such as during manufacturing, after a factory reset, or when transferring ownership. In the illustrated embodiment, the ACP-Version-Key key may not be provided to the device 110.

[0359] A potentially unique ACP-Version-Key may be used for each cloud / SCM pair. This approach may effectively limit exposure of each compromised ACP-Version-Key to a single SCM 120, as opposed to all SCMs 120 associated with a particular cloud 130, as would be the case if a single key (e.g., with one ACP-Key) were used for all SCMs associated with a particular cloud 130.

[0360] The ACP-Version-Key private key may be securely stored in a secure element or equivalent hardware module, such as secure memory 220, secure enclave, or hardware security module (HSM) of cloud 130. The ACP-Version-Key private key may not be transmitted to other system components. Meanwhile, the ACP-Version-Key public key may be securely transmitted and stored to system components that utilize the ACP-Version-Key public key, such as SCM 120. The ACP-Version-Key private key may be used by cloud 130 to encrypt and / or sign messages for the associated SCM 120 and may be used to decrypt and / or verify messages sent from the associated SCM 120 to cloud 130. The ACP-Version-Key public key may be used by SCM 120 to decrypt and / or verify messages originating from the cloud and may be used to encrypt and / or sign messages from SCM 120 to cloud 130.

[0361] In one embodiment, the Cloud-SCM-Key may be used for the ACP-Version-Key.

[0362] In one embodiment, the ACP-Version-Key private key may be generated and managed in a manner similar to the SCM-Key, for example, the ACP-Version-Key private key may reside on SCM 120 and the public key may reside in cloud 130.

[0363] In an alternative embodiment, an ACP-Key key that is unique only to a particular cloud 130 may be implemented in place of the ACP-Version-Key key.

[0364] In one embodiment, the ACP-Version-Key public key may not be securely transmitted and / or stored to system components that utilize the ACP-Version-Key public key.

[0365] In one embodiment, the ACP-Version-Key private key may not be stored in secure memory 220 or a secure element or equivalent hardware module. However, the ACP-Version-Key private key may still be securely stored. For example, secure storage without secure memory 220 may be achieved by one or more of the following: the ACP-Version-Key private key may be encrypted at rest, software-based and / or hardware-based measures may be implemented to prevent access to such data, and hardware and / or physical barriers or shields may be implemented. JTAG and other ports may be disabled. Hardened software interfaces may be implemented to eliminate attack vectors. A trusted execution environment, hardware or software, may be instituted, and a detection system may be implemented to detect the onset of operating system root access or security breaches. In an alternative embodiment, the ACP-Version-Key private key is not securely stored.

[0366] In one embodiment, the ACP-Version-Key public / private keys may be changed and / or generated as a result of key rotation.

[0367] In one embodiment, the ACP-Version-Key public / private key may not be changed as a result of a factory reset.

[0368] One or more certificates may be used for the ACP-Version-Key. Alternatively, the ACP-Version-Key may be a symmetric key. In another alternative embodiment, the ACP-Version-Key may be an OAuth2 token. In yet another alternative embodiment, an alternative authentication key or token type and / or challenge / response mechanism may be used in place of the ACP-Version-Key.

[0369] In one embodiment, one or more ACP-Version-Key keys may be created and stored in cloud 130 for a particular SCM 120 (or for all SCMs 120 as a global key pool) for later use. This approach may avoid having cloud 130 generate such keys during normal operation. Multiple keys may be utilized so that cloud 130 can rotate keys and / or support multiple SCMs 120. In this embodiment, cloud 130 may manage which ACP-Version-Key keys are available but not in use, in use, or retired or retired.

[0370] In one embodiment, the ACP-Version-Key key may not be present, in which case other means may be used for the system component to communicate with and / or verify the authenticity of the ACP container version package 412. In one embodiment, the system component may not verify the authenticity of all of the ACP container version packages 412.

[0371] In one embodiment, there may be multiple ACP-Version-Key keys. For example, in a system where each SCM 120 can store and use more than one ACP 400, it may be necessary for a given SCM to receive multiple ACP containers 410 and / or multiple ACP container version packages 412 and / or multiple ACP container collections 414 that use multiple ACP-Version-Key keys. K.Device-SCM-Session-Key

[0372] The Device-SCM-Session-Key key may be a symmetric key used to protect communications between pairings (or device / SCM pairs) defined between a particular Device 110 and SCM 120 after at least one pair has been authenticated, such as by being authenticated in a manner similar to the TLS master secret. To improve system performance and responsiveness with constrained system components, the Device-SCM-Session-Key key may persist through a connection (such as in a manner similar to the continuation of a TLS session) or may be rotated periodically as described herein.

[0373] The Device-SCM-ED of a device in a Device / SCM pair may be used to identify and / or select the appropriate Device-SCM-Session-Key when establishing and / or resuming a connection.

[0374] In one embodiment, a Device-SCM-Session-ID (similar to Device-SCM-ED) may be provided to each device / SCM pair and used to identify and / or select the appropriate Device-SCM-Session-Key when establishing and / or resuming a connection. This may be done in a similar manner to a TLS Session ID or Session Ticket.

[0375] In one embodiment, the Device-SCM-Session-Key is an asymmetric key pair. Alternatively, the Device-SCM-Session-Key may be an OAuth2 token. In another alternative embodiment, an alternative authentication key or token type and / or challenge / response mechanism may be used in place of the Device-SCM-Session-Key.

[0376] In one embodiment, the Device-SCM-Session-Key key may not exist, in which case other means may be used for the device 110 and SCM 120 to communicate securely and / or the device 110 and SCM 120 may not communicate securely. L. Session Token

[0377] System components (e.g., device 110) communicating with cloud 130 and / or OEM cloud 135 may obtain an OEM cloud session token and / or cloud session token during an OEM cloud login process for use as an additional security measure. The OEM cloud session token may accompany all OEM cloud 135 messages, as well as any internal mappings to other data items managed by OEM cloud 135. The cloud session token may accompany all cloud 130 messages, which may be mapped to a specific Cloud-User-ED and OEM-ED, allowing cloud 130 to restrict access to data associated with the specific Cloud-User-ED and OEM-ED. OEM cloud 135 may use the Cloud-to-OEM cloud session token to communicate with cloud 130. The Cloud-to-OEM cloud session token may be similar to the cloud session token, except that the Cloud-to-OEM cloud session token may only restrict access to data associated with a specific OEM-ID.

[0378] Cloud 130 and OEM cloud 135 may rotate session tokens periodically so that the tokens expire. Rotation may occur under various circumstances or in response to events such as every login, when suspicious activity occurs, or when message validation fails.

[0379] The OEM cloud session token and the cloud session token may be the same in one embodiment. Alternatively, the OEM cloud session token may not be used. In alternative embodiments, the cloud session token may not be used. Additionally or alternatively, the Cloud-to-OEM cloud session token may not be used. M. Other Keys

[0380] Other keys may exist within system 100 that are dedicated to a purpose and / or are temporary. Examples of dedicated purpose are keys used within a particular message set or internally to a particular system component. Examples that are temporary include session keys used between other system components operating within the context of a standard security protocol such as TLS or DTLS. N. Users

[0381] In one embodiment, the user 10 may play a role in the system similar to a cryptographic key. The user 10 has the following potentially unique characteristics / features that can be incorporated as a cryptographic key to be used for authentication (or two-factor or multi-factor authentication) mechanisms or in connection with authorization gating by system components within the system 100: 1) Eyes and / or face (e.g., retina / facial key / signature, visual verification of receipts) 2) Fingerprint (e.g. fingerprint key / signature, Apple Touch ID, or other authentication information) 3) Email access (e.g., demonstrated access to an email account) 4) SMS access (e.g., demonstrated access to SMS messages) 5) Push notification access (e.g., demonstrated access to push notifications) 6) Screen access or code entry (e.g., demonstrated access to a device screen) 7) Proximity (e.g., proximity to system components based on micro-location or proximity based on IR detection) 8) Access (e.g., demonstrated physical access to system components, such as button pushes) 9) Proximity or access to other devices (e.g., other user devices such as watches or bands) XIII. Key circulation

[0382] Key rotation, also known as key rotation or key update, according to one embodiment, is a process in which keys are changed for existing objects without directly notifying users of the change or requiring user interaction. For example, keys for objects including authorizations, devices 110, SCM 120, cloud 130, equipment components 130, and OEM cloud 135 can be changed.

[0383] Keys may be rotated periodically, such as every few hours, daily, weekly, monthly, six months, or yearly, or when a compromise or anomaly is detected. The change may be done automatically or manually, such as through administrative or operational action.

[0384] Properly supporting key rotation may be an intensive task for the system 100. One issue is with system components that may be offline, and a key change request may not be delivered to the targeted system components before yet another key change request. For example, successive key rotation processes may result in non-delivery or delayed delivery of key changes. Configuration changes that depend on a key (e.g., ACP 400) may also result in non-delivery or delayed delivery due to a system component being offline. For many system components, this is unlikely to occur, as key changes are delivered quickly. However, it is possible that the SCM 120 may remain unused for days, months, or years, and thus some key rotation events may be missed, after which the previous owner may not be able to transfer the SCM 120 to a new owner using the system 100. More specifically, in this case, the SCM 120 may not be able to decrypt the updated ACP 400 or the updated ACP container 410 and / or authenticate the rotated device 110. In this case, it may be acceptable to factory reset the SCM 120. In another scenario, multiple key rotation events that render the SCM 120 unusable (by the owner or guests) for several hours may not be acceptable from a user experience or usability perspective.

[0385] There may also be key rotation events that affect multiple keys. Multiple keys may be affected under a variety of circumstances, such as a system-wide key rotation, in a device 110 managing multiple SCMs 120, or in an SCM 120 with multiple authorized accounts and / or devices 110. An example sequence is shown below.

[0386] A method for rotating keys according to one embodiment is shown in Figure 12 and generally designated 1200. The cloud 130 requests the device 110 to rotate keys for a given SCM 120 by providing a new Cloud-SCM-Key and other cloud-generated keys (e.g., User-SCM-Key) and / or keys needed to communicate with the cloud (such as tokens) (step 1201). The device 110 generates a new Device-SCM-Key and sends it to the cloud 130 in response to the key rotation request (step 1202).

[0387] At some point after cloud 130 has received the updated Device-SCM-Key (and any other input keys required) from all devices 110 associated with SCM 120, cloud 130 sends the updated ACP 400 ("version 2") to device 110 (e.g., via ACP container 410) for distribution to SCM 120 (step 1203). Device 110 distributes the updated ACP 400 to SCM 120, which includes all required updated keys (step 1204). SCM 120 notifies device 110 that the ACP 400 was successfully updated (step 1205). Device 110 notifies cloud 130 that SCM 120 has applied "version 2" ACP 400. This allows the cloud 130 to maintain the appropriate set of keys for the appropriate version of ACP 400 for each SCM 120, so that if an SCM 120 or device 110 (or other system component) fails to update a key, the previous update can be delivered in order or the most recent update can be delivered using the previous key for recovery (step 1206).

[0388] Steps 1207-1211 indicate a second key rotation event. At some point, the cloud 130 rotates one of the cloud-generated keys for the SCM 120 and distributes (steps 1207, 1208) the updated ACP 400 ("version 3") to the device 110 for distribution to the SCM 120 (e.g., via the ACP container 410). Steps 1209-1211 are similar to steps 1204-1206, in that the cloud 130 is notified that the SCM 120 has applied "version 3" of the ACP 400.

[0389] To rotate keys in an SCM 120, both a "new key" and an "old key" (a known key) may be included in an ACP 400 for a target SCM 120. Each time an ACP 400 is accepted by an SCM 120, an acknowledgement may be sent back to the cloud 130 at some point via an online system component, such as device 110. By tracking which ACP version a particular SCM 120 last accepted, the cloud 130 may prevent the generation of a subsequent ACP container 410 for that SCM 120 that includes a key change where the "old key" field is different from the (previous / unaccepted) ACP 400 being sent, until the ACP 400 being sent has been accepted by the SCM 120.

[0390] In an alternative embodiment, regardless of which ACP 400 was accepted by SCM 120, cloud 130 may send subsequent ACP containers 410 to that SCM 120 as normal. In this embodiment, a minimal predecessor version may be added to the ACP container version package 412, the ACP container 410, the ACP 400, and / or the cloud API response.

[0391] If an SCM 120 detects that its current ACP version is not greater than or equal to the minimum predecessor version (i.e., the last version for which the SCM 120's current set of keys was valid), the SCM 120 may reject the ACP update and request the minimum predecessor version. This may result in the continued rollback of older ACP containers 410 before updated packages are sent out of order or executed by a sending system component (e.g., device 110). Rejecting an ACP update may involve the cloud 130 maintaining a copy of the previously established ACP container 410 for each SCM 120, or at least for those SCMs 120 that have not received the latest ACP.

[0392] Additionally or alternatively, the minimal predecessor version may only be communicated to the receiving system component via a response to the cloud API, and the receiving system component may then request the appropriate ACP container 410. Additionally or alternatively, the cloud 130 may provide only executable ACP containers 410 to the SCM 120 in order, i.e., the cloud may not perform any reordering.

[0393] In one embodiment, if the in-transit ACP 400 has not yet been accepted by a particular SCM 120, the cloud 130 may not send subsequent ACP containers 410 for that SCM until it accepts the in-transit ACP 400.

[0394] In one embodiment, the cloud 130 may merge in-flight key changes into a new ACP version if the in-flight ACP 400 has not yet been accepted by a particular SCM 120. In other words, the cloud 130 may maintain one or more previous keys for each system component and use the appropriate key based on the last known state of the target SCM 120.

[0395] In the illustrated embodiment, because the ACP container 410 is targeted to a specific SCM 120 and signed by one or more system components or services, keys other than those contained within the ACP 400, such as the SCM-Key and Cloud-SCM-Key, as well as other non-key attributes including identifiers, may also be updated at the same time.

[0396] In an embodiment where authorization is not issued to an account (e.g., authorization is instead issued to a specific device 110) for an ACP container 410 that contains only rotated keys, the owner 10 may not be required to approve the updated ACP, and therefore the owner device 110 may not encrypt and sign the ACP outer layer 2. Instead, the owner device identifier may be set to a value that indicates that it is a key rotation ACP 400, and then the ACP outer layer 2 may be encrypted with a key used by another layer (e.g., ACP outer layer 1 or ACP outer layer 3). Additionally or alternatively, the key rotation ACP 400 may not be encrypted, in which case the signature and key fields may be used for further validation.

[0397] In an embodiment where authorization is issued to an account with respect to an ACP container 410 containing only rotated keys, the owner 10 may not need to approve the updated ACP 400, but the user account service can still encrypt and sign the ACP outer layer 2 as usual.

[0398] ACP 400 can have a key rotation attribute that can be set to further verify that the package is legitimate. Validity may indicate that the encryption, or lack thereof, of the ACP outer layer 2 was intentional. During validation of the ACP container 410, SCM 120 can verify that the current key of SCM 120 (i.e., the key specified in the previous ACP 400 received by SCM 120) matches the "old key" in the new ACP. If either key does not match, ACP 400 can be rejected.

[0399] In an alternative embodiment, for the key rotation ACP 400, the SCM 120 may verify that the authorizations have not been updated (except for the keys associated with the authorizations). In another alternative embodiment, for the key rotation ACP 400, only the keys may be updated.

[0400] In alternative embodiments, the owner device 110 may be configured to approve and possibly sign the rekey ACP 400 with or without user intervention. The owner device 110 may only sign the ACP 400 automatically in this situation. In alternative embodiments, the owner device may be configured to approve and possibly sign the rekey ACP 400 with user intervention. The user 10 may be required to approve the ACP 400 as if it were any other authorization change.

[0401] When rotating keys, the system component may retain zero or more predecessor keys for a period of time to aid in accommodating missed key rotation ACP 400. The system component may attempt to use an earlier key if a more recent key fails. The system component may keep the predecessor key alive until it determines that it is no longer necessary to do so, such as using the most recent key, after no new keys, another configuration arrives, or until some time has passed.

[0402] In one embodiment, when a key is rotated, connections to entities utilizing the key may be re-established or at least re-validated. Examples of such connections include device / SCM pairs, cloud / device pairs, and appliance / SCM pairs. While key rotation may be cumbersome in some respects if the user experience is diminished due to improper implementation, key rotation may be considered a security measure and is not meant to be cumbersome. In one embodiment, keys are rotated to prevent compromise using a hacked device, which may be used to disconnect system components such as the SMC 120 to force a reconnection. In the case of a hacked device, the reconnection attempt will likely fail.

[0403] In an alternative embodiment, key changes for SCMs 120 may be distributed similar to how they are distributed in ACP containers 410, but instead may be distributed in a separate package such as a key change package (KCP), with or without a separate KCP version tracked by cloud 130 for each SCM 120. If such an approach is used and KCP versions are not used, the KCP version may be merged with the ACP version.

[0404] In one embodiment, the SCM is not the only system component that can utilize key rotation: the device 110, cloud server 130, equipment components 140, OEM cloud 135, and others (if present) can also be configured to update keys in response to a compromise.

[0405] The key rotation request may originate from the cloud 130, so each system component may verify that the request to rotate a key is authentic. As described herein, each system component may possess multiple keys. Zero or more of the multiple keys may be generated by that system component, and zero or more of the multiple keys may be obtained from other system components. Because each system component may generate at least one of the keys, the key rotation process may involve the cooperation, coordination, and sequencing of multiple system components.

[0406] The SCM 120 may not generate its own keys, and therefore may not be required to rotate keys. In this case, the SCM 120 is the recipient of the key rotation process. Keys that are not generated by the SCM 120 include at least one of the SCM-Key and the SCM-Equipment-Key.

[0407] If an SCM does not generate its own keys, and the key is not under the control of the cloud 130, the cloud 130 may issue a request to have that particular key rotated. For example, the cloud 130 may issue a request to the device 110 to generate a new Device-SCM-Key for the particular SCM 120. If configured, the updated key (authenticated to be from the requested device 110) may be included in an ACP 400 and distributed to that device 110 or to multiple devices 110 associated with the particular SCM 120. The device or devices 110 may distribute the ACP 400 to the SCM 120.

[0408] In an alternative embodiment, the SCM 120 may generate its own keys and therefore may be required to rotate the keys. In an alternative embodiment, a system component may rotate a particular key or initiate a key rotation and issue the new key to the cloud 130 for distribution.

[0409] In an alternative embodiment, instead of delivering updated keys to SCM 120 via ACP container 410, individual key rotation requests (obtained individually or collectively from cloud 130) may be issued to SCM 120 and their status reported to cloud 130. In one configuration of this embodiment, the key rotation process is considered complete only when all requests have been processed.

[0410] In another alternative embodiment, system 100 may not directly support key rotation, but instead may utilize processing within system 100 to remove and reissue authorizations, factory reset SCM 120, factory reset device 110, and / or erase or reinstall applications, and start a new cloud server. XIV. Establishing a Secure Connection

[0411] 14, the device / SCM communication channel may employ a step-by-step authentication process and / or method to improve user experience (responsiveness) and enable communication with devices 110 not previously seen by the SCM 120. The secure connection process may occur over any communication link, but may be configured for a relatively slow, insecure wireless communication link between constrained hardware, such as a Bluetooth Low Energy (BLE) communication link.

[0412] In the illustrated embodiment, the secure connection establishment process or method 1400 can include three distinct phases: (1) unknown-step 1401; (2) secure-step 1402; and (3) trusted-step 1403. The resulting secure connection can be utilized whatever the underlying communication link is, whether the underlying communication layer is secure or insecure. This underlying communication link can be described as a priori unknown communication link. In situations where the a priori unknown communication link is known to be secure (e.g., a TLS or DTLS session has already been established), alternative embodiments may remove redundant phases (e.g., unknown and / or secure). Method 1400 can be similar in some respects to a TLS / DTLS connection establishment process. A. Prior unknown communication links

[0413] The a priori unknown communication link initialization and connection sequence may vary based on the system configuration and the underlying physical medium and protocol stack (e.g., Ethernet-IP-TCP, Ethernet-IP-UDP, Ethernet-IP-TCP-TLS, BLE, 802.15.4-IPv6 [6L0WPAN], etc.). Therefore, the actual messaging content, packetization / framing, and sequence / processing of send / receive connecting / connected protocols may differ slightly due to differences in the underlying technology. It is also possible that differences in the underlying technology may result in one or more protocol steps being collapsed into a single step (or conversely, it may be useful or necessary to split a single step into many smaller steps to overcome very small packet / message limitations). However, the higher level protocol steps may remain the same. In the illustrated embodiment, the connection establishment process is performed over Bluetooth Low Energy (BLE), although it should be understood that the present disclosure is not limited thereto.

[0414] By the time the SCM 120 and device 110 reach the start of the unknown phase-step 1401, significant effort may have been expended to set up a pre-unknown communication link. One such example of this is the application of the present embodiment in combination with the system described in U.S. Patent Application No. 14 / 620,959, filed February 12, 2015, by J. Michael Ellis et al., entitled "System and Method for Communicating with a Vehicle," and U.S. Patent Application No. 15 / 488,136, filed April 14, 2017, by Raymond Michael Stitt, entitled "System and Method for Establishing a Real-Time Location." The disclosures therein are incorporated by reference in their entirety, including microlocation systems using BLE. A method according to this system is shown in the illustrated embodiment of FIG. 13 and designated 1300. Method 1300 may use an (initial connection) connection strategy in which the master device (SCM 120) starts as peripheral and the portable device (device 110) starts as central (step 1301). After agreeing to communicate with each other, the roles are switched, where the master device 110 becomes central and the portable device 110 becomes peripheral as part of a micro-locating connection (step 1302).

[0415] In embodiments in which the security models / systems described herein may be applied in combination with the systems described herein and / or systems described in U.S. patent application Ser. No. 14 / 620,959, filed Feb. 12, 2015, entitled “SYSTEM AND METHOD FOR COMMUNICATING WITH A VEHICLE,” to J. Michael Ellis et al., and U.S. patent application Ser. No. 15 / 488,136, filed Apr. 14, 2017, entitled “SYSTEM AND METHOD FOR ESTABLISHING A REAL-TIME LOCATION,” to Raymond Michael Stitt, the disclosures of which are incorporated herein by reference in their entireties. · Prior unknown communication link - initial connection

[0416] A previously unknown communication link may be an initial connection in connection with method 1300. In other words, device 110 and SCM 120 have not yet swapped roles, so the first exchange in the sequence described herein with respect to method 1300 is from device 110 to SCM 120.

[0417] In this embodiment, the secure connection establishment process can be completed through either a secure phase or a trusted phase within the context of the initial connection. The process can be completed through a secure phase or a trusted phase depending on whether mutual authentication is performed during the unknown or secure phase.

[0418] A session key, such as the Device-SCM-Session-Key, established during this process may be verified and / or authenticated prior to switching to the microlocation connection (i.e., role reversal). In either case, the session key may be used within (handed over to) the microlocation connection to establish a secure communication channel. If phase demotion is utilized, the microlocation connection may continue to be used. Phase demotion may be utilized in a variety of situations, such as disconnection / reconnection, session key rotation, or due to authentication failure.

[0419] This approach can enable the SCM 120 to neatly distribute device connections to alternate system components (eg, the SCM 120 or similar modules) at role reversal boundaries. 2. Prior unknown communication links – microlocation connections

[0420] In one embodiment, the previously unknown communication link may be a microlocation connection. In other words, the device 110 and the SCM 120 may have already swapped roles, and thus the first exchange in the sequence described with respect to the method 1400 is reversed, from the SCM 120 to the device 110.

[0421] This is an alternative embodiment, in which the unknown connection establishment phase in step 1401 may not be completed during the initial connection in method 1300. That is, the entire connection establishment process 1400 may be completed within the context of the microlocation connection established in step 1320 of method 1300. 3. Establish a previously unknown communication link

[0422] 14, the beginning of an initial connection in the microlocation system is when a device 110 decides to connect to a particular SCM 120. By way of example, the device 110 may decide to connect to the SCM 120 because the SCM 120 is recognized as a system component with which the device 110 believes that a) the device 110 is configured to communicate, b) the device 110 wishes to become the owner of the SCM 120, or c) the device 110 is a nosy (or malicious) device that will connect with the SCM 120.

[0423] The device 110 may use the initial connection established in step 1301 according to method 1300 to query the SCM 120, such as to determine if the SCM 120 is in a factory reset mode, to send an updated ACP, or to determine other settings. When the device 110 and / or the SCM 120 begin the portion of the secure connection establishment process in which a session key (Device-SCM-Session-Key) is established, the device 110 may perform a role reversal (step 1402) by switching to a microlocation connection according to step 1302. The secure connection establishment step may occur after the device 110 has shared its Device-SCM-ED, so the SCM 120 has some evidence that the device 110 is the device 110 that the SCM 120 should connect to, even though it may not be secure.

[0424] In this approach, the device 110 may not be able to authenticate the SCM 120 and / or the SCM 120 may not be able to authenticate the device 110 before deciding whether to switch to a microlocation connection and attempt to establish a secure communications channel with the device 110.

[0425] In the illustrated embodiment of Figure 14, message timing information may be incorporated into the challenge-response protocol of the communications link to help protect against relay attacks. Although the application embodiment shown in Figure 14 focuses on the microlocation system discussed herein and incorporated by reference herein, the disclosure is not limited thereto and the system 100 and communication methods described herein may facilitate communication in any type of system of devices or system components.

[0426] In one embodiment, because some device platforms / libraries do not allow a BLE peripheral to advertise all desired information while in background processing mode, SCM 120 and / or device 110 may store the BLE binding information to complete the transition to a microlocation connection. In an alternative embodiment, the BLE binding may be completed during the initial connection phase on behalf of the user. B. Establishing a Secure Connection

[0427] The device 110 may initiate a connection with the SCM 120 according to the illustrated embodiment of Figure 14. The SCM 120 may accept the connection and begin the connection establishment process of step 1401 - a first (unknown) phase, step 1402 - a second (secure) phase, and step 1403 - a third (trusted) phase. First (unknown) phase

[0428] In the illustrated embodiment, during the first (unknown) phase, it is unknown whether the communication link is secure.

[0429] The underlying communication link may already provide some level of encryption and / or end node hardware authentication, which may or may not be secure in nature. For example, the underlying communication link may suffer from known flaws / vulnerabilities. As a result, during this phase, the communication link is assumed to be insecure.

[0430] During this phase, or during step 1401, device 110 may send a request to SCM 120 to switch to a secure communication channel (step 1410). This request may induce device 110 to send its Device-SCM-ID and ACP container version package 412 to SCM 120. In an alternative embodiment, the Device-SCM-ID of device 110 may be included in the ACP container version package 412. The Device-SCM-ID can be used by SCM 120 to determine which set of encryption keys to use for subsequent messages, such as the Device-SCM-Key, ACP-Version-Key, or Device-SCM-Session-Key, or a combination thereof.

[0431] As described at least in the ACP container 410 section (Section III), the SCM 120 may not allow a transition to a secure communication channel if the ACP 400 is to be updated. If it is determined that the ACP 400 of the SCM 120 is to be updated, the SCM 120 may send a request back to the device 110 to send the updated ACP 400.

[0432] If the ACP 400 of the SCM 120 does not need to be updated, the SCM 120 sends a message back to the device 110 indicating that the device 110 can continue, and further determines whether to use the previously stored session key (Device-SCM-Session-Key) (step 1412). If the SCM 120 indicates that the device 110 should use the already established session key (the session key itself does not need to be disclosed) and the device 110 possesses the session key (Device-SCM-Session-Key), the device 110 and the SCM 120 can immediately move to the secure phase. If not, the SCM 120 and the device 110 can start establishing a new session key (Device-SCM-Session-Key). The Device-SCM-Session-Key session key may be established while the device 110 attempts to achieve challenge-response authentication of the SCM 120 according to one or more of the following steps: 1) The device 110 can generate a cryptographic nonce (N). 2) The device 110 can encrypt N with the Device-SCM-Key (private) key to create ND. 3) The device 110 may send an ND to the SCM 120. 4) The SCM 120 can use the Device-SCM-Key (public) key to decrypt the ND and create the NDS. 5) The SCM 120 may generate a cryptographic nonce (M). 6) The SCM 120 can calculate a copy of the session key, Device-SCM-Session-Key, using, for example, a cryptographic hash of NDS concatenated with M. The session sequence number (stored with the session key) can be set to 0 or a random number. 7) The SCM 120 can encrypt NDS and M with an SCM-Key (private) key to generate NM. 8) The SCM 120 may send the NM to the device 110. 9) The device 110 can use the SCM-Key (public) key to decrypt the NM and create the NDSD and MD. 10) The device may verify that N is equal to NDSD. If there is no match, the SCM 120 cannot be authenticated and the device 110 disconnects. The SCM 120 and device 110 may discard any previously calculated session keys. The challenge-response authentication process may be aborted at this stage. 11) Device 110 may compute a copy of the session key, Device-SCM-Session-Key, for example, using a cryptographic hash of N concatenated with MD. The session sequence number stored with the session key may be set to 0.

[0433] At this point, both the device 110 and the SCM 120 have calculated a new session key, but neither has verified that they can successfully communicate, which may be considered yet another measure of the authenticity of the SCM 120. If the challenge-response authentication process is completed successfully, then in step 1402 the device and SCM may immediately move into the secure phase.

[0434] In one embodiment, in addition to encrypting the messages in the challenge-response authentication process, the messages may be encrypted after they are signed. In an alternative embodiment, the cryptographic nonce (N) generated by the device 110 may be encrypted by the SCM-Key (public) key instead of the Device-SCM-Key (private) key. In another alternative embodiment, the cryptographic nonce (N) generated by the device 110 may not be encrypted. In yet another alternative embodiment, the cryptographic nonce (M) generated by the SCM 120 may be sent with the "continue" message (sent before the challenge-response authentication process) when the session key has not yet been established.

[0435] In yet another alternative embodiment, the session key (Device-SCM-Session-Key) may be calculated by another method. In yet another alternative embodiment, an alternative challenge-response authentication algorithm may be utilized. In yet another alternative embodiment, the Device-ID may be used as the Device-SCM-ED. In one embodiment, a session sequence number is not utilized.

[0436] In one embodiment, device 110 may send a "session key established" message to SCM 120 when the challenge-response authentication process is successful (i.e., when the device generates its session key). In one embodiment, device 110 may send an "authentication failed" message to SCM when the challenge-response authentication process is aborted.

[0437] In one embodiment, SCM 120 may verify the authenticity of device 110 during this phase or step 1401 (instead of device 110 verifying the authenticity of SCM 120), so that at a later stage, when a command is sent, device 110 may verify the authenticity of SCM 120.

[0438] In one embodiment, in addition to or as an alternative to one or more of the embodiments described herein, device 110 and SCM 120 may mutually authenticate each other during step 1401. In this case, if successful, device 110 and SCM 120 may move to a trust phase.

[0439] SCM 120 may be configured to disconnect from device 110 after a predetermined period of inactivity. SCM 120 may also disconnect from device 110 at any time or in response to any event. For example, SCM 120 may disconnect due to high system resource usage at SCM 120, due to failure to respond to a request within a predetermined time, or due to a connection duration that exceeds a predetermined maximum duration.

[0440] As described at the beginning of this section XIV.B, the SCM 120 may request the device 110 to send the ACP container 410 with the ACP container version package 412. The device 110 may send the ACP container 410 to the SCM 120 during this phase. In response to receiving the ACP container 410, the SCM 120 may provide a response with a status indication, possibly at a minimum, indicating whether the ACP container 410 was accepted, not processed, or rejected. Acceptance may indicate that the ACP container 410 has been processed and stored, and may indicate that any changes contained in the ACP container 410 have been successfully applied. Not being processed may be due to the ACP container 410 being an older or the same version. Rejection may indicate that validation failed. In an alternative embodiment, the SCM 120 may not provide a status indication to the device 110 regarding the ACP container 410 for update processing.

[0441] To support a factory reset state, device 110 may request an SCM-Key (public) key and / or an SCM-ID identifier from SCM 120 during step 1401 via a new owner initiated request. In response to this request, SCM 120, if in factory reset mode, may provide a response that includes an SCM-Key (public) key and / or an SCM-ED identifier, thereby indicating that SCM 120 is, in fact, in factory reset mode.

[0442] The SCM 120 may log information about failed authentication attempts in an SCM system log. Examples of failed authentication attempts include failure to enter or remain in the secure and / or trusted phase. 2. The second (safety) phase

[0443] During the second (secure) phase or step 1402, both the device 110 and the SCM 120 may have a session key (Device-SCM-Session-Key) that may be used to create a secure communication channel. That is, the session key may enable the device 110 and the SCM 120 to perform one or more of the following: encrypting data, incrementing a sequence number, and generating a message authentication code.

[0444] Messages from the device 110 and SCM 120 using the secure communication channel may be sent using the Device-SCM-Session-Key session key with an increasing sequence number to encrypt and MAC (e.g., encrypt the message using the Device-SCM-Session-Key and append a MAC [Message Authentication Code] calculated from the encrypted message), allowing the device 110 and SCM 120 to verify and authenticate the sent / received message. This communication mode may be similar to some features of TLS / DTLS. Note that approaches other than encryption-then-MAC may be used (e.g., MAC-then-encrypt, or encryption and MAC), but they may be less secure.

[0445] In the illustrated embodiment, the session key (Device-SCM-Session-Key) can survive the connection. Thus, to limit the duration or persistence of the session key, the Device-SCM-Session-Key session key may be rotated by the SCM 120 (at any phase) periodically and / or at convenient times. Convenient times may be during other events where the user experience is already affected, or while other actions are occurring that result in a new session key in any way (key rotation or ACP update). Convenient times may also be taken in a more traditional sense, in which case a convenient time may be considered as a time when the user experience is not affected or not noticeably affected, such as while the user 10 is not actively using the SCM 120 but is within range of the SCM 120, or while the user is in and out of range and has enough time to complete the process. Examples of being within range include sitting in a car that is already started, sitting at a table, sitting with the door locked.

[0446] The session key may be rotated by executing a session key rolling algorithm within the existing secure communication channel and / or by calculating a new session key using a challenge-response authentication process or another process similar in some respects to the process described herein with respect to the unknown phase and the calculation of the session key during the unknown phase. Additionally or alternatively, the session key may be rotated by invalidating the stored session key and then disconnecting and re-establishing the session key during the unknown phase. In one embodiment, the device 110 may initiate the rotation of the session key.

[0447] At the start of step 1402, the device 110 may send either a request to the SCM 120 to verify that the session key (Device-SCM-Session-Key) is valid (to verify that the channel is operational) or a request to verify both the validity of the channel and the authenticity of the SCM 120 (steps 1416, 1418). If an existing session key was used, e.g., the previous phase was not performed recently, the validity and authenticity of the SCM 120 may be confirmed (step 1418).

[0448] If the device 110 has recently confirmed operation of the channel or has verified that the session key is valid, it may skip this channel verification step 1418. In an alternative embodiment, the device may not skip the verification step 1418.

[0449] To complete the session key verification step 1418, the device 110 and the SCM 120 may execute a secure phase challenge-response protocol. The primary purpose of this protocol is for the device 110 to verify the operation of the channel when the authenticity of the SCM 120 has already been established and to immediately enter the verification phase from the unknown phase. However, the secure phase challenge-response protocol may also be used periodically by either the device 110 or the SCM 120 as a means of maintaining the connection of the channel or for other purposes. Below is an example of a (simple) challenge-response protocol: 1) The device 110 (or SCM 120) can generate a random number (N). 2) The device 110 may send N to the SCM. 3) The SCM 120 can calculate N+1(M). 4) The SCM 120 may send M to the device 110. 5) Device 110 can verify that N+1 is equal to M. If they do not match, the verification results in a failure, possibly because the message was not communicated properly.

[0450] When device 110 executes the secure phase challenge-response protocol, device 110 may verify that the communication channel is working. Device 110 may not have verified anything about the authenticity of SCM 120 at this stage, except that SCM 120 possesses the correct session key. The roles of SCM 120 and device 110 may be reversed, as SCM 120 may also initiate the secure phase challenge-response protocol to verify the secure communication channel. In alternative embodiments, the secure phase challenge-response protocol may not be utilized. In this case, an authentication protocol may always be used or there is no authentication protocol.

[0451] In one embodiment, the device 110 may use a secure phase challenge-response authentication protocol to verify the authenticity of the SCM 120. The secure phase challenge-response authentication protocol may be performed periodically, upon entering the secure phase after a predefined time has elapsed, or upon some other event occurring. Exemplary events include the SCM 120 requesting the device 110 to perform a secure phase challenge-response authentication protocol, and an updated ACP 400 being received by the device 110. The secure phase authentication protocol outlined below is similar in many ways to the unknown phase authentication protocol. However, the secure phase authentication protocol outlined herein utilizes fewer asymmetric cryptographic operations and therefore requires significantly less computation. An exemplary secure phase authentication protocol may be performed as follows (alternative challenge-response authentication protocols may also be used): 1) The device 110 can generate a cryptographic nonce (N). 2) The device 110 may send N to the SCM. 3) The SCM 120 can compute the cryptographic hash of N+1(M). 4) The SCM 120 can encrypt M with the SCM-Key (private) key to create MS. 5) The SCM 120 can send the MS to the device 110. 6) The device 110 can decrypt the MS using the SCM-Key (public) key to create the MSD. 7) The device 110 can compute a cryptographic hash of N+1(MD). 8) The device 110 can verify that the MD is equal to the MSD. If they do not match, authentication will fail because the SCM 120 may not possess the proper encryption keys to prove its authenticity.

[0452] In alternative embodiments, an alternative encryption key, such as a Device-SCM-Key (public) key, may be used instead of the SCM-Key (private) key. In alternative embodiments, an additional encryption key, such as a Device-SCM-Key key, may be used.

[0453] Similar to the described process in the unknown phase, the device 110 may transmit the ACP container version package 412 to the SCM 120 using a secure communication channel. As an example, the device 110 may transmit the ACP container version package 412 in response to or based on the device receiving an updated ACP container 410. If the SCM 120 determines a need or desire to receive a corresponding ACP container 410, the SCM 120 may request the device 110 to transmit the ACP container 410 accompanied by the ACP container version package 412. The SCM 120 may also request the device 110 to transmit the latest ACP container version package 412 stored on the device 110 periodically or in response to the occurrence of an event.

[0454] The device 110 may send the ACP container 410 to the SCM 120 during this phase using a secure communication channel. In response, the SCM 120 may provide a response with a status indication, as described in the previous phase. In an alternative embodiment, the ACP container 410 and / or the ACP container version package 412 may not be allowed to be sent to the SCM 120 during the secure phase. As described herein, there may be other configuration packages that use similar semantics / processing as the ACP container 410, and therefore it should not be inferred that the ACP container 410 is the only configuration package of the system 100 that may be delivered in this and other phases.

[0455] In one embodiment, a firmware update package (FUP) may be delivered from device 110 to SCM 120 only over a secure communication channel, such as during a secure or trusted phase. Device 110 may obtain the FUP from cloud 130 or as part of an executable / loadable image stored on device 110. For example, the FUP may be obtained as part of an application bundle or as a separate image included in a larger device firmware image.

[0456] In one embodiment, the FUP may be distributed from device 110 to SCM 120 over any communication channel. In one embodiment, the FUP may be distributed from device 110 to SCM 120 only over a secure communication channel for which device 110 is authenticated, such as only during a trust phase. In one embodiment, the FUP may be distributed from device 110 to SCM 120 only by owner device 110. In one embodiment, device 110 may not distribute the FUP to SCM 120. Additional or alternative firmware update configurations and embodiments are described at least in Section XV, which includes additional information regarding the firmware update packages themselves.

[0457] SCM 120 may send a blacklist package, discussed in further detail herein in at least Section XXI, to device 110 using a secure communications channel. Device 110 may provide a response to the blacklist package with a status indication. In one embodiment, device 110 may request SCM 120 to send the blacklist package to device 110. If there are no items to blacklist, SCM 120 may do nothing, or SCM 120 may send an indication that there are no items to blacklist.

[0458] The device 110 and SCM 120 may execute various system level operations in the background while communicating with each other via a secure communication channel. These operations may not be related to the explicit execution of a command that utilizes authentication and / or authorization for initiation or completion. For purposes of the disclosure, any operation that is executed as a result of communication between the device 110 and SCM 120 or as a result of no communication is considered a command. Thus, such background operations are considered commands. Anything or action that may be executed can be considered a command. There may be some operations or actions that occur when nothing is connected (e.g., turn off the lights) and there may be some operations or actions that occur when something is connected (e.g., track the device, turn on the lights, etc.). The command may relate to an action or operation of the device 110 or SCM 120 or other system components.

[0459] Exemplary background operations include microlocation services, GPS / INS services, status information, logging, background / maintenance operations, power mode changes, and configuration updates. Additionally, transitions from one communication phase to another are considered commands (e.g., to disconnect, transition from unknown to secure, secure to trusted, trusted to unknown, etc.). For example, authorization for device 110 to SCM 120 may be required to transition to a trusted communication phase (i.e., authorization may include both authentication information and authorization criteria).

[0460] It is also worth noting that in this phase (step 1402), the SCM 120 may not have explicitly verified the authenticity of the device. There may not have been any explicit verification recently or initially. However, there may be sufficient evidence to have a high degree of confidence that the device 110 is authentic. At some point in this phase (step 1402), the device 110 and / or the SCM 120 may generate, issue, or receive a command, which may encapsulate sending / receiving any one or more of the following commands: 1) a command (e.g., the device 110 may be instructing the SCM 120 or its equipment component 140 to do something); 2) a request (e.g., the device 110 may be requesting the SCM 120 or its equipment component 140 to send data); 3) an update (e.g., the SCM 120 or its equipment component 140 may be providing periodic / non-periodic data); and 4) a response (e.g., the SCM 120 or its equipment component 140 may be providing a response to a request).

[0461] The SCM 120 can perform an action, including any one of the enumerated commands, based on the presence, location, authentication status, or authorization status, or any combination thereof, of the device 110. The device 110 can perform an action, including any one of the enumerated commands, based on the presence, location, authentication status, or authorization status, or any combination thereof, of the SCM 120.

[0462] The above description of various types of commands, and what is considered a command, is not intended to be exhaustive or limited to the above list, nor is the list of commands limited to this phase of communication (e.g., a command is a command that is generated, issued, or received regardless of any phase of communication).

[0463] If SCM 120 receives a command and device 110 has not been authenticated, the command may be queued while device 110 is authenticated. If device 110 fails authentication, an appropriate error response may be provided for each rejected command.

[0464] In one embodiment, only up to one command may be queued while device 110 is authenticated. Additionally or alternatively, a command may be rejected if device 110 is not yet authenticated.

[0465] In one embodiment, system level background processing may not be allowed unless in the trusted phase (step 1403).

[0466] The SCM 120 may (preemptively) authenticate the device 110 even if no commands are sent or received to improve the user experience. In another embodiment, the SCM 120 may not preemptively authenticate the device 110.

[0467] In one embodiment, in order for device 110 to send or receive a command to SCM 120, SCM 120 may require authentication of device 110 by SCM 120. SCM 120 may initiate a secure phase challenge-response authentication protocol to verify the authenticity of device 110 before allowing execution of the command (steps 1420, 1422). An example of a secure phase challenge-response authentication protocol may include one or more of the following steps: 1) SCM 120 may generate a cryptographic nonce (N). 2) SCM 120 may send N to the device. 3) Device 110 may compute a cryptographic hash of N+1 (M). 4) Device 110 may encrypt M with a Device-SCM-Key (private) key to create MS. 5) Device 110 may send MS to SCM. 6) SCM 120 may decrypt MS with a Device-SCM-Key (public) key to create MSD. 7) SCM 120 can compute a cryptographic hash of N+1 (MD). 8) SCM 120 can verify that MD is equal to MSD. If MD and MSD do not match, authentication will fail. In other words, if MD and MSD do not match, device 110 did not possess the proper cryptographic key to prove the authenticity of device 110.

[0468] Once the device 110 is authenticated, the device 110 may not need to be authenticated again for a predetermined period of time and / or until a predetermined event occurs, such as a disconnection occurring, an update to the ACP container 410, and an authentication request from the equipment component 140, or any combination thereof.

[0469] In one embodiment, as described herein, authenticity of device 110 may be performed only once per key rotation session. In one embodiment, if the SCM verification of authenticity of device 110 fails, device 110 and SCM 120 may remain in the secure phase (step 1402).

[0470] In one embodiment, authentication of device 110 may be performed by SCM 120 on all commands issued from and sent by device 110. In one embodiment, authentication of device 110 may be performed on all commands issued from device 110. In one embodiment, authentication of SCM 120 may be performed on all commands issued from SCM 120.

[0471] If the challenge-response process or the challenge-response authentication process fails, the device 110 and SCM 120 may immediately disconnect and / or return to the unknown phase at step 1401 .

[0472] After the SCM 120 verifies the authenticity of the device 110, the device 110 and the SCM 120 can move into a trust phase. 3. The third (trust) phase

[0473] During the third (trust) phase, both device 110 and SCM 120 may possess a verified session key (Device-SCM-Session-Key), and both device 110 and SCM 120 are determined to be authentic (step 1403).

[0474] During this phase (step 1403), all or a subset of the actions and consequences of the previous phase may be performed over the secure communications channel, including, for example, updates to the ACP container 410, firmware updates, background / other processing, and challenge-response authentication protocols of the device 110 and SCM 120. If authentication over the secure communications channel fails, the device 110 and SCM 120 may immediately disconnect and / or revert to the previous phase (e.g., the unknown phase).

[0475] During the trust phase, periodic authentication of both SCM 120 and device 110 may be utilized and even deemed necessary. Periodic authentication may be implemented by routine execution of commands, by periodic and / or triggered separate authentication verification of authenticity for SCM 120 and device 110 (via an appropriate challenge-response authentication protocol), or by periodic and / or triggered mutual authentication challenge-response authentication protocols. In alternative embodiments, periodic authentication of both SCM 120 and device 110 may not be required or deemed necessary.

[0476] In one embodiment, a mutual authentication challenge-response protocol may be implemented that is similar to the challenge-response protocol described above, with one or more exceptions. One difference is that both the SCM 120 and the device 110 are authenticated in one sequence. This single sequence authentication may incorporate one or more features of TLS / DTL mutual authentication. If the challenge-response authentication process fails, the device 110 and SCM 120 may immediately disconnect and / or return to an unknown phase.

[0477] During the trust phase (step 1403), an opaque data channel (ODC) may be made available between the SCM 120 and the device 110 for use in transferring abstract user-defined commands and / or data back and forth. The ODC may enable the SCM 120 to reliably pass commands and / or data from one system component (e.g., the device 110) to another device (e.g., the equipment component 140) while ensuring that the device 110 is authorized to do so, but perhaps without knowledge of the details of the device 110's API or data. One or more of the authorization, validation, and verification of the commands and / or data used in the ODC may not be performed by the SCM 120. The ACP 400 may also include additional information that may be useful in conjunction with the ODC, such as additional authentication types and identifiers. XV. Firmware Upgrade

[0478] In one embodiment, system 100 may be configured to ensure that system components can safely and securely upgrade firmware. The ability to upgrade firmware may fix security vulnerabilities or firmware defects. Firmware updates may be delivered to SCM 120 via a firmware update package (FUP) as described herein.

[0479] The FUP may be received using a FUP version package (similar in many respects to the ACP container version package 412, but adapted to facilitate transfer of the FUP instead of the ACP 400). The FUP (and the FUP version package provided therewith) may be distributed via the cloud 130 to a system component, such as the equipment component 140, and then to the SCM 120 in a manner similar to the ACP container 410.

[0480] As described herein according to one embodiment, firmware updates may be delivered to SCM 120 via a secure communications channel. Different system instantiations may have different allowed firmware update distributors. For example, one system may allow firmware to be delivered via device 110 or directly from cloud 130, whereas another system may expect updates to occur only via the physical medium of equipment component 140 or SCM 120.

[0481] The FUP is similar to the design of the ACP container 410 and other secure firmware image / distribution techniques described herein in that the FUP may be transmitted, stored, and distributed from any system component to a specific SCM 120. However, in one embodiment, the system 100 may be configured such that transmissions are only allowed to one or more specific system components. In another embodiment, the firmware update may be transmitted to the SCM 120 over any type of communication channel.

[0482] The FUP and FUP version packages, like the ACP container 410, may be signed and / or encrypted for the target SCM 120 and then signed and / or encrypted by the cloud 120 so that the FUP and FUP version packages can be verified to have originated from the appropriate cloud 130 and only the target SCM 120 can decrypt the contents of the FUP and FUP version packages.

[0483] If the FUP is specific to a target SCM 120, the target SCM 120 may be specified in the package. The identity of the cloud 130 may be provided in the FUP and FUP version packages.

[0484] In one embodiment, the FUP and FUP version packages may be encrypted and / or signed only by cloud 130. The FUP and FUP version packages may be visible and / or applicable to many SCMs 120, or may be applicable to only one SCM 120 but the contents of the FUP and FUP version packages may be visible to all of the many SCMs 120. In one embodiment, the FUP version packages may be encrypted and / or signed using an ACP-Package-Version key.

[0485] In one embodiment, the FUP and FUP version packages may not be encrypted. In another embodiment, the FUP may be further signed and / or encrypted with a manufacturer-provided encryption key (e.g., a Firmware-Key) that may or may not be specific to a particular industry, customer, product line, and / or number of targets (including being specific to a single target), among other options. In one embodiment, an additional layer of signing and / or encryption may be utilized for the FUP and / or FUP version packages, which makes the FUP version packages more similar to the configuration of the ACP container 410.

[0486] The FUP may be securely stored in one or more system components (e.g., device 110 or cloud 130), in secure memory 220, or in a secure element such as a secure enclave or hardware security module (HSM) or equivalent hardware module.

[0487] In one embodiment, the FUP may not be stored in a secure element (or equivalent hardware module). However, the FUP may still be securely stored. For example, secure storage without the use of secure memory 220 may be achieved by one or more of the following: the ACP-Version-Key private key may be encrypted at rest, software-based and / or hardware-based measures may be implemented to prevent access to such data, and hardware and / or physical barriers or shields may be implemented. JTAG and other ports may be disabled. Hardened software interfaces may be implemented to eliminate attack vectors. A trusted execution environment, hardware or software, may be instituted and a detection system implemented to detect the onset of operating system root access or security breaches. In an alternative embodiment, the ACP-Version-Key private key is not securely stored.

[0488] SCM 120 and its subcomponents may continue to operate normally while receiving the firmware update image. SCM 120 and its subcomponents may apply the updates immediately and / or when not in use and / or at a predefined time period, such as a time of day or day of the week. In one embodiment, SCM 120 and its subcomponents may enter an update mode that suspends or disables normal operation while the firmware is being updated.

[0489] SCM 120 can roll back to previous versions of its own firmware and all SCM subcomponents if its currently operating firmware is corrupted or not operating within expected or required constraints. For example, SCM 120 can initiate a rollback procedure if too many exceptions occur within a unit of time, if SCM 120 cannot operate continuously long enough to perform another firmware update, if SCM 120 cannot establish a connection with another system component (such as device 110, cloud 130, or equipment component 140), or if image hash / CRC verification fails upon loading, or any combination thereof. Operational constraints may be hard-coded within the boot selector, boot loader, firmware / application, or other loadable items.

[0490] In one embodiment, the operational constraints may be configurable at run time. Statistical and / or other information useful for evaluating the operational constraints may be stored in a memory area that survives reset and / or power loss. In one embodiment, the operational constraints may include run-time behavioral or statistical analysis, run-time performance (e.g., timing or throughput) analysis, classification using machine learning, or other dynamic analyzers to determine if the firmware is operating properly, or any combination thereof. In one embodiment, when a firmware rollback occurs, subcomponents of SCM 120 may be notified and choose whether or not to roll back. In one embodiment, SCM 120 and subcomponents of SCM 120 may not roll back for various reasons, including, for example, because one or more of these components cannot perform the rollback, or because one or more of these components cannot keep track of enough statistical data to determine whether to downgrade.

[0491] In one embodiment, before requesting a FUP, the firmware version, timestamp, minimum compatible version, and other version information, as well as constraints on all or a subset of the firmware images in the FUP specified by the FUP version package, or any combination of this information, may be verified for applicability.

[0492] If the FUP is determined to be applicable, it may be requested from the target. A particular firmware update image may be determined to be applicable based on one or more criteria, such as the firmware update image version is newer than the current firmware (or is equivalent and its timestamp is newer), the minimum compatible versions of various settings are compatible with the new firmware, and all other constraints are met. Once the complete firmware image is obtained (and perhaps again when written to ROM), the image may be verified by the target. Verification may include performing an integrity hash, a signature, analysis of other attributes that may be verified, or any combination thereof.

[0493] In one embodiment, the firmware image may be delivered to the target system components in smaller chunks (to allow processing by constrained components) so that the smaller chunks can be verified independently.

[0494] The SCM 120 may authenticate, additionally encrypt and / or sign, or leave unaltered, or any combination thereof, firmware updates for the subcomponents of the SCM 120 and deliver the updates to the subcomponents. The subcomponents of the SCM 120 may be other hardware modules in the SCM 120 and / or other sensors in the SCM 120 that collectively represent the SCM 120 from the perspective of other system components.

[0495] In one embodiment, delivery of firmware updates to subcomponents of SCM 120 may be synchronized and / or ordered among the subcomponents. SCM 120 may update all subcomponents before updating itself and verify that each subcomponent has been successfully updated by verifying the version of the loaded item. In one embodiment, SCM 120 may update its own firmware before the firmware of the subcomponents. In one embodiment, system 100 may be configurable based on data in the FUP as to whether SCM 120 updates the subcomponents first, SCM 120 is updated first, or there is another ordering constraint that must be met.

[0496] The SCM 120 can broadcast firmware updates to all SCM subcomponents, or the SCM can send firmware updates targeted to specific SCM subcomponents.

[0497] In one embodiment, a delta update may be used to transmit the FUP to the SCM 120. Compression may be used to transmit the FUP to the SCM 120.

[0498] In one embodiment, cloud 130 may provide firmware update packages to system components other than SCM 120, such as device 110 and equipment component 140, using the FUP format or an alternate format for different system components. In one embodiment, system components may support the distribution (and / or routing) of firmware updates for other system components. For example, device 110 may distribute equipment firmware updates via SCM 120.

[0499] In one embodiment, a system component may authenticate, additionally encrypt / sign, or leave unaltered a firmware update, or any combination thereof, and distribute the update to other components. As an example, the device 110 may distribute a firmware update package to the SCM 120, which may sign and distribute the firmware update package to another SCM 120 or to an attached equipment component 140.

[0500] After initial manufacture, or in response to being commanded to perform a factory reset, the SCM 120 may enter a factory reset mode. In response to being commanded to perform a factory reset, the SCM 120 may discard its ACP 400, other configuration records, and encryption keys to return to the factory (initial manufacture) state. Zero or more of the following identifiers and encryption keys may not be reset as a result of a factory reset: 1) SCM-ID Identifier 2) SCM-Key 3) Equipment-Key 4) SCM-Equipment-Key

[0501] In one embodiment, the SCM-Key key may be rotated by SCM 120 as a result of a factory reset. Changing the SCM-Key key will cause SCM 120 to be presented to system 100 as a new SCM 120, and any system components with the old SCM-Key key will be unable to encrypt or decrypt messages from SCM 120. Although SCM 120 may appear to be new, SCM 120 can still be identified as the same SCM 120 as long as its SCM-ID remains unchanged (or an alternate identifier for identifying SCM 120 remains unchanged).

[0502] In one embodiment, if the SCM-Key is not rotated and an attacker is able to successfully connect and authenticate with the cloud 130 using a device 110 under the attacker's control, the attacker may be able to gather information to compromise parts of the system and then submit a new owner registration request. In this way, the attacker may be able to convince the cloud 130 to transfer ownership of the SCM 120 to the attacker's device 110. However, the SCM 120 will reject any messages that must be signed by the cloud 130, including the ACP 400 that authorizes the attacker's device 110 to send and / or receive commands to and / or from the SCM 120. In this case, the attacker's actions may be clearly identifiable and reversible.

[0503] Changing the SCM-Key upon factory reset can enable the cloud 130 to reject any request to become the initial owner device 110 of an SCM 120 that is already registered with the same SCM-Key, providing an additional mechanism to prevent an attacker from attempting to "take over" the SCM 120 using a new owner registration request. In an alternative embodiment, the cloud 130 can generate a new SCM-Key to be delivered to the SCM 120 as part of the new owner registration request response.

[0504] In one embodiment, the SCM-ID identifier may be rotated by the SCM 120 as a result of a factory reset. The SCM-ID identifier may be intended to be a persistent identifier. However, changing the SCM-ID identifier may result in the system 100 being unable to identify the SCM 120 as the same physical part, especially if the SCM-Key is also changed. In one embodiment, the cloud 130 may generate a new SCM-ID identifier to be delivered to the SCM 120 as part of a new owner registration request response. In one embodiment, the SCM-ID may be rotated and the cloud 130 may keep a history of the SCM-IDs for that SCM 120.

[0505] In one embodiment, the Equipment-Key key may be cleared by the SCM 120 as a result of a factory reset. The SCM-Equipmen-Key key may be rotated by the SCM 120 as a result of a factory reset according to one embodiment. Clearing and / or changing the equipment key may cause the SCM 120 to be unable to communicate with equipment components 140 coupled to or possibly attached to the SCM 120. In one embodiment, the cloud 130 may generate a new SCM-Equipment-Key key to be delivered to the SCM 120 as part of a new owner registration request response.

[0506] One or more devices 110 associated with and having authorization for the factory-reset SCM 120 may not receive any notification that the SCM 120 has been factory-reset. If at least one of the SCM-ID identifier or SCM-Key of the factory-reset SCM 120 is not changed, the cloud 130 may automatically revoke authorization for the user 10 in response to a new owner registration request for the SCM 120.

[0507] The SCM 120 may complete its manufacturing process in a factory reset mode, but the manufacturing process may load settings specific to a particular destination, such as an Equipment-Key or other configuration data. The SCM 120 may be included in the manufacturing process of the equipment components 140 to which the SCM 120 is coupled. During the equipment manufacturing process, the SCM 120 may be taken out of the factory reset mode, and the manufacturing equipment may be registered as the owner device 110 of the SCM 120. At the end of the equipment manufacturing process, ownership of the SCM 120 may be transferred to another device 110, or the SCM may be factory reset. The other device 110 may be associated with an OEM, a reseller, or a rental company.

[0508] At this stage of production, the SCM 120 may be transferred to other devices 110 and / or factory reset during the sales and distribution process. The SCM 120 may be commanded to be factory reset by the equipment component 140 to which it is coupled. The criteria by which the equipment component 140 determines the appropriateness of a factory reset of the SCM 120 may be useful to the overall security of the OEM system. For example, the equipment component 140 may verify that a user 10 requesting a factory reset is authorized to do so. Authorization may be based on one or more factors, such as ownership of the equipment component 140 or physical possession of the equipment component 140.

[0509] In one embodiment, the SCM 120 may be commanded to perform a factory reset directly or indirectly through one or more system components by the cloud 130. A direct command to perform a factory reset may be received if the SCM 120 is connected to the cloud 130. An indirect command to perform a factory reset may be received similar to the ACP 400 through one or more system components, such as from the cloud 130 to the device 110 to the SCM 120 or from the cloud 130 to the equipment component 140 to the SCM 120.

[0510] In one embodiment, the owner device 110 can command the SCM 120 to perform a factory reset. Alternatively, any device 110 may command the SCM 120 to perform a factory reset. Additionally or alternatively, any system component (including the SCM 120 itself) may command the SCM 120 to perform a factory reset, such as a user pressing a button on the SCM 120.

[0511] When the SCM 120 is in factory reset mode, there are no owner devices 110 for that SCM 120, but the SCM 120 can accept a new owner initiation request. The new owner initiation request can establish the first owner device 110 for the SCM 120 and can result in the generation and transfer of the first ACP 400 for the SCM 120, providing the SCM 120 with cloud keys (e.g., Cloud-SCM-Key, Cloud-SCM-Approval-Key, and ACP-Version-Key) and authorization and other configuration data. Registration of the SCM 120 and establishment of a new owner can be performed according to one or more of the following steps. 1) The device 110 can send a new owner initiation request to the SCM 120. 2) The SCM 120 may send its SCM-Key (public) key and SCM-ID identifier to the device 110 . 3) The device 110 can generate a new Device-SCM-Key public / private key pair. 4) The device 110 can send a new owner registration request to the cloud 130. The device 110 can send some or all of the following to the cloud 130 as part of the new owner registration request: Cloud-User-ID Identifier Device-SCM-Key (public) key ·SCM-Key (public) key · SCM-ID Identifier Device-ID Identifier Device-SCM-ID Identifier Other (e.g. Ethernet MAC, BLE UUID, APNS / GCM token) 5) The cloud 130 may register the device 110 and generate one or more of the following: Generate a new Cloud-SCM-Key public / private key (e.g. Cloud-SCM-Key and Cloud-SCM-Approval-Key) Generate a new ACP-Version-Key public / private key Generate a new User-SCM-Key public / private key Generate owner device authorization Generate the first ACP400 and distribute it 6) The cloud 130 may send the Cloud-SCM-Key (public) key to the device 110. 7) The cloud 130 can send the ACP container 410 (containing the first ACP) to the device 110. 8) The device 110 can transfer the ACP 400 to the SCM 120. 9) The SCM120 can now accept the ACP400 and exit factory reset mode.

[0512] After the SCM 120 has accepted its initial ACP 400 and exited factory reset mode, authorizations for additional devices 110 may be added normally.

[0513] In one embodiment, the SCM-ID may not be obtained over an insecure connection, and thus the SCM-Key may be used to establish the secure connection. Establishing a secure connection may be similar to the device / SCM connection establishment process starting from an unknown phase, after which the device 110 can request the SCM-ID from the SCM using the secure connection. XVI. Device / Cloud Communication – Server Side Authentication

[0514] In one embodiment, the communication channel between the device 110 and the cloud 130 may be secured, such as using TLS 1.2 or higher, with server-side (cloud) authentication based on certificates and cloud session tokens.

[0515] The application layer and / or application programming interfaces in the system 100 may be based on any combination of relevant standard technologies, such as HTTPS, Google Protocol Buffers, AMQP, MQQT, CoAP, TCP, and UDP. In one embodiment, each device 110 may have its own unique client certificate, and TLS mutual authentication may be performed based on this unique client certificate. In one embodiment, DTLS may be utilized instead of TLS. In one embodiment, raw asymmetric encryption may be used instead of TLS. In one embodiment, symmetric encryption may be used instead of TLS. In one embodiment, no secure communication channel is used. Messages that the device 110 receives from the cloud 130 for a particular SCM may be signed by the SCM's corresponding Cloud-SCM-Key. XVII. Cloud / Cloud Communication – Mutual Authentication

[0516] In one embodiment, communication channels utilized within cloud 130 (cloud-internal) and / or between cloud systems may be secured using TLS 1.2 or higher with mutual authentication using certificates.

[0517] The application layer and / or application programming interface may be based on any combination of relevant standard technologies, such as HTTPS, Google Protocol Buffers, AMQP, MQQT, CoAP, TCP, and UDP. In one embodiment, DTLS may be utilized instead of TLS. In one embodiment, raw asymmetric encryption may be used instead of TLS. In one embodiment, symmetric encryption may be used instead of TLS. In one embodiment, a secure communication channel is not used. XVIII. Equipment / SCM communication

[0518] The communication channel between the equipment component 140 and the SCM 120 may use raw asymmetric encryption to secure the communication. The asymmetric encryption may be based on the SCM-Equipment-Key and / or the Equipment-Key.

[0519] The application layer and / or application programming interfaces may be based on any combination of relevant standard technologies, including, for example, Google Protocol Buffers, CoAP, TCP, UDP, CAN, UART (possibly custom), SPI, and I2C. In one embodiment, TLS may be used with mutual or server-side authentication with certificates or asymmetric cryptography. In one embodiment, DTLS may be used with certificates or asymmetric cryptography. In one embodiment, symmetric cryptography may be used. In one embodiment, no secure communication channel is used.

[0520] As described herein, an SCM 120 may be an appliance for another SCM 120, establishing one or more inter-SCM communication channels for each SCM 120. Such a configuration may facilitate one or more of sharing of connections, authorization, and / or authentication activities between SCMs, load balancing (e.g., communication connections or computing resources), redundant / multi-factor verification / authentication of devices or other system components (e.g., other appliances), redundant / lock-step system execution and verification (e.g., cross-checking), and expansion of system control capabilities (e.g., more input / output ports or improved communication range). XEX.Time Delivery

[0521] One or more system components may utilize the current time to establish secure connections or to verify information, or both. The current time may be securely distributed or obtained from a trusted source. In one embodiment, the SCM 120 may obtain the current time from an equipment component 140 to which the SCM 120 is coupled. In one embodiment, the SCM 120 may obtain the current time from the device 110 (possibly with or without a secure communication channel). In one embodiment, the SCM 120 may obtain the current time from the cloud 130. In one embodiment, the device 110 may obtain the current time from the cloud 130. XX. Block Fan Rights Management

[0522] In one embodiment, the system 100 may utilize a Blockfan-based rights management system. Blockfan is identified as a blockchain-based rights management system in which each node can "fan" into a tree, as opposed to a traditional blockchain (where each node can have at most one parent and at most one child). Blockfan's tree structure may be used to manage and verify peer rights granted via parent permissions. For example, device 110 may be granted rights to access SCM 120 (parent permission) and, under the context of that right, may be granted rights to issue some commands (peer permission).

[0523] The chain structure of the block fan may be utilized to order the grants over time. In one embodiment, a Merkle tree may be used to verify the hash and / or signature of the nodes of the block fan (including the sibling nodes of the grant node to ensure that the token grant was not used multiple times). Thus, the Merkle tree may be used to verify the completeness, validity, and accuracy of the entire rights management system. A block fan-based rights management system may define token grants, where one-time use rights are granted for later use. For example, at some point in the future, a particular device 110 may want to take ownership of a particular SCM 120. The block fan may form a ledger. In other words, rights are never deleted, and all rights can be traced back to one or more grant roots. If a right cannot be traced back to the grant root, this is considered to indicate a validation failure.

[0524] Rights in the rights management system according to the illustrated embodiment of FIG. 15 may be defined in three components. 1) The right to take action as specified in § 1501. 2) A right that grants the right to perform an action, as specified in 1502. 3) A right that grants the right to perform an action, as specified in 1503. · Note that having the right to grant a right does not necessarily mean that the grantor can take action himself / herself. This right may include the right to grant this right to anyone else.

[0525] In one embodiment, a grantor cannot assign rights to himself, nor can a grantor who has been granted the right to grant the right to grant a right to grant a right to himself.

[0526] For example, the owner 10 of SCM 120 can grant another user 10 the right to grant the right to issue a particular command. That other user 10 can grant the other user 10 the right to issue a particular command, but that other user 10 cannot grant the other user the right to allow the other user 10 to issue a particular command. In the illustrated embodiment, only the owner of SCM 120 can do this.

[0527] In one embodiment, every grant may include the following information: ·action ·context ·Grantee A copy of the grantee's public key · What has been granted ·start date Expiration Date ·Parent grant ED Check value

[0528] This collection of information may be encrypted with the grantor's private key and may include the grantor's ED, grantee's ID, parent grant's ED, action, context, granted, start date, and end date. It should be understood that this disclosure is not limited to grants having all of the specified information, and that additional information may be included, and one or more of the specified information may not be present.

[0529] In one embodiment, via a join to a table of revoked rights, each right or grant can also include: · revoked parent ED · revoked value.

[0530] This collection may be encrypted with the revoker's private key and may include the revoker's ED, the revoked's ED, the revoked grant's ED, the action, the context, and the revoked status.

[0531] Signing and dating the issuance of the grant allows all rights grants to be traced back to the beginning of the system 100, allowing for validation of data within the system 100 during processing.

[0532] The types of rights listed below may be utilized in accordance with one embodiment of the present disclosure. Note that grants may have different models depending on the action. · Dependent. Dependent rights may expire when the grantor's rights granting the rights expire. This type of right may be used primarily for operational rights for SCM 120, and all such dependent rights may be revoked when SCM 120 is transferred or when SCM 120 is removed from ownership. · Independent. Independent rights may not require the grantor's rights granting the permissions to be valid after the time of grant. Tracking may still be possible through system 100 to ensure that the grantor's rights are valid at the time of grant. This type of right may be useful within an organization for administrative tasks. · Token. In one embodiment, token grants can only be used once. In one embodiment, token grants are the only rights in system 100 that cannot be used without side effects. Use of a token right may invalidate sibling tokens. Token rights may be used for transfer of SCM 120. · Immortal. The right to be immortal may be granted for the life of SCM 120 and may transcend ownership of SCM 120. The right to be immortal may only be granted to the OEM, if granted at all, and may represent a right to be included in all configurations made for the SCM 120 referenced by the immortal right.

[0533] In one embodiment, a block-fan based rights management system can be used to create rights management services in the cloud 130 that are used within this system 100 and security model (where the Device-Rights-Key references the corresponding node in the block-fan). XXI. Blacklist

[0534] In one embodiment, system 100 can be considered riddled with possible vulnerabilities. If there is no way to communicate, updates may not be delivered. The distributed nature of system 100 may make system 100 more tolerant of lack of connectivity than other systems 100. However, system 100 may not provide a substantially foolproof solution to this problem that an online system likely would not provide.

[0535] Authorization and configuration updates may be delivered to SCM 120 through other system components (e.g., device 110). If a system component cannot communicate with SCM 120 or obtain updates due to its own lack of connectivity, the system component may not deliver the updates to SCM 120. The failure to receive updates in a timely manner due to unintentional or intentional lack of connectivity is of particular concern with respect to revoking authorization.

[0536] Consider a scenario in which one user A revokes authorization of the SCM 120 of a device 110 belonging to user B, but user B wants to continue accessing the equipment component 140 to which the SCM 120 is attached (i.e., a "Crazy X" scenario). In this scenario, if user B disables the radio on his device 110, the device 110 cannot deliver an updated ACP 400 to the SCM 120 that revokes its authorization, and thus user B can continue to use the equipment component 140 associated with the SCM 120. The distributed nature of the system 100 may help to avoid this sequence, since any device 110 that has authorization for the SCM 120 can deliver the updated ACP 400. However, in this scenario, user A has only one nearby authorized device 110, and user B's device 110 is offline, but user A has access to the SCM 120 and the attached equipment component 140.

[0537] To provide a means for the equipment component 140 (and, on its behalf, the user 10) to revoke authorization locally, the SCM 120 may manage an authorization blacklist (the SCM blacklist). Assuming the equipment component 140 has a suitable user interface, the equipment component 140 may use the user interface to present a list of valid authorizations to user A, who may then add user B's authorization to the SCM 120 blacklist, at which point user B's authorization will be revoked locally and user B will no longer be able to access the equipment component 140 using the device 110 associated with user B.

[0538] Each entry in the blacklist of the SCM 120 may be a pair of an authentication and a unique Blacklist-Item-ED. In one embodiment, the Device-ID or the Device-SCM-ID may be used as the Blacklist-Item-ED.

[0539] When device 110 establishes a secure communications link with SCM 120 (at least in the secure phase, per the device / SCM connection establishment process), SCM 120 may send the blacklist package to device 110. SCM 120 may send the blacklist package to device 110 after processing an updated ACP 400, at some point after device 110 connects, or when SCM 120's blacklist changes.

[0540] The blacklist package is similar to the ACP container 410 in that the blacklist package may be a multi-layer encrypted package. The blacklist package may contain the current ACP version of the SCM 120 and may be signed and encrypted with an SCM-Key (private) key, which may then be signed and encrypted with a Cloud-SCM-Key (public) key. In one embodiment, the SCM 120 may send the blacklist package to another SCM 120 or another system component over any communication link. In one embodiment, the blacklist package may also be signed and encrypted with an ACP-Package-Version (public) key. In one embodiment, a system component other than the device component 140 may receive a list of valid authorizations and send the blacklisted authorizations to the SCM 120.

[0541] When the device 110 receives the blacklist package, the device 110 may send the blacklist package to the cloud 130 without modification (the device 110 may not be able to decrypt the blacklist package). The cloud 130 may perform one or more of the following: verify the blacklist package, apply any revocations listed in the blacklist package, and notify the owner device 110 of the SCM 120 that an updated ACP 400 is available for approval. The ACP 400 may include Blacklist-Item-IDs that have been processed since the cloud 130 last received confirmation that the configuration was delivered to the SCM 120. For example, the ACP blacklist may be increased until confirmation is received that the contents of the blacklist have been processed, at which point the blacklist may be decreased. If the updated ACP 400 is not acceptable to the owner 10, the owner 10 may modify the ACP 400 until the ACP 400 meets approval.

[0542] When device 110 delivers an updated ACP 400 to SCM 120, SCM 120 may process the ACP 400 blacklist by removing Blacklist-Item-IDs that are present in both the SCM 120 blacklist and the ACP 400 blacklist. The presence of Blacklist-Item-ED in the ACP 400 blacklist may represent a decision of owner device 110 to include the Blacklist-Item-ID in the ACP 400 (whether owner device 110 has decided to retain or revoke the corresponding authorization). XXII. Central System Log

[0543] In one embodiment, to provide information that can assist in detecting and analyzing attacks against system 100 or specific system components (including users 10), or analyzing system performance and operation, cloud 130 may manage a secure, centralized system log, defined as a central system log, that can store (i.e., log) information from events that occur across all or some components of system 100. Such events may include events that occur on cloud 130 itself.

[0544] Each system component may maintain a system log in which it can store (i.e., log) information about local events encountered by the system component. The information stored in a component's system log, and the location where the system log is stored, may be configurable (at implementation, configuration, or run-time) and may change with system state. The changes may occur automatically and / or manually, such as when commanded to do so by another system component.

[0545] System components may log events to a central system log, or to RAM, ROM, other system components, or one or more communication links, diagnostic / debug ports, and / or physical media via real-time, batch, or deliverable system log packages. System log packages may be delivered to other system components (e.g., device 110, equipment 140, SCM 120, etc.) for transmission to cloud 130 (e.g., SCM 120 may deliver SCM 120 system log packages to devices for transmission to the cloud). Alternatively, system log packages may be sent directly to cloud 130, similar to blacklist packages. Depending on how the system log packages are encrypted, system log packages may be delivered via any communication channel. Real-time and batch logs in one embodiment may only be sent to cloud 130 via secure communication links. In one embodiment, system log packages may only be sent via secure communication channels.

[0546] In one embodiment, there may be no central system log; instead, each system component may create and manage its own system log. XXIII. Use Case Examples

[0547] It should be understood that one or more embodiments of the present disclosure may be implemented in connection with a variety of applications, and the present disclosure is not limited to the particular applications described herein. For purposes of the disclosure, some use cases or applications, including use cases that may be combined with a microlocation system, are identified as follows: 1) Automobiles ·Passenger / Light Truck ·bus ·long haul Local delivery · All-purpose / Specialized RV Ride sharing ·rental ·dealer Shared access 2) Heavy machinery (bulldozers) 3) Agricultural machinery (John Deere, Kubota) 4) Motorcycles (and four-wheelers, three-wheelers, and snowmobiles) 5) By Plane ·General aviation ·Commercial ·Military 6) Ship Personal watercraft Boats (residential) / Yachts ·Commercial ·Cargo ship 7) Door lock ·Residential & Commercial ·Hotels / Rentals · Secure and controlled access 8) Office Equipment and Automation ·Conference room facilities -Safe button (separate patent available) ·automation 9) Office furniture Space Utilization Open Desk Customize your space Mobile equipment Adjustable chair Brody Chair ·display 10) Conference Events · Entry into a session (against tag scanning) Where is my seat / Am I in the right seat? 11) Theme parks (Disney, Six Flags) 12) Hospital Access to rooms and facilities Who is in which room? · RTLS (Real-time Location System) - Track things 13) Retail (stores) 14) Industrial Equipment / Manufacturing Automation (large and expensive) 15) Vending Machines 16) Restaurant · Waiter / Manager Which tables ordered which foods Order from the table, get yours 17) Computer monitors / laptops

[0548] One or more embodiments described herein provide several advantages over conventional systems.

[0549] Directional terms such as "vertical," "horizontal," "top," "bottom," "upper," "lower," "inner," "inwardly," "outer," and "outwardly" are used to help describe the invention based on the orientation of the illustrated embodiments. The use of the directional terms should not be construed as limiting the invention to any particular orientation.

[0550] The above description is a description of the current embodiment of the invention. Various modifications and changes may be made without departing from the spirit and broad aspects of the invention as defined in the appended claims, which are to be interpreted in accordance with the principles of patent law, including the doctrine of equivalents. The present disclosure has been presented for illustrative purposes and should not be construed as a comprehensive description of all embodiments of the invention or to limit the claims to the specific elements shown or described in connection with these embodiments. For example, but not by way of limitation, any individual element of the described invention can be replaced by an alternative element that provides substantially similar functionality or otherwise operates appropriately. This includes, for example, currently known alternative elements, as currently known to those of skill in the art, and alternative elements developed in the future that would be recognized as alternative elements by those of skill in the art at the time of development. Furthermore, the disclosed embodiments include multiple features that are described together and cooperate to provide a collection of advantages. The invention is not limited to only those embodiments that include all of these features or provide all of the advantages described, unless expressly set forth in the issued claims. For example, a reference to a claim element in the singular form, using the articles "a," "an," "the," or "said," should not be construed as limiting the element to the singular. Reference to a claim element as "at least one of X, Y, and Z" is meant to include an...

Claims

1. A control unit in communication with a vehicle equipment component, comprising: a communication interface operable to wirelessly communicate with a remote device; an equipment interface operable to communicate with the vehicle equipment component; a controller configured to establish a communication link with the remote device via the communication interface. the controller is configured to receive authorization setting information from the remote device via the communication link; The control unit receives commands from the remote device related to vehicle operation and approves actions based on the commands received from the remote device based on authorization of the remote device; A control unit, wherein the authorization setting information includes an authorization type related to an access attribute which is a restriction of authority to the remote device, and commands or functions that can be accessed vary depending on the authorization type.

2. The control unit of claim 1 , wherein the authorization configuration information includes encrypted data, and the controller is capable of decrypting the encrypted data.

3. 1. A method for obtaining authorization settings information for a remote device in a control unit in communication with a vehicle equipment component, comprising: wirelessly communicating with the remote device; establishing a communications link with the remote device via wireless communication; receiving the authorization configuration information from the remote device over the communications link; the control unit receiving commands from the remote device related to vehicle operation and approving actions based on the commands received from the remote device based on authorization of the remote device; The authorization setting information includes an authorization type related to an access attribute that is a restriction of authority to the remote device, and a command or function that can be accessed varies depending on the authorization type.

4. The method of claim 3 , wherein the authorization setting information includes encrypted data, and the control unit is capable of decrypting the encrypted data.

Images