Systems and methods for authenticating and authorizing devices

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] This application relates to systems and methods for authenticating and authorizing devices and / or for distributing keys.

Background Art

[0002] Considerable efforts have been made to enable smartphones to be used as keys for instructing access to and operation of device devices such as doors and vehicles. However, these conventional systems rely on a simple form of security that depends on a device device having network access to authenticate whether a smartphone has the authority to instruct the operation of the device device. Such conventional device devices cannot authenticate and / or authorize at least one of the key, device, and user when the authorization device has not previously communicated with the device device to identify the key, device, or user's authority. In other words, when there is no communication link between the authorization device and the device device, i.e., when connectivity is lacking, the device device of this conventional system cannot determine whether the smartphone attempting to communicate with the device device is authorized by the authorization device.

[0003] In a conventional key fob system used by vehicle manufacturers, the authentication information of the key and / or key fob is distributed to the authorization device before the key fob is authenticated and / or authorized, and the authorization device can send the authorization information to the device device.

[0004] Similar traditional systems may rely on device-based systems that can communicate with a cloud system (or other system components unreachable due to lack of connectivity) during authentication and / or authorization processes, and therefore, when the communication link is absent, it may be impossible to authenticate and / or authorize keys, devices, or users. This scenario (lack of connectivity) may seem unusual. However, consider a car parked in a parking lot, remote location, or woods cottage without cellular connectivity, and it is actually quite common. A lack of connectivity in such a situation can prevent granting a smartphone or other device permission to operate the car or access the cottage. [Overview of the project]

[0005] This disclosure relates primarily to a system and method for a distributed security model that can be used to achieve one or more of the following: authenticating system components, securely transferring messages between system components, establishing secure communication channels via constrained links, authenticating message content, authorizing actions, and delivering authorization and configuration data within 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 the following: portable devices, cloud or network servers or systems, hardware, modification, and revocation.

[0007] In one embodiment, the system can enable the secure and confidential transfer of information between system components. In one embodiment, end-to-end encryption may be provided across all communication links. The system can form a distributed system in which some data may be transmitted over an unencrypted channel, but the data itself is fully encrypted.

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

[0009] A system according to one embodiment can facilitate authorization and the delivery of one or more related features, including the generation of new keys, identification of modified keys, blacklist / revocation notifications, key cycling, ownership transfer, reset, roots of trust in settings, keys, and other data.

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

[0011] In one embodiment, the system can provide a key attribute authorization model in which each authorization has one or more attributes that are considered necessary to identify that authorization as active. Examples of such one or more attributes include time, usage count, location, and custom attributes.

[0012] One embodiment of the system is useful for a shared model in which authorization is provided and granted per device, per device + account, and / or per account (even at the organization level, for example).

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

[0014] A system according to one embodiment can enable authentication and authorization between devices, even on first encounter, without a practical internet connection.

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

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

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

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

[0019] The first device can communicate authorization configuration information to the second device via a communication link. The first device can also communicate command information regarding requests to execute commands via the communication link. Based on the authorization configuration information, the second device can authenticate the identity of the first device and determine whether the first device is authorized to issue commands to the second device.

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

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

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

[0023] A method for communication between a first device and a second device is provided according to one embodiment. The method may include the first device obtaining authorization configuration information from a network server, the authorization configuration information including data encrypted with a first key associated with the second device. The method may also include establishing a communication link for exchanging communications between the first device and the second device, wherein the second device has not received any information indicating that the first device has obtained the authorization configuration information before establishing the communication link.

[0024] The method may include receiving authorization configuration information on the second device, and decrypting the authorization configuration information on the second device in order to obtain device keys and authorization data related to one or more authorizations for the first device to instruct the operation of the second device.

[0025] The second device can authenticate the identity of the first device based on a device key obtained from the authorization setting information and receive a command from the first device.

[0026] The method can include determining whether the first device has the authority to issue a command, and instructing the device component to execute the command in response to determining that the first device has the authority to issue the command.

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

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

[0029] Before the embodiments of the present invention are described in detail, it should be understood that the present invention is not limited to the details of the operations of the components described in the following description or shown in the drawings, or to the details of the configuration and arrangement. The present invention can be implemented in various other embodiments and can be implemented or executed in other ways not explicitly disclosed herein. Also, it should be understood that the expressions and terms used herein are for the purpose of description and should not be regarded as limiting. The use of "including" and "comprising" and their variants means including the items listed hereinafter and their equivalents, as well as additional items and their equivalents. Further, enumeration may be used in the description of various embodiments. Unless otherwise specified, the use of enumeration should not be construed as limiting the present invention to a particular order or number of components. Also, the use of enumeration should not be construed as excluding from the scope of the present invention any additional steps or components that can be combined with the enumerated steps or components, or within the components.

Brief Description of the Drawings

[0030] [Figure 1] FIG. 1 is a representative diagram of a system according to an embodiment.

[0031] [Figure 2] FIG. 2 is a representative diagram of system components in an embodiment.

[0032] [Figure 3] FIG. 3 shows a micro-location system according to an embodiment.

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

[0034] [Figure 5]Figure 5 shows an ACP container and an ACP container version package according to one embodiment.

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

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

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

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

[0039] [Figure 10] Figure 10 shows a method for generating a user account according to one embodiment.

[0040] [Figure 11] Figure 11A-B is a representative diagram of data distribution according to one embodiment.

[0041] [Figure 12] Figure 12 shows a method for circulating keys according to one embodiment.

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

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

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

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

[0046] [Figure 17] Figure 17 shows a typical diagram of a system according to one embodiment. [Modes for carrying out the invention]

[0047] This disclosure relates to a system and method for a distributed security model that can be used to achieve one or more of the following: authenticating system components, securely transferring messages between system components, establishing secure communication channels via constrained links, authenticating message content, authorizing actions, and delivering authorization and configuration data within user system components in a device-as-a-key system. One or more parts of the system can be implemented together with one or more parts of a microlocation system described in U.S. Patent Application No. 14 / 620959 by J. Michael Ellis et al., filed on 12 February 2015 and issued as U.S. Patent No. 9666005, entitled “System and Method for Communicating with a Vehicle,” and U.S. Patent Application No. 15 / 488136 by Raymond Michael Stitt, filed on 14 April 2017 and issued as U.S. Patent No. 9794753, entitled “System and Method for Establishing a Real-Time Location.” These disclosures are incorporated herein in their entirety, and the hardware may be a monitor or master device, resulting in authentication, authorization, and location-verified portable devices interacting with other systems using (secure, trusted, and confidential) end-to-end encryption. I. System Architecture

[0048] A system according to one embodiment is shown in Figures 1 and 17 and is collectively designated as 100. System 100 may consist 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., smartphones, cards or fobs, or a combination thereof) and / or fixed devices (e.g., computers / servers, wall-mounted panels / displays, or a combination thereof), c) one or more system control modules (SCMs) 120, also referred to as hardware, d) a cloud 130 (e.g., a collection of clouds) which may include a collection of one or more backend servers or computers from one or more vendors, and e) one or more equipment components 140 which may be configured to control the operation of equipment, start services, relay information to another part of System 100, or retrieve information from another part of System 100, or a combination thereof. In the illustrated embodiment, the cloud 130 and / or equipment 140 are optional.

[0049] System 100 can enable one or more users 10 to interact with or access equipment 140 using device 110. Device 110 can communicate with equipment 140 (such as a vehicle, lock, or table) by communicating with SCM 120. In one embodiment, SCM 120 can authenticate device 110, provide or receive configuration data, authorize actions (e.g., connecting, or sending and / or receiving requests, commands, updates, or responses, or combinations thereof), or communicate with equipment components or perform combinations thereof to achieve desired actions. Device 110 can communicate with Cloud 130 to obtain, modify, or deliver authorization and other configuration data (as described herein) or combinations thereof with the relevant devices and users. There are interactions with other systems that are less relevant to the security model but are not shown or described in further detail for the purposes of disclosure. For example, there are factory tools that communicate with SCM 120 and Cloud 130, which are capable of interacting with other systems clouds. A. Overview of communications and interactions

[0050] The communication links between one or more system components shown in the embodiment illustrated in Figure 1 may be wireless, 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 system components, including embodiments where the number is zero, such as when there is no cloud and / or equipment.

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

[0052] The system 100 in the illustrated embodiment may include one or more system components as outlined herein. The system component may be a user or an electronic system component, and may be device 110, SCM 120, equipment component 140, and cloud 130, or a combination thereof. As discussed herein, the electronic system component may be configured to operate as any one or more of those devices. In this sense, in one embodiment, there may be several aspects or features common to device 110, SCM 120, equipment component 140, and cloud 130. For the purposes of disclosure, these features will be described in relation to the electronic component shown in Figure 2 and designated collectively as 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 running 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 / electronic equipment via the communication units 214. The electronic system component 200 may or may not have a hardware-based encryption unit 222; if not present, the encryption function may be performed in software. The electronic system component 200 may or may not have (or access to) a secure memory unit 220 (e.g., a secure element or hardware security module (HSM)). Optional components and communication paths are shown by dashed lines in the illustrated embodiments.

[0054] The system 100 of the illustrated embodiment does not depend on the presence of a secure memory unit 220 in any component. If the secure memory unit 220 is optionally absent, the data stored in the secure memory unit 220 (e.g., private keys and / or secret keys) may be encrypted in quiescent mode (when possible). Both software-based and hardware-based countermeasures can be used to substantially prevent access to such data, and to substantially prevent or detect the incurrence of security breaches to the overall system components, or both. Examples of such countermeasures include implementing physical obstacles or shields, disabling JTAG and other ports, strengthening software interfaces to eliminate attack vectors, using a trusted execution environment (hardware or software, or both), and detecting the incurrence of root access or security breaches to the operating system.

[0055] For the purposes of disclosure, security is generally understood to mean being secret (encrypted), authenticated, and verified for integrity. However, this disclosure is not limited to these, and the term “security” 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, internal, or both communication. For example, the communication interface 214 can provide a wireless communication link with another system electronic device 200 in the form of device 110, such as a cloud 130 via a wireless communication link, such as a Bluetooth® low-energy standard or a Wi-Fi Ethernet® communication link. In another example, the communication interface 214 can be configured to communicate with equipment components 140 (e.g., vehicle components) via a wired link, such as a CAN-based wired network, to facilitate communication between multiple devices. In one embodiment, the communication interface 214 may include a display and / or input interface for communicating information to and / or receiving information from user 10.

[0057] In one embodiment shown in Figure 2, the electronic system component 200 may be configured to communicate with another electronic system component 200 or one or more auxiliary devices 300 other than the user. The auxiliary devices 300 may be configured differently from the electronic system component 200. For example, the auxiliary device 300 may not include a processor 210 and instead include at least one direct connection and / or communication interface for sending and receiving information with or receiving information from the electronic system component 200, or both. 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 in the illustrated embodiment may be configured to determine location information for device 110 in real time. In the illustrated embodiment of Figure 1, user 10 may carry device 110 (e.g., a smartphone). The system 100 can facilitate the location of device 110 relative to equipment 140 (e.g., a vehicle) in real time with sufficient accuracy to determine whether the user is located in a position where access to the equipment or authorization of equipment commands should be granted.

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

[0060] The vehicle in this scenario may also include other types of equipment 140, such as one or more sensors similar to the remote device 310, as described in relation to the illustrated embodiment in Figure 3 and shown in Figures 16 and 17 together with the sensor and sensor hub configuration. The equipment 140 forming the sensor and sensor hub configuration in Figure 16 may include one or more keys as described herein to facilitate authentication of information received from the sensors and sensor hub. Note that one or more keys may be incorporated into the system 100 for use with the sensors or remote device 310 and / or sensor hub. One or more additional keys, similar in structure to the equipment devices or other components of the system 100, may reside in the SCM 120 and the sensors / sensor hubs in the sensor network. In addition, 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 sensors / sensor hubs in the sensor network and authorize their participation.

[0061] The microlocation of device 140 can be determined in various ways, including using information obtained from the Global Positioning System, one or more signal characteristics of communications from device 110, and one or more sensors (e.g., proximity sensors, limit switches, or vision sensors), or a combination thereof. An example of a microlocation technique that can constitute system 100 is described in U.S. Patent Application No. 15 / 488136 filed on April 14, 2017, entitled “System and Method for Establishing Real-Time Location,” the disclosure of which is incorporated herein by reference in whole. More specifically, in an example depicted in the illustrated embodiment of Figure 3, the SCM 120 and a plurality of remote devices 310 (similar in some respects to device 110) can be positioned in fixed locations relative to the device component 140. Exemplary use cases of the device component 140 include the vehicles identified in the preceding examples, or buildings whose access is controlled by the device component 140.

[0062] Device 110 can communicate wirelessly with SCM 120 via a communication link (for example, via Bluetooth Low Energy). Multiple remote devices 310 may be configured to intercept communication between device 110 and SCM 120 and determine one or more signal characteristics of the communication, such as signal strength. The determined signal characteristics may be communicated to SCM 120 via a communication link separate from the communication link between device 110 and SCM 120, or communicated after being analyzed. Additionally or alternatively, device 110 may establish a direct communication link with one or more remote devices 310, and one or more signal characteristics may be determined based on this direct communication link.

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

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

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

[0066] A security model, as described herein, can be utilized to facilitate one or more of the following: system 100, authenticating system components, securely transferring messages between system components, establishing secure communication channels via constrained links, authenticating message content, approving actions, and distributing approval and configuration data within user system components in a device-as-a-key system. II. Approval

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

[0068] In one embodiment, a key (certificate of credit or virtual / electronic / mobile key) is delivered to device 110, and the key is passed to SCM 120 for verification (or several variations thereof) when in use.

[0069] In the illustrated embodiment of System 100, the device 110 itself (its identity) is the key, and the SCM 120 can authorize a desired action of the device 110 based on one or more authorizations that the SCM 120 can set up for the device 110. The “identity” of the device 110 may be (or be based on) one or more cryptographic identities or any other identifiers unique to the device 110, or a combination thereof and / or any combination thereof. Examples of cryptographic identifiers include unique public / private keys, such as a key pair generated with asymmetric cryptography, and shared secret keys, 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 a cryptographic identity and a non-cryptographic identity.

[0070] Device 110 may have zero or more authorizations at any given time, including multiple authorizations for the same SCM 120 or different authorizations for different SCM 120s. Authorization is a useful part of the security model described herein because it provides information that can facilitate one or more of the following: enabling Device 110 to communicate with SCM 120, mutually authenticating multiple Device 110s and multiple SCM 120s, and identifying the conditions under which Device 110 can interact with SCM 120. In addition to useful information for authentication, authorization can define access attributes for each Device 110 to SCM 120. Access attributes according to one embodiment may include one or more of the following: 1) Type (e.g., Owner, Guest, Bullet, etc.) - Standard. Various authorization types result in different authorization distribution / sharing permissions (e.g., an Owner can make another device an Owner, but not a Guest, etc.). There may be commands or other system-level functions 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, authorization may be automatically revoked at a specific date / time. 4) Valid schedule - Optional. If present, authorization may only be used for defined schedules (e.g., each day of the week, a monthly schedule, or a custom schedule that specifies when it will be used, or a recurring weekly schedule). 5) Number of valid uses - Optional. If present, the authorization can only be used up to the set number of times (e.g., number of commands, number of days / hours 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 / thumbprint / request for the presence of another device to issue a specific command). 7) Distribution Rights - Optional. If present, the authorization authority in the rights management service (see description herein) identifies and / or describes the rights held by device 110 in order to issue a new authorization to another device 110 for SCM 120. In other words, distribution rights relate to device 110's right to share authorizations with other devices. If not present, it may be based entirely or partially on the authorization types described in at least paragraph 1) and section VII. In alternative embodiments, both authorization types and digital rights management services may be used together, for example, by performing cross-checks. 8) Command Rights – Optional. If present, this refers to authorization rights in a rights management service (see description herein) that identify and / or describe the rights that device 110 has to issue, receive, or both, certain commands and / or responses. For example, device 110 can issue a command to open a door, but cannot close it. Rights may be granted on a per-command or per-class basis. If not present, command rights may be based entirely or partially on authorization types as described in at least paragraph 1) and section VII. In alternative embodiments, both authorization types and digital rights management services may be used together, for example, by performing cross-checks. In another alternative embodiment, a list of authorized commands (and other potentially necessary metadata) may be provided instead. In yet another alternative embodiment, a list of prohibited commands (and other potentially necessary metadata) may be provided instead. 9) Other possible attributes that the SCM120 may permit or deny interaction with. In one embodiment, device 110 can communicate securely with the SCM120 only when device 110 possesses authorization for such secure communication, but it should be understood that there may be scenarios or situations in which device 110 may engage in insecure communication with the SCM120.

[0071] It should be noted that not all attributes need to be communicated to SCM120 or device 110. For example, some attributes may only exist within cloud 130.

[0072] SCM120 may authorize device 110 to send or receive one or more of the following: requests, commands, updates, and responses, or both, based on at least one of the following: 1) One or more authorizations are recognized (see, for example, at least Section III of the ACP). 2) In one or more certified licenses, all or some of the potentially required conditions are met. 3) Device 110 is authenticated. Thus, in addition to the above conditions, each authorization may include an encryption key (e.g., Device-SCM-Key and / or User-SCM-Key) and data used by device 110 to establish an encrypted communication link with target SCM 120, by device 110 to authenticate target SCM 120, and by target SCM 120 to authenticate device 110. The data used for device 110 in such a situation is described in more detail in the system key description section, which is also identified as the key system in section XII. III. Approval Package

[0073] In one embodiment, information can be communicated securely to the SCM 120 via an authorization configuration package (ACP) designated 400, as shown in one embodiment of Figure 4. The ACP 400 may include authorization or other configuration data, or both, that can be sent to the SCM 120. One or more devices 110 may send the ACP 400 to the SCM 120, but the ACP 400 may also be sent to the SCM via other devices, and it should be understood that this disclosure is not limited to transmission via devices 110.

[0074] The ACP 400 can be encapsulated in an ACP container 410, which can be encapsulated within an ACP container collection 414, as shown according to one embodiment in Figure 5. The ACP 400, the ACP container 410, or the ACP container collection 414, or any combination thereof, may be based on sequenced multilayer encryption. The ACP container 410 may include nested layers, each layer may be encrypted in a different way, such as by encrypting each layer according to a different cryptographic key. In this way, the nested layers can be conceptualized as layers of an onion, and 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 to the SCM 120 via a distributed system. In the illustrated embodiment, the ACP container 410 may be distributed to the device 110 by the cloud 130. The ACP container 410 can utilize sequenced multilayer encryption in a manner that provides one or more of the following: Substantially guaranteed confidentiality and integrity, regardless of device or communication security (e.g., insecure devices using insecure communication links). Substantially guaranteed authenticity and approval of the contents of ACP400 by multiple certified system components (e.g., owner device 110, its users, and one or more cloud services 130, including, for example, two or more cloud services 130, where separate cloud authorization requests and cloud authorization approval services are used as described herein). • A substantial guarantee that the ACP400 is intended for the target SCM120 and that other system components cannot decipher the unauthorized contents of the ACP400. • Substantial guarantee of the state of System 100 (e.g., that the appropriate system components have approved the configuration in the defined order). Even if the target SCM120 has never communicated with the device 110 before, authorization may be performed using only the communication link between the device 110 and the target SCM120 (for example, authentication may be performed when disconnected from the internet, when neither the device 110 nor the SCM120 is accessing any cloud service 130, in other words, when both the device 110 and the SCM are offline).

[0076] Together with the authorization change process and package layer encryption sequence performed by Cloud 130, the structure of the ACP container 410 ensures that only Target SCM 120 can decrypt the entire ACP container 410, and that multiple system components (e.g., User 10, Cloud 130, and Owner Device 110, or a combination thereof) have authorized the ACP 400. The encryption sequence of the ACP container 410, from the innermost layer (last to be decrypted) to the outermost layer (first to be decrypted), will be described in more detail later. The structure of the ACP container 410 may vary depending on the application. However, in the illustrated embodiment, the ACP container 410 may include at least one of an integrity hash (e.g., a cryptographic hash and / or signature), a timestamp, a version, a transmitter identity, a receiver identity, and other data locations and encapsulation attributes (not shown in Figure 4 or 5).

[0077] After all necessary authorized layers have been decrypted, authenticated, and integrity verified, and attributes have been checked across multiple layers for integrity, the ACP container 410 or any of its layers (including ACP400) is processed and / or stored by the SCM120. In the illustrated embodiment, the SCM120 is authorized to process and decrypt all layers of the ACP container 410, but it should be understood that there may be further layers of the ACP container 410 that the SCM120 is not authorized to process or decrypt, or is not configured to process or decrypt. Although the ACP container 410 is described herein as having a number of layers, it should also be noted that the number of layers and configuration or structure of the ACP container may be modified depending on the application. Any part of the ACP container 410 (including ACP400) may be stored, but it should also be understood that such layers may be stored as the received (encrypted) format, as the received but decrypted format, in an alternative format (e.g., optimized for storage efficiency or runtime retrieval), or in any combination thereof. A.ACP outer layer 1

[0078] In the embodiment shown in Figure 4, the ACP 400 is contained within the ACP outer layer 1 designated by 401. The ACP outer layer 1 can verify that the ACP 400 originates from the cloud 130 and is directed toward the target SCM 120. The cloud 130 can encrypt the ACP outer layer 1 with a key that may be specific to the pair defined by the target SCM 120 and the cloud 130 (such as the Cloud-SCM-Key key, which is described in more detail in at least Section XII of this specification). In one embodiment, optionally, only the cloud 130, the target SCM 120, and the device 110 authorized to the target SCM 120 may be able to decrypt the ACP outer layer 1.

[0079] In an alternative embodiment, the key used 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 SCM 120s in a system of multiple SCM 120s may be used. In one embodiment, if a Cloud-SCM-Key key does not exist, verification that the ACP originates from the cloud 130 and is directed to the target SCM 120 can be achieved in a way that is not limited to the use of a Cloud-SCM-Key. In an alternative embodiment, system 100 may not rely on verification of the ACP outer layer 1 based on a Cloud-SCM-Key, and instead may rely on encryption and sequencing of other layers or authentication of the cloud 130 (as described herein). B.ACP outer layer 2

[0080] In the illustrated embodiment of Figure 4, the ACP outer layer 1 is contained within the ACP outer layer 2, designated 402. The ACP outer layer 2 can verify that the ACP 400 (originating from the cloud 130) for the target SCM 120 has been verified and authorized by user 10 on the owner device 110 for the target SCM 120. The user account service of the cloud 130 may encrypt the ACP outer layer 2 with a key such as a User-SCM-Key key, which is described in more detail in at least Section XII of this specification, and which may be unique to a pair defined by the user account associated with the target SCM 120 and device 110. In one embodiment, authorization may be issued to a 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 device 110 associated with a user account authorized to use ACP400 can decrypt the ACP outer layer 2.

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

[0083] In an alternative embodiment, 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 the device 110 or user account. For example, a common key shared among all SCM 120s in a system of multiple SCM 120s may be used. 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 verified and approved by the user 10 of the owner device 110 for the target SCM 120 can be achieved in an alternative way that is not limited to the use of the Cloud-SCM-Key. In an alternative embodiment, the system 100 does not have to rely on verification of the ACP outer layer 2 based on the Cloud-SCM-Key or User-SCM-Key, and instead may rely on encryption and sequencing of other layers or cloud authentication (as described herein). C.ACP outer layer 3

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

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

[0086] In the illustrated embodiment of Figure 4, the ACP outer layer 3 is contained within the ACP outer layer 4 designated by 404. The ACP outer layer 4 can verify that the completed ACP container 410 originates from the cloud 130, is approved by the cloud 130, and is directed toward the target SCM 120. The cloud 130 may encrypt the ACP outer layer 4 with a key such as the Cloud-SCM-Approval-Key key, which is described in more detail herein at least in Section XII, and which may be specific to the pair defined by the target SCM 120 and the cloud 130. In one embodiment, optionally, only the cloud 130, the target SCM 120, and a device 110 authorized for the target SCM 120 can decrypt the ACP outer layer 4.

[0087] In one embodiment, since the cloud authorization request and the cloud authorization approval service cannot be separated, the ACP outer layer 4 may be encrypted with a Cloud-SCM-Key key, which is described in more detail herein in Section XII, and 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 SCM 120s in a system of multiple SCM 120s may be used. In one embodiment, if the Cloud-SCM-Approval-Key or Cloud-SCM-Key key is not different from the SCM-Key key, or if the Cloud-SCM-Approval-Key or Cloud-SCM-Key does not exist, verification that the completed ACP container 410 originates from the cloud 130, is approved by the cloud 130, and is directed to the target SCM 120 may be achieved in another way. In an alternative embodiment, the system 100 does not have to utilize verification of the ACP outer layer 4 based on the Cloud-SCM-Approval-Key or Cloud-SCM-Key, and instead may rely on encryption and sequencing of other layers or cloud authentication (as described herein).

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

[0090] One configuration example to approximate the separation of authentication and authorization is to separate a) a service that generates the initial ACP400 and requests user 10 to approve the ACP400 (Cloud Authorization Request Service) and b) a service that user 10 approves the initial ACP400 and generates the final ACP container 410 (Cloud Authorization Approval Service). 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 from 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 ACP outer layer 4, such as the Cloud Authorization Approval Service, resides on a different server from the cloud service 130 that signs ACP outer layer 1, such as the Cloud Authorization Request Service. IV. Delivery of ACP containers

[0091] In one embodiment, the ACP container 410 may contain all current authorizations for the target SCM 120. The cloud 130 can generate and / or update a complete (i.e., not a partial update) ACP container 410 whenever the data contained within the ACP 400 for the SCM 120 changes via a push mechanism, and automatically distribute it to all relevant devices 110. Examples of changes include a) data and authorizations in the ACP 400 with at least one of the following added, modified, and revoked for the SCM 120, b) the SCM 120 being instructed to be factory reset, c) the first authorized owner device, and d) a circulated cryptographic key. A. Pushing ACP containers

[0092] The push mechanism may be used for the delivery of all ACP containers 410, or the use of the push mechanism may be limited to the delivery of ACP containers 410 in response to specific changes and / or events. A related device 110 may be considered a device 110 that has current authorizations, or previously had one or more authorizations, but has not yet received an updated ACP container 410 for the target SCM 120 (e.g., SCM 120 has a newer ACP 400). Current authorizations are authorizations that have not been revoked (i.e., removed, invalidated, or deleted) and have not expired (i.e., are valid authorizations). The push mechanisms used 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), device-to-cloud connectivity based on persistent polling or long polling or similar device-to-cloud connectivity, device-to-device messaging in mesh, star, and / or other topologies, and SMS, and may be modified based on the type of device 110.

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

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

[0095] Device 110 can automatically request currently approved ACP400s from Cloud 130 for SCM120 (or for all SCM120s for which Device 110 has current authorization) when a specific event occurs. Exemplary events include when an application changes its execution state (e.g., start, pause, resume, stop, or terminate), or when a connection to SCM120 and / or Cloud 130 is established periodically, or when requested by a user, a reset immediately thereafter. 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 placed in an environment where a communication link to the cloud 130 is unavailable. For example, the communication link may not exist, or may be unavailable by any means, including indirectly through other system components, such as routing the communication link through another device or equipment component 140. Such lack of a communication link may be permanent or temporary.

[0097] In one embodiment, the security model of system 100 is not significantly affected by a lack of communication, primarily because it is not strictly required that SCM 120 communicated with cloud 130 before authorizing device 110. SCM 120 only needs to expect that device 110 communicated with cloud 130 at some point before communicating with SCM 120. One problem that may arise in this situation is that if SCM 120 does not remember the ACP 400 containing the authorization for device 110, SCM 120 may not be able to establish a secure communication link with device 110. However, the ACP container 410 may be sent to SCM 120 via an insecure communication link, at least partially due to cryptographic sequencing or layering of the ACP container 410, or both, and because the ACP container 410 is only decrypted by the target SCM. Thus, SCM120 may receive updated ACP400 from any source via any communication link, including from devices 110 with which SCM120 has never communicated, and from devices 110 (or other system components / sources) that do not possess authorization. For example, a device 110 whose authorization has been revoked may communicate an ACP container 410 containing the updated ACP400.

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

[0099] To facilitate the elimination of the need for the SCM 120 to receive and process the ACP container 410 on all connections from all devices 110 in order to determine whether device 110 has a different ACP 400, the first N bytes of the ACP container 410 (where N is the number of bytes required to obtain the required information, also known herein as the ACP container version package 412) may be transmitted as part of the connection establishment process between device 110 and SCM 120 (as described herein), which SCM 120 can decode to obtain the required information, which may include the ACP version and / or other attributes used for comparison, such as the integrity hash or signature, or both. In one embodiment, as described herein, the ACP container version package 412 is delivered to device 110 as the first N bytes of the ACP container 410 (where N is the number of bytes considered required to obtain the required information). If SCM120 determines that device 110 has a newer version of ACP400, SCM120 may utilize device 110 to provide the updated ACP400 before a secure connection is established. In an alternative embodiment, SCM120 may decide to perform an ACP update process if device 110 has a different ACP400, which may not be newer than the ACP400 stored in SCM120. If SCM120 is not in factory reset mode, waiting for the first owner device 110 associated with SCM120, and no ACP container version package 412 is provided, the connection to device 110 may be refused, terminated, or both. The operation of this factory reset mode is described in more detail herein, at least in Section XD.

[0100] If device 110 has already established a secure connection with SCM120, SCM120 periodically requests device 110 to send ACP container version package 412, and if an updated ACP400 exists, it disconnects from device 110 and requests device 110 to reconnect (thus sending the updated ACP400), or requests device 110 to send the updated ACP400 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 (with the ACP container version package 412), and if SCM 120 determines that the update is appropriate (as described herein), it may 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 via the secure connection. If device 110 fails to respond to the request to send the ACP container version package 412 (for example, within a certain period), SCM 120 may disconnect from it.

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

[0102] In one embodiment shown in Figure 5, the ACP container version package 412 may include an ACP version, one or more embedded identifiers such as a large random number or sequence number, and a message authentication code or signature. One or more of the embedded identifiers, message authentication code, signature, and some or all of the ACP-Version-Key key may be stored within the ACP container 410 for verification. The ACP container version package 412 may be generated by the cloud 130 and encrypted with a key such as the ACP-Version-Key key 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 the Device-SCM-Key key or the SCM-Key key, or both.

[0103] In an alternative embodiment, the ACP container version package 412 is simply an ACP version of ACP 400 owned by device 110, previously generated or provided by device 110, without the corresponding cryptographic key in the ACP container 410. As an example, in this embodiment, SCM 120 can trust the version provided by device 110 and use that version to decide whether or not 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 cryptographic key via device 110.

[0104] This alternative embodiment is recognized as being far less secure than the previously described embodiment and has a potential vulnerability that could allow device 110 to claim to have any version of ACP400 it desires. However, this is generally unlikely to happen, and the most likely drawback might be that device 110 would either (a) not send ACP400 for update (because the version is older than the current one) or (b) send ACP400 for update (which would be rejected after each processing if the version number is very high). It is considered virtually impossible for device 110 to manufacture ACP400. Therefore, the most likely drawback is that SCM120 would end up bearing a lot of extra work, namely a denial of service (DoS). C. Verification

[0105] When SCM120 receives the ACP container 410, it may verify the authenticity of the ACP container 410 by sequentially decrypting each layer and calculating and comparing the integrity hashes (signatures) to ensure that the contents of the ACP container 410 have not been altered and have been properly decrypted; verifying that the provided ACP container version package 412 and its contents match the corresponding contents (e.g., ACP version and other applicable attributes) at various layers of the ACP container 410; and performing other (not enumerated) integrity and data integrity / validity checks as the ACP container 410 is processed at each layer.

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

[0107] Decrypting the ACP container 410 is considered a computationally intensive process, and for use in real-time systems, there may be more optimal data structures / configurations; therefore, the ACP container 410 (or ACP400) itself may or may not be stored in the SCM120's memory 212 when received. The ACP container 410 or ACP400 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 ACP400 may be stored in whole or in part. Alternatively, the ACP container 410 or ACP400 may be encrypted with an alternative cryptographic key in ROM (and decrypted during execution and stored in RAM), or it may be stored unencrypted in protected ROM, or it may be a combination of some of the above or other techniques. Additional examples of other techniques include software-based or hardware-based countermeasures that can prevent access to such data, provide hardware obstacles or shields, provide physical obstacles or shields, disable JTAG and other ports, enhance software interfaces to eliminate attack vectors, establish a trusted execution environment (hardware or software), and detect the inviting of root access or security breaches to the operating system.

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

[0109] An ACP container 410 and / or an ACP container version package 412 according to one embodiment of the present disclosure may be received or acquired by 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 to the SCM 120 by the device 110. If the ACP container version package 412 is not provided to the SCM 120, the SCM 120 may be required to retrieve and decode the first layer of the ACP container 410 in order 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 need to be notified of 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 the ACP container version package 412 currently owned by SCM 120 from SCM 120. Device 110 may then compare the version of ACP 400 identified in the ACP container version package 412 with the version of ACP 400 stored in memory and decide whether or not 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 between device 110 and SCM 120, at least in Section XIV as described herein.

[0112] In one embodiment, device 110 may send the complete version of the entire ACP container 410 to SCM 120. In one embodiment, device 110 may send the ACP container 410 to SCM 120 at its discretion, 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 SCM 120 by a system component other than device 110, such as an equipment component 140 or other accessory connected to device 110, using an available communication link. The available communication link may vary depending on the application or under different circumstances, and may be physical media, 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 an 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 circumstances and may be at least one of physical media, a wireless link, and a wired link.

[0114] Because of the potential risk of partial updates and inconsistent system states, including unintended behavior due to indiscriminate internet connectivity and the possibility of partial updates being missed, in the illustrated embodiment, the complete ACP container 410 may be sent to the SCM 120. An exemplary risk scenario includes a situation where, if the owner adds device A and then removes device B, the resulting configuration in the SCM 120 may be inaccessible to either device A or device B. In other words, the initial update may have been missed. However, these risks can be overcome or mitigated by adding attributes that track the version and order of partial updates.

[0115] In one embodiment, partial or incremental updates to the ACP container 410 may be obtained from the cloud 130. Such updates may include at least one of the addition, deletion, or modification of authentication, or a combination thereof, and a cycle of cryptographic 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 the SCM identity configuration package and ACP400.

[0116] In one embodiment, it may be necessary or desirable to reduce the size of the ACP container 410 being transmitted. One approach to doing so is to use a delta update, in which case only the differences between two specific ACP containers 410 are transmitted. If there are many versions of the ACP container 410 and the delta update image is specific to the preceding and succeeding versions 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, in which case 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, in which case 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 within the system 100.

[0117] Additionally or alternatively, a reduction in the size of the ACP container 410 being transmitted may be achieved by compression. Compression may be performed by either the cloud 130 or a system component (e.g., device 110) transmitting 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 within the system 100.

[0118] In one embodiment, the SCM120 may connect to a cloud 130, in which case the SCM120 does not store authorizations in the ACP400, 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 whether the identity of device 110 is authorized. If device 110 has authorizations, then the authorizations may be cached on the SCM120 for the duration of device 110's connection to the SCM120 (or longer if memory allows). Additionally or alternatively, to reduce network latency, authorizations may be cached on a local server (or set of servers).

[0119] In one embodiment, an ACP400 for a specific SCM120 stored in device 110 may contain only authorizations for that device 110. Additionally or alternatively, SCM120 may merge authorizations from multiple devices 110 into a unified ACP400 stored in SCM120.

[0120] In one embodiment, each SCM120 may receive and store multiple ACP400s, in which case each ACP400 contains a subset of all sets of authorizations issued to the SCM120. This prevents the ACP400 from becoming too large in environments where many devices 110 are authorized (e.g., a building access management system or fleet environment where hundreds or thousands of employees are authorized to unlock certain locks). The contents of each subset ACP400 may contain only authorizations for a specific set of user accounts and / or devices 110. For example, in one embodiment, a subset ACP400 may be created for each user account (in which case the ACP400 contains only the devices 110 associated with that user account). For example, in another embodiment, a subset ACP400 may be created for each set of 10 user accounts. For example, in yet another embodiment, a subset ACP400 may be created for each set of 100 devices 110. A subset ACP400 may be delivered as part of a combined ACP container 410 containing all subset ACPs, as a combined ACP container 410 containing any number of subset ACP400s (e.g., modified subset ACP400s), as individual ACP containers 410 (i.e., one for each subset ACP400), or as any combination thereof. In one embodiment, each ACP container 410 may have one ACP container version package 412 containing version information deemed necessary for each subset ACP400. In another embodiment, each ACP container 410 may have multiple ACP container version packages 412. V. Management and distribution of alternative packages

[0121] Other data packages may exist defined for the SCM120 configured and generated according to one or more embodiments of the ACP container 410 described herein, including similar meanings, processing, and encodings to the ACP container 410. It should be understood that as a result, different configuration (and other) packages may be available and managed and / or distributed in a similar manner. Packages may also exist defined for other system components (e.g., device 110 or instrument component 140). The following are examples of possible packages (some of which are described in further detail herein): 1) Application settings 2) Firmware update package 3) Subcomponent settings 4) Device protocol settings 5) Equipment Model 6) Blacklist Package 7) System log package

[0122] Examples of embodiments in which the security models / systems described herein are applied to a micro-rotation system are described in U.S. Patent Application No. 14 / 620959, filed February 12, 2015, entitled “System and Method for Communicating with a Vehicle,” and U.S. Patent Application No. 15 / 488136, filed April 14, 2017, entitled “System and Method for Establishing a Real-Time Location,” which are incorporated herein by reference in their entirety. Examples of information that may be provided according to one embodiment of a micro-location system include: 1) The zone configuration or related data may identify one or more areas or spaces relative to the SCM120 that are thought to be related to the use of the user or owner of the equipment 140. For example, an area or space within 5 feet of a door may be thought to be related to the operation of the door, and for example, presence in this zone may be a trigger that enables access through the door. 2) The configuration and placement of the monitoring device or related data can identify the settings of the remote device 310 described in relation to the embodiment shown in Figure 3, such as connection parameters for communicating with the SCM120 and for positioning the remote device 310 relative to the SCM120. 3) The algorithm tuning settings or related data may indicate one or more compensation factors for the algorithm used to determine the position of device 110 relative to SCM120. 4) The algorithm model or related data may indicate the algorithm used to determine the position of device 110 relative to SCM120. VI. Candidate ACP

[0123] In the illustrated embodiment, the cloud 130 may maintain a copy of the currently operating ACP400 (candidate ACP) for each SCM 120. The candidate ACP may be identifiable by the version of the ACP400 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 the ACP400 may be incremented each time a change is made.

[0124] When a new candidate ACP is created to be identified for owner account approval, 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 user 10 can then retrieve the latest candidate ACP on device 110 for approval. The user 10 can approve the candidate ACP from any of the devices 110 associated with the owner user account (i.e., the user account authorized as the owner of the SCM 120).

[0125] In one embodiment, authorization is issued only to a specific device 110 (i.e., instead of a user account). Thus, when a new candidate ACP is created to be identified for authorization on the owner device 110, the owner device 110 (and the corresponding user 10) may 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 device 110 for authorization.

[0126] In one embodiment, the candidate ACP may include additional changes from another owner 10, some or all of which may be undesirable. As a result, user 10 may (a) reject the candidate ACP by not approving it if nothing happens, or (b) edit the candidate ACP until it becomes 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 incorporated into the user interface of device 110. If the candidate ACP is rejected, it remains, and future changes may be made to that rejected version.

[0127] If edits are submitted to a candidate ACP 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 a candidate ACP is updated by another device 110 during the approval process, the edits in device 110 may have been made to an older version of ACP400, and therefore 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 ACP400.

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

[0129] If the signed version of the candidate ACP submitted to the cloud 130 by device 110 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 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, user 10 does not activate 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 matches the submitted 2FA code. If they match, the submission is considered accepted, provided that other criteria are also met. If they do not match, the submission is rejected (and the approval process may be repeated). In an alternative embodiment, the cloud 130 may accept based on the receipt of one or more user-related keys, such as those described herein in at least Section XII.N (e.g., retina, face, and / or touch ID).

[0130] After Cloud 130 decides to accept the submission of the signed version of the candidate ACP by Device 110, Cloud 130 marks the corresponding candidate ACP as approved, generates the final ACP container 410, and distributes the 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 system 110 with both a blockchain-type ledger of ACP400 and an approach that can avoid potential concurrency or blocking issues that may arise when multiple versions of ACP400 appear for approval or when only one version of ACP400 appears for approval at a time. The ACP400 ledger can provide an inspection history where each edit result becomes a new version, and each version is associated with a specific device 110.

[0132] In an alternative embodiment, a candidate ACP process for distributing and approving ACP400 may not be used. Instead, a new ACP400 for approval may be generated each time a change is made that elicits approval. Additionally or alternatively, a new ACP400 for approval may be generated each time a change is made that elicits approval, if subsequent changes prior to approval of the new ACP400 are rejected. VII. Approval Type

[0133] In one embodiment, System 100 may utilize or associate one or more rights associated with Device 110, defined as one or more authorizations, as discussed herein in at least Section II. Authorizations may have types associated with authorizations, known as authorization types (see, for example, Sections 1 and VII).

[0134] Authorization can be associated with pairings defined between device 110 and SCM 120. For disclosure purposes, it should be understood that authorizations and authorization types are described in relation to one device 110 paired with one SCM. However, between multiple devices 110 and multiple SCM 120, there are numerous possible pairing combinations, including multiple devices 110 associated with one or more SCM 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 can then be created for each device 110 and flow into authorizations associated with the user's account. For example, a user account service can create authorizations for each of the user's devices 110 and apply a user account authorization type for a particular SCM 120 to each of the created authorizations. In one embodiment, a user account may have zero or more authorization types (e.g., guest-administrator the following week, then guest) for each SCM 120 to which the user account is authorized, each becoming active at different times and / or under different conditions according to the authorizations associated with the user account.

[0136] In yet another embodiment, the authorization may be associated with only a specific 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] An authorization type can ultimately indicate the type of role a particular device 110 has with respect to a particular SCM 120. In System 100, an authorization type can also determine authorization rights associated with a particular authorization, including, but not limited to, the right to perform one or more of the following: “grant another right,” “transfer ownership,” “make someone an owner,” “add a guest,” “share with others,” or “issue a specific command.” In alternative embodiments, authorization types and authorization rights may be managed separately, for example, in accordance with one or more embodiments described herein in at least Section XX, for the management of block fan rights. Authorization types can be a useful aspect of the security model because they can control the various actions that a particular device 110 (and, on its behalf, its user 10) can perform with respect to a particular SCM 120 (and, on its behalf, equipment components communicating with the SCM 120). Exemplary authorization types are listed below for disclosure and include, but are not limited to, owner authorization types, guest-administrator authorization types, guest authorization types, bullet authorization types, and organization authorization types. A. Owner

[0138] The Owner Authorization type may be reserved for user accounts and / or devices 110 that have full authority over a given SCM 120. A user account with the 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 up to 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 not have any other valid authorizations for the same SCM 120. If an account and / or device 110 is issued Owner Authorization after other authorizations have been issued, all other authorizations may be revoked, for example, in accordance with the authorization issuance methods described herein, at least in Section VIII.

[0139] In an alternative embodiment, the SCM120 may have up to one owner account.

[0140] In an alternative embodiment, the SCM120 may have up to one owner device.

[0141] In the embodiment illustrated in Figure 1, an owner account and / or device 110 can inspect, issue (create), modify, and revoke (delete) any authorizations for a given SCM 120. An owner account and / or device 110 can transfer an SCM 120 to a new account and / or device 110, thereby revoking all authorizations for the SCM 120 originating from the owner account and / or device 110, and creating owner authorizations for the target account and / or device 110, respectively. In one embodiment, an owner account and / or device 110 may be configured to approve all authorization changes for a given SCM 120. User 10 may or may not be required to be involved, depending on the type of change. In one embodiment, any owner account and / or device 110 may approve authorization changes. When an 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 arising from that 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 the SCM 120.

[0143] As discussed herein, an authorization can be associated with one or more access attributes, including whether the authorization includes an owner authorization type. Modifications that restrict or change the access attributes of an issued authorization may apply to all issued authorizations that include the access attributes (including all authorizations issued based on the restricted or changed access attributes). For example, if an owner authorization type or access attribute is 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 authorization to be issued (e.g., a change in the start / end date) may not affect any of the previously issued authorizations based on the access attributes of the authorization to be issued.

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

[0145] In one embodiment, once an owner authorization is created, it cannot be changed to another authorization type. In an alternative embodiment, an owner authorization may be changed to any other authorization type. A change to another authorization type may result in previously issued authorizations that are no longer permitted. These authorizations may be moved automatically or manually to an alternative account and / or device 110 that has applicable authorizations, or they may be revoked. B. Guest Administrator

[0146] A guest-administrator authorization type can be associated with an account and / or device 110 that has nearly complete privileges to a given SCM 120. A device 110 with guest-administrator authorization is known as a guest-administrator device (or a guest device if there is no operational difference with respect to the guest authorization type). A user account of the guest-administrator authorization type is known as a guest-administrator account (or a guest account if there is no operational difference with respect to the guest authorization type). Each account and / or device 110 can have at most one guest-administrator authorization to a given SCM 120. However, an SCM 120 can have multiple guest-administrator accounts and / or devices. A guest-administrator account and / or device 110 for a given SCM 120 may not have any other valid authorizations for the same SCM 120. In one embodiment, if an account and / or device 110 is issued guest-administrator authorization after other authorizations have already been issued, all other authorizations may be revoked, such as in accordance with the authorization issuance methods 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 yet another alternative embodiment, each account and / or device 110 may issue zero or more other permissible authorizations for the same SCM 120. In yet another alternative embodiment, an account and / or device 110 may not issue a guest-administrator authorization if other authorizations have already been issued. In yet another alternative embodiment, if an account and / or device 110 issues a guest-administrator authorization after other authorizations have already been issued, the redundant or unpermissible authorizations may be revoked, at least in Section VIII, in accordance with the authorization issuance methods described herein.

[0148] In the embodiment illustrated in Figure 1, a guest-administrator account and / or device 110 can issue (create) non-owner authorizations, but can only inspect, modify, and revoke (delete) authorizations they have issued (or been issued) to a given SCM 120. A guest-administrator account and / or device 110 may be issued authorizations with limited access attributes. For example, a guest-administrator account and / or device 110 may be issued authorizations with a limited expiration date.

[0149] A guest-administrator account and / or device 110 may not issue authorizations with broader access attributes than those 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 an expiration date outside the expiration date associated with the guest-administrator authorization type.

[0150] If the authorization access attributes of the 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 revoked. In one embodiment, if the guest-administrator authorization of an account and / or device 110 is revoked, all authorizations derived from that guest-administrator authorization from that account and / or device 110 are also revoked. The guest-administrator account and / or device 110 for 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, the guest-administrator authorization may not have limited access attributes. In one embodiment, a guest-administrator account and / or device 110 that has been issued authorizations from an issuing account and / or device 110 (e.g., owner account and / or device 110) may, at the discretion of the issuing account and / or device 110, examine authorizations issued to other accounts and / or devices 110 for a given SCM 120 that have been issued authorizations from the issuing account and / or device 110, including or excluding the issuing account and / or device 110. In an alternative embodiment, if the guest-administrator authorization for an account and / or device 110 is revoked, all authorizations derived from the guest-administrator authorization for the account and / or device 110 may be transferred to another owner account and / or device 110, or to a different guest-administrator account and / or device 110, for use with respect to the SCM 120.

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

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

[0154] A guest authorization type may be associated with an account and / or device 110 that has limited authority over a given SCM120. A device 110 with guest authorization is known as a guest device 110. A user account with 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 SCM120, and an SCM120 may have multiple guest accounts and / or devices 110. Guest accounts and / or devices 110 of a given SCM120 do not need to have valid owner or guest-administrator authorizations for the same SCM120. If an account and / or device 110 is issued guest authorization after other authorizations have already been issued, redundant or unacceptable authorizations may be revoked, at least in accordance with the authorization issuance methods described herein in 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 yet another alternative embodiment, if an account and / or device 110 issues a guest authorization after other authorizations have already been issued, all other authorizations may be revoked, such as in accordance with the authorization issuance methods described herein in Section VIII. In yet another alternative embodiment, each account and / or device 110 may issue zero or more other acceptable authorizations for the same SCM 120. In yet another alternative embodiment, an account and / or device 110 may not issue a guest authorization if other authorizations have already been issued. In yet another alternative embodiment, if an account and / or device 110 issues a guest authorization after other authorizations have already been issued, redundant or unacceptable authorizations may be revoked, such as in accordance with the authorization issuance methods described herein in Section VIII.

[0156] In the embodiment illustrated in Figure 1, the guest account and / or device 110 can issue (create) bullet authorizations, but can only review and revoke (delete) authorizations issued by the guest account and / or device 110 to a given SCM 120. The guest account and / or device 110 may issue one or more authorizations with limited access attributes. For example, the guest account and / or device 110 may issue authorizations with limited expiration dates.

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

[0158] If the authorization 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 revoked. If 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, the guest account and / or device 110 cannot revoke its own guest authorization. The guest account and / or device 110 for SCM120 may not issue authorization to itself (i.e., the same account and / or device 110) for the same SCM120.

[0160] In an alternative embodiment, a guest account and / or device 110 that has been issued authorization by an issuing account and / or device 110 (e.g., owner account and / or device 110) may, at the discretion of the issuing account and / or device 110, examine to a given SCM 120 the authorizations issued to other accounts and / or devices 110 that have been issued authorization by the issuing account and / or device 110, including or excluding the issuing account and / or device 110. In an alternative embodiment, if the guest authorization of an account and / or device 110 is revoked, all authorizations derived from the guest authorization of the account and / or device 110 may be moved to another owner account and / or device 110, or guest-administrator account and / or device 110, to the SCM 120. In one embodiment, the 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, once a guest authorization is created, it cannot be changed to another authorization type. In an alternative embodiment, a guest authorization may be changed to any other authorization type, but this may result in one or more authorizations issued from the guest authorization that are no longer permitted. Such one or more authorizations may be automatically or manually moved to an alternative account and / or device 110 with applicable authorizations, or they may be revoked. D. Barrett

[0162] A bullet authorization type can be thought of as a special-purpose authorization type for accounts and / or devices 110 that have limited authority over a given SCM 120. A device 110 with bullet authorization is known as a bullet device. A user account with a bullet authorization type is known as a bullet account. Each account and / or device 110 may have zero or more bullet authorizations for a given SCM 120. However, an SCM 120 may have multiple bullet accounts and / or devices 110. A bullet account and / or device 110 of a given SCM 120 may not have any valid owner authorizations, guest-administrator authorizations, or guest authorizations for the same SCM 120. If an account and / or device 110 is issued a bullet authorization after other authorizations have already been issued, any redundant or unacceptable authorizations may be revoked, for example, in accordance with the authorization issuance methods described herein in Section VIII.

[0163] A bullet account and / or device 110 can only inspect authorizations issued to a given SCM 120. A bullet account and / or device 110 may issue authorizations with limited access attributes. For example, a bullet account and / or device 110 may issue authorizations with limited expiration dates.

[0164] In an alternative embodiment, no bullet authorizations may exist. In another alternative embodiment, a limited number of bullet authorizations may be provided to a given SCM120 account and / or device 110. This number may be a fixed number (e.g., 1). In yet another alternative embodiment, bullet authorizations may be transferred to another account and / or device 110 belonging to the same entity (e.g., a bullet service organization) as the bullet account and / or device 110, or to an associated account and / or device 110.

[0165] In one embodiment, when any event occurs (for example, a non-bullet account and / or device 110 connects to the SCM 120, or equipment component 140 indicates that the SCM 120 has moved beyond a reasonable threshold), the bullet authorization may be automatically revoked.

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

[0167] In one embodiment, the organizational authorization type may have 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 the SCM120. This authorization type is transient. It is used to signal that such a transfer is desired so that appropriate authorization and revocation may be performed, and based on the authorization, owner authorization 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 runtime, via pre-runtime configuration, or programmatically. For example, a new type of authorization type not previously used in system 100 may be introduced to accounts and / or devices 110 and SCM120 via ACP400. H. Authorization Tree

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

[0171] In the embodiments illustrated in Figures 6 and 7, there are multiple SCMs 120 within the system 100, each associated with one or more owner accounts and / or devices 110. 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 Figure 1, user 10 can issue, modify, and revoke various types of authorizations to multiple SCMs to the user account (and, via the user account service, to device 110) and / or to device 110. The security model can leverage the involvement of multiple system components for issuing authorizations, including user 10 (to accept both authorization issuance requests and the resulting ACP400). Modifying and revoking authorizations may not necessarily require user involvement.

[0173] A method for issuing one or more authorizations according to one embodiment is shown in Figure 8 and is represented collectively as 800. The method 800 includes a range of steps, including step 801) a user 10 entitled to issue authorizations sends an authorization issuance request to a receiving user account and / or device 110 for a specific SCM 120 using the device 110 (the one entitled to do so); step 802) the receiving user accepts the authorization issuance request using their respective device 110 (e.g., any device 110 associated with their respective user account, a specific device 110); and step 803) the owner device 110 for the SCM 120 accepts the changes to the ACP 400 resulting from the issued authorizations.

[0174] In addition to the above, two-factor authentication (2FA) may be added as a system-level requirement in one or more of the above steps, as described herein. However, for ease of understanding, 2FA messages are not shown in the sequence diagram 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 channel is provided for a first user 10 to send an authorization request to a second user 10 who does not have an existing user account and / or OEM (Original Equipment Manufacturer) cloud account. The communication channel may be at least in part based on email and / or SMS communication. The message delivered to the second user 10 may request the second user 10 to obtain an application for the second user 10's device 110 (if appropriate), or to visit a website to create a user account and / or OEM account, and to accept the request.

[0176] As described herein in relation to one or more embodiments, an ownership transfer request can be considered a special case of a typical authorization issuance process. This is because an ownership transfer request results in the issuance of an owner authorization, which involves the revocation of all other authorizations for a given SCM120. In the embodiment illustrated in Figure 8, both the new owner and the previous owner may be required to approve the ownership transfer request, however, due to the nature of the ownership transfer request, the candidate ACP cannot be modified 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 its user 10 on its behalf) can approve changes to the ACP400 initiated by any user 10 to the SCM120. 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 participate in the approval process of the ACP400. Even if user 10's involvement is not required (e.g., not 2FA or not requiring the pressing of an authorization button), the owner device 110 may still be involved (e.g., by performing processing in the background without user intervention).

[0178] Other authorization and / or authorization processes may exist that do not require user involvement. Any authorization and / or authorization process described herein may be adapted to such a method that does not require user involvement. It is desirable to improve the user experience by not requiring user 10 to be involved in the authorization of something initiated by the user. If user 10 has multiple devices 110 associated with their user account, it is desirable to require authorization from another user device 110 even if they initiate a change. In an alternative embodiment, the scope of changes to ACP400 may be limited such that a) user 10 may be required to be involved in authorization for SCM120, or b) user 10's involvement in the authorization process of SCM120 may only be required when a new owner authorization is issued. User involvement may be required when a new owner authorization is issued. Even when user involvement is not required, such as when 2FA is not enabled or the authorization button is not enabled, the owner device 110 may still be involved (e.g., by performing processing in the background without user intervention).

[0179] In an alternative embodiment, the authority to authorize changes to ACP400 may be delegated. As discussed herein, the owner account and / or device 110 may be configured to authorize ACP400 for SCM120. The owner account and / or device 110 may delegate the authority to authorize ACP400 to another account and / or device 110 that is attempting to issue an authorization. The authority to authorize may be limited to a subset of authorization types available to the owner account and / or device 110, or may include all available authorization types. For example, if owner C has given guest A the authority to authorize guest authorizations and delegate guest authorizations, guest A can issue guest authorizations to guest B without the involvement of owner C. In another example, the authority to authorize may be delegated if no other changes to ACP400 exist. Otherwise, the owner account and / or device 110, or a non-owner issuing account and / or device 110 in the issuing chain, may authorize changes to ACP400.

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

[0181] The illustrated embodiment in Figure 8 includes several steps highlighted herein, including sending an authorization request, accepting the authorization request, and accepting the changes to ACP400 resulting from the issued authorization (steps 801, 802, and 803). The exemplary embodiment emphasizes 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, who is currently classified as the owner, and user A's device A is owner device 110. User B and her device 110, labeled as device B, may be subject to authorization issuance. User A can request user B's username (e.g., "B"), and user B can respond (steps 821, 822). User A can instruct her device A to issue a guest authorization to user B. 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 to 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 can select which of user B's devices 110 the authorization is sent to (step 825). Cloud 130 requests one of User B's devices 110 to accept or reject authorization (step 826). If User B accepts authorization, User B's device 110 generates a Device-SCM-Key and sends the relevant part (e.g., public key) to Cloud 130, which Cloud 130 uses to update the candidate ACP (step 827). The existence of the updated candidate ACP is communicated to User A (via device 110), and User A accepts the changes to the candidate ACP. The device 110 used by User A signs the approved candidate ACP to approve the changes and sends it to Cloud 130 (step 828). This approval step can be considered a requirement in one embodiment if the change is a transfer of ownership, even if the initiator is the owner device.

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

[0184] In one embodiment, system 100 may leverage what the user is familiar with by accessing the service via an account model, such as a username and password-based account model. Additionally or alternatively, system 100 may leverage a key-based identification system (i.e., cryptographic identity) based on the identity of device 110. Key-based identification (i.e., cryptographic identity) provides the user with a degree of anonymity and facilitates the tracking of changes or transactions to ACP400 according to the blockchain ledger. Similar to, and at least partially based on, an cryptographic system in which the 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, system 100 may leverage device identity as a key in the authorization issuance sequence. Device identity may be dynamic or fixed based on one or more characteristics of the device and potentially circumvent the identification, tracking, and authentication of user 10 by account and password. System 100 can substantially equate the physical properties of device 110 with those of a mechanical key and consider the identity of device 110 as a proxy for user 10.

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

[0186] A 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 in Cloud 130 can abstractly associate OEM user accounts (via the OEM User Identifier) ​​with Cloud-User-IDs using a secure database approach, and the Cloud 130 service that stores and performs this mapping (the user account service) is isolated or separated from other services in Cloud 130 and the OEM cloud, allowing user-identifiable information to remain in the external OEM cloud. This approach can prevent unauthorized hacker access unless a hacker penetrates three separate system components (at least two of which reside in separate management infrastructures, domains, or control areas) to aggregate personally identifiable information (PII), such as the mapping of user 10 to OEM user accounts, the mapping of user 10 to device 110, and the mapping of user 10 to SCM 120 or equipment 140.

[0187] In an alternative embodiment, Cloud 130 may not use a secure database approach but can 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 OEM user identifiers and Cloud-User-IDs may not exist or be abstracted.

[0188] In the illustrated embodiment, the cloud 130 does not need to maintain personally identifiable account information. As a result, the cloud 130 may not have user accounts in the conventional concept and may lack a non-OEM cloud login API that enables direct access. Device 110 may be registered using an OEM cloud and associated with an OEM user account, which can then interact with the cloud 130.

[0189] A method for registering a device according to one embodiment is described in the illustrated embodiment of Figure 9, which is represented as 900 overall. Device 110 securely connects to the OEM cloud (e.g., via TLS) (step 901). Device 110 uses input from user 10 to send 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 device 110 with the Cloud-User-ED, OEM identifier, required tokens (e.g., session token and / or cloud token), and any other data necessary to successfully register the device. The OEM cloud may interact with other parts of the cloud 130 (step 903). Device 110 sends a registration request to the OEM cloud (step 904) which includes a session token (which can be mapped to a specific Cloud-User-ID and OEM-ED, allowing Device 110 not to send them individually or to request them separately as additional verification), any other necessary tokens (such as a push notification service token), a device rights public key (if using a device rights service such as the BlockFan 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 used in the registration process to substantially avoid or prevent a malicious device from registering the same device multiple times.

[0190] In method 900, the OEM cloud can verify the registration request (step 905). If the registration request is successful, the OEM cloud provides the registered device 110 with a Device-ID (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 does not have to be a cryptographic signature and does not have to be truly device-specific (for example, it may be application installation-specific). Rather, the device signature may be an identifier that can be used to uniquely identify a particular device (for example, a serial number or application instance number, such as a randomly generated number or a number provided by the operating system). If successful, the device registration process can provide the generated Device-ED to device 110 for use in subsequent processing, such as issuing authorization.

[0192] In an alternative embodiment, the OEM cloud may not be used. Cloud 130 may allow device 110 to be registered with a randomly generated (possibly unique) Cloud-User-ED. In this case, the Cloud-User-ED may contain a specific globally defined or configurable OEM identifier, and device 110 may play a role in maintaining or providing all the conveniences used to obtain device aggregate information and information for performing desired cross-device processing.

[0193] In many cases, the OEM provides a user interface for the device component 140, such as a branded website and mobile application, though not limited to these. Therefore, the OEM can manage the corresponding system components necessary to deliver 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) that use appropriate privacy and trust (encryption, authentication, and authorization), the OEM cloud can retrieve from the cloud 130 which device 110 is associated with a particular user, manage authorization, and perform any device ownership adjustments required over the product lifecycle of the OEM's equipment components 140. Privacy and trust can be established in various ways, including via TLS 1.2+ mutual authentication using X.509 certificates, and via OAuth2 or a delegated / custom challenge / response mechanism (OEM cloud). An example of an OAuth2 challenge / response flow, i.e., method 1000, for interaction between the OEM cloud, user 10, and cloud 130 is shown in the illustrated embodiment in Figure 10.

[0195] In the illustrated embodiment, user 10 can obtain a user account from OEM Cloud 135, which may be configured similarly to Cloud 130 as described herein (step 1002). Next, user 10 can log in to OEM Cloud 135 to obtain a temporary OEM Cloud identifier and / or Cloud Token (for use, for example, in the OAuth2 authentication process) (step 1004). User 10 can provide Cloud 130 with the temporary OEM Cloud identifier and / or Cloud Token previously obtained from OEM Cloud 135 to request a Cloud-User-ID from Cloud 130 (step 1006). Cloud 130 can verify the Cloud Token and / or temporary OEM Cloud identifier provided by user 10 in OEM Cloud 135 (step 1008). If the cloud token and / or temporary OEM cloud identifier is verified, cloud 130 may send the Cloud-User-ID to user 10, possibly along with the OEM cloud identifier (OEM user identifier) ​​(which may 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 of verifying 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 instructing which server to connect to, or allowing 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 an OAuth2 or 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 a custom or delegated cryptographic and authentication protocol with TLS 1.2+ or OAuth2, or a delegated or custom challenge and response mechanism.

[0197] As described herein, in one embodiment, the cloud 130 does not have to provide a user account service that allows users to create accounts and then associate their devices 110 with their accounts 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 can provide anonymous user accounts. In one embodiment, the cloud 130 can provide conventional user account management and device 110-related services (e.g., via a user account management service) that can be used by the OEM cloud, other OEM services, applications, and system components such as user 10, device 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 OEMs in each system. The user account management and device-related services provided by Cloud 130's user account management service may include (but are not limited to) the following: 1) Create and activate user accounts (using name, email, phone number, and password) using two-factor authentication and email verification. 2) Add or remove devices to or from a user account, or both. 3) Examine the devices associated with the user account and the authorizations associated with those devices.

[0198] In one embodiment, authorization may be shared across all devices 110 associated with user account 10. Authorization changes may be approved by any device 110 associated with a user account associated with the owner device 110 of SCM 120. User 10 may or may not configure how authorization is shared among those devices 110. For example, user 10 may or may not configure which devices 110 receive authorization for which SCM 120. The user account service can ensure that these operations are performed on behalf of the user, for each configured selection and system rule. X. Monetization

[0199] In one embodiment, System 100 may be configured to require payment from User 10 for specific processes performed by System 100. In this way, System 100 may monetize the aspects or functions provided by System 100. Maintaining the technology and infrastructure for System components to operate and communicate securely can be a difficult and expensive process. Furthermore, User 10 may expect technological advancements, improvements, compatibility with new products and technologies offered on the market, and security patches or enhancements (all of which may require funding). There are numerous system processes described herein that are computationally intensive but do not involve User 10 directly or concretely. There are many computationally intensive system processes (i.e., services) that involve User 10, such as issuing, amending, or revoking licenses, registration, transferring ownership of SCM120 or factory reset, and firmware updates. Payment for services may be made by User 10, the OEM, or other entities. The following actions may be monetized in connection with the processing of the security models / systems described herein: issuance of authorization, registration of device 110, transfer of ownership of SCM120, factory reset of SCM120, 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 authorization

[0200] The OEM may be billed for each authorization successfully issued by User 10, in which case an invoice is generated for the collected amount incurred over a predetermined period, 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 has the potential to result in micropayments.

[0201] User 10 may be billed for each authorization successfully issued by User 10, in which case an invoice may be generated for the collected billing amount, occurring over a predetermined period such as daily, weekly, or monthly. Alternatively, User 10 may be billed in real time for each authorization successfully issued by User 10 to generate revenue based on micropayments. In this embodiment, payment may be approved by User 10, indicating that User 10 agrees to be billed. Consent may be obtained when the authorization request is submitted, and User may be billed when the recipient accepts the authorization or when the resulting changes to ACP400 are approved. Evidence of consent may be provided as part of the request, which may be rejected if there is no evidence of payment approval.

[0202] In an alternative embodiment, if the sequence granting approval fails, user 10 is immediately charged, but the transaction may be canceled / refunded.

[0203] In one embodiment, user 10 may be charged for each authentication that cloud 130 successfully issues to user 10, in which case an invoice may be generated for the collected charges that occur over a predetermined period, such as daily, weekly, or monthly. In one embodiment, user 10 may be charged in real time for each authorization successfully received or requested by user 10, in order to generate a micropayment-based monetization system. In this embodiment, payment may be approved by user 10, indicating that user 10 agrees to be charged. Consent may be obtained in conjunction with the receipt of the authorization request. Evidence of consent may be provided as part of the request acceptance response, which may be rejected if there is no evidence of payment approval. User 10 may be charged when the request acceptance response is received by cloud 130, or when the resulting changes to ACP400 are approved. In an alternative embodiment, if the sequence is unsuccessful, user is charged immediately, but the transaction may be canceled or refunded. B. Device Registration

[0204] The OEM may be billed for each device successfully registered by user 10, in which case an invoice may be generated for the billed amount collected over a predetermined period, such as daily, weekly, or monthly. In one embodiment, the OEM may be billed in real time for each successfully registered device 10, resulting in a micropayment type system.

[0205] In one embodiment, user 10 may be billed for each device 10 successfully registered by user 10, in which case an invoice may be generated for the collected billing amount that occurs over a predetermined period, such as daily, weekly, or monthly. In another embodiment, 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 user 10, indicating that the user consents to being billed. Consent may be obtained in conjunction with the submission of the device registration request, and evidence of consent may be provided as part of the request. If there is no evidence 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, user 10 is billed immediately, but if the device registration sequence is unsuccessful, the transaction may be canceled or refunded. Transfer of ownership of C.SCM

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

[0207] In one embodiment, user 10 may be billed for each successful transfer of ownership of SCM120. Invoices may accrue over predetermined periods, such as daily, weekly, or monthly, and be generated for the collected billing amounts. In one embodiment, user 10 may be billed in real time for each successful transfer of ownership of SCM120, resulting in a micropayment-based monetization system. In this configuration, payment may be authorized by the user, indicating that the user agrees to be billed. Consent may be obtained in conjunction with the submission of a device registration request, and evidence of consent may be provided as part of the request. If there is no evidence of payment authorization, the request may be rejected, and the user may be billed when the device registration is successfully processed. In an alternative embodiment, user 10 is billed immediately, but if the device registration sequence is unsuccessful, the transaction may be canceled or refunded. D.SCM Factory Reset

[0208] The OEM may be billed for each successful factory reset of the SCM120 by a user associated with the OEM. Invoices may be generated for the collected billing amount over a predetermined 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, user 10 may be billed for each successful factory reset of SCM 120, in which case the invoice may accrue over a predetermined period, such as daily, weekly, or monthly, and be generated for the collected billing amount. In another embodiment, user 10 may be billed in real time for each successful factory reset of SCM, resulting in a micropayment-based monetization system. In this configuration, payment may be authorized by user 10, indicating that user 10 agrees to be billed. Consent may be obtained when a new owner initiate request is submitted, and evidence of consent may be provided as part of the request. If there is no evidence of payment authorization, the request may be rejected. User 10 may be billed when cloud 130 generates the resulting ACP 400. In an alternative embodiment, user 10 is billed immediately, but if the sequence is unsuccessful, the transaction may be canceled or refunded. E. Firmware update

[0210] The OEM may be billed for each successful firmware update by user 10, in which case the invoice may be generated for the collected billing amount over a predetermined period, such as daily, weekly, or monthly. In one embodiment, the OEM may be billed in real time for each successful firmware update, which would result in a micropayment-based monetization system.

[0211] User 10 may be billed for each successful firmware update, in which case the invoice is generated for the collected billing amount over a predetermined period, such as daily, weekly, or monthly. In one embodiment, User 10 may be billed in real time for each successful firmware update (e.g., micropayment). In this configuration, payment may be authorized by User 10 (indicating that User 10 agrees to be billed) when the firmware update is sent or initiated. Proof of authorization may be supplied as part of the request, and if there is no evidence of payment authorization, the request is rejected. User 10 may be billed when a component of System 100 detects that the firmware update was successful. In an alternative embodiment, User 10 is billed immediately, but if the sequence is unsuccessful, the transaction may be canceled or refunded. XI. Distributed confidence models

[0212] System 100 according to one embodiment can utilize a distributed trust model. This distributed trust model can allow device 110, SCM 120, and equipment system components 140 to be either online or / or offline while they can establish trust, communicate securely, and operate. For example, device 110, SCM 120, and equipment system components 140 can enable authentication and authorization of system components online and / or offline. A. Overview

[0213] In one embodiment, system 100 can incorporate the principle of least privilege to enhance confidentiality and privacy, isolate system components, and reduce the attack surface. Communication between system components and data storage within system components can be implemented securely and confidentially by uniquely combining security standards with processes. Standards include encryption, authentication, integrity verification, or security protocols, or a combination thereof, and processes include protocols, workflows, or management or verification of system state, or any combination thereof.

[0214] For disclosure purposes, 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. An 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, or it may be part of an asymmetric pair defined by a public key and a private key.

[0216] A secure (encrypted) hash may be stored within the encrypted message to verify the integrity of the message or to confirm that the message has not been tampered with. Sender identification information may be stored within the encrypted message to verify the authenticity of the message. The integrity and authenticity of a message can be verified simultaneously by including symmetric encryption, a message authentication code (MAC), or asymmetric encryption (e.g., public-key cryptography) in (or along with) the encrypted message, or by including a digital signature.

[0217] In asymmetric cryptography, a digital signature does not in itself guarantee that the author signed and encrypted the message. Such a guarantee can be described as irrefutable cryptography or as evidence of authorship and / or origin.

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

[0219] If a public key is delivered with the message, the recipient may not be aware of any changes in the author. A digital certificate (X.509), which would be managed by a public key infrastructure (PKI), can provide evidence that a particular public key is the key of a particular author, and therefore a particular digital signature was made by a particular author. In the absence of a digital certificate, evidence of authorship, and possibly evidence of the intended destination, may be established by properly including the author's identity, the destination's identity, or both, in the encrypted message when using an SE approach. An SE approach may include both a) signing the message more than once, such as signing an SE message (SSE), and b) encrypting the message more than once, such as encrypting an EES message (ES) message.

[0220] Symmetric encryption may not be a concern for the transfer of secrets. The recipient may be assured that the creator is known and that the sender intended to send the message to the recipient. However, symmetric encryption may not provide cryptographic repudiation because both parties share a secret. Systems based on symmetric encryption can address and mitigate this problem through one or more layers of selected security protocols, message packaging or storage, and communication methods.

[0221] Symmetric and / or asymmetric encryption, with and / or without digital certificates, using message integrity and authentication mechanisms, is used throughout System 100 to communicate between system components and to 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 the identified weaknesses of asymmetric encryption and other known vulnerabilities or considerations that are not explicitly identified but are generally known to the security community: • Digital certificate

[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 the following: a public certificate authority, a private cloud certificate authority, or a self-signed certificate. • Public certificate and key

[0223] Public certificates and / or public keys that may be used to decrypt a message can never be delivered with the message. That is, in one embodiment, the recipient must receive and authenticate the public certificate and public key in advance from a trusted source. Instead of per cloud 130 or per SCM 120, the public keys and certificates can cover specific relationships that are considered practical or beneficial, such as between pairs defined by device 110 and cloud 130, and between pairs defined by device 110 and SCM 120. The public keys and certificates may be stored only by the system component that uses them. 3. Signature

[0224] If digital certificates are not used, signatures may be used, and author IDs and / or recipient IDs may be included in the message to suit the functionality and security requirements of the message content. Messages may be encrypted or not, or messages may be double-signed and / or double-encrypted. • Creator's proof

[0225] For distributed reliability 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 delivered by any source, as long as the author's ID is preserved, and the message can be authenticated as having originated from that particular source. Messages may be configured and delivered in such a way that the contents of a message directed to a particular system component are not scrutinized by other components, but are verified by all or some components as having been created by a trusted component.

[0226] Symmetric and asymmetric keys, such as shared secret keys, public / private keys, and certificates, may be circulated or modified. This circulation or modification may be performed as part of a breach recovery procedure or through normal operation of system 100. System 100 can circulate keys periodically. System components and message definitions can support actions in system components or system communications, including online system components, offline system components, and components that switch between offline and online, that provide updated keys as part of a key circulation protocol. An exemplary online system component or communication includes a pairing between cloud 130 or cloud 130 and device 110. An exemplary offline system component or communication includes device 110, a pairing between device 110 and SCM 120, SCM 120, a pairing between equipment 140 and SCM 120, and equipment 140. In one embodiment, a key circulation instruction and one or more keys may be delivered within message content such as ACP400.

[0227] System components or communications that use digital certificates, such as communications between Cloud 130 and device 110, can 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 an alternative embodiment, revoked certificates may be registered in batches at predetermined intervals, such as hourly, every four hours, or daily. In an alternative embodiment, revoked certificates may not be registered using the CRL.

[0228] System components or communications that use digital certificates, such as 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 performed using the CRL of the appropriate certificate authority. In an alternative embodiment, the revocation of the certificate may not be checked. In another alternative embodiment, the expiration date of the certificate may not be checked.

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

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

[0231] Identity changes and revocations (and changes to identity verification or authentication) may be delivered from or to the cloud, or from or to all or some system components, such as via ACP400, factory reset procedures, or key circulation, 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 contain critical resources that are unavailable on constrained devices, such as system components with little or no ROM, RAM, processing power, or communication bandwidth / throughput.

[0233] In the illustrated embodiment of system 100, the SCM 120, device 110, and 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, "raw" asymmetric and / or symmetric encryption may be used in such system components because this type of encryption uses significantly less memory, along with considerably lower processing overhead. Lower memory usage can also result in reduced communication bandwidth for transferring information.

[0234] In one embodiment, device 110 can 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, whenever raw public-key cryptography is used, symmetric cryptography may be used, for example, in non-certificate-based use.

[0236] In one embodiment, P-256 (secp256rl) elliptic curve (ECC) (asymmetric) and AES-128 (symmetric) encryption are 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 above encryption algorithms. B. Certificate Verification

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

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

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

[0240] There are numerous cryptographic keys distributed among the system components within system 100 so that each system component can authenticate one another and data can be delivered confidentially and securely so that the data is accessible to the components (presumably only to the components that are expected to need the data). The data can be communicated online and / or offline. The distribution of keys or identifiers according to one embodiment is shown in Figures 11A–B, which includes multiple system components and the cryptographic keys (and several identifiers) that they possess. Furthermore, the illustrated embodiment in Figure 16 also shows system 100, each having only the private / symmetric cryptographic keys that it possesses. Each of the cryptographic 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 SCM120. The SCM-Key key may be an asymmetric private / public key pair that is generated and stored either directly by the SCM120 or only during the manufacturing process by a manufacturing tool. The SCM-Key private key can be securely stored in the SCM120 within a secure memory 220 or secure element, including a secure hardware module such as a secure enclave or hardware security module (HSM).

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

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

[0244] Since no changes are expected in the SCM-ED, system components may report changes to user 10 as security anomalies, such as tampering, attempted impersonation, or signs of protocol violations. Alternatively, changes may be reported to the owner 10 of the SCM120 as signs of product failure, such as memory corruption.

[0245] The SCM-ED may be a randomly generated identifier used solely for the identification of the SCM120, or the SCM-ED may serve other purposes as well. One example of such other purposes is to act as a communication protocol identifier, such as a Media Access Control (MAC) address and / or a Global / Universal Unique Identifier (GUED / UUED) shared with other services, including, for example, Bluetooth® Low Energy (BLE). Another exemplary 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 product number (EAN), vehicle identification number (VEST), or any other identifier unique to a particular SCM120.

[0246] In alternative embodiments, the SCM-ED may not be specific to a particular SCM120. Examples of non-specific types of SCM-EDs include the International Standard Book Number (ISBN), USB device identifier, and 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 part of identification information that is not dependent on 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, and each of them may not be unique to a particular SCM120. For example, the SCM120 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), an International Mobile Station Equipment Identity (IMEI), and / or a Mobile Device Identifier (MEED).

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

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

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

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

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

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

[0255] In one embodiment, there is no SCM-Key, and in this case, other means may be used for the system component to communicate with the SCM120 and / or to verify the authenticity of the SCM120. B. Equipment-Key

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

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

[0258] In the illustrated embodiment, the Equipment-Key private key is not transmitted to other system components. The Equipment-Key public key may be securely transmitted to and stored in a system component that utilizes the Equipment-Key public key, such as SCM120. The Equipment-Key public key may be transmitted to SCM120 (or other equipment) by a manufacturing tool during the manufacturing of equipment 140 or SCM120. The Equipment-Key public key may be transmitted to SCM120 (or other equipment) by equipment 140 or other system components via a communication link or physical medium. The Equipment-Key private key may be used by a particular equipment 140 to encrypt and / or sign messages that equipment 140 transmits to other system components, and may be used to decrypt and / or verify messages transmitted from other system components to equipment 140.

[0259] The Equipment-Key public key may be used by system components to decrypt and / or verify messages originating from a specific device 140, and may also be used to encrypt and / or sign messages directed to a specific device 140.

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

[0261] The Equipment-Key public key of one embodiment may be transmitted to (or received by) a system component, such as SCM120, only if the system component does not already have the stored Equipment-Key public key. This may occur during manufacturing or following a factory reset. Additionally, or alternatively, the Equipment-Key public key may be transmitted only by a manufacturing tool to another system component. In an alternative embodiment, the Equipment-Key public key may not be transmitted by a manufacturing tool to another system component.

[0262] In an alternative embodiment, the Equipment-Key may be shared across all of the devices 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, SCM120 may not be able to communicate with a particular device 140 without approval from device 110, user 10, or cloud 130. Additionally, or alternatively, the device 140 may not be required to approve itself.

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

[0265] In one embodiment, the Equipment-Key public / private keys may be modified and / or generated as a result of key cycling 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 yet 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 instead of the Equipment-Key key.

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

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

[0269] The SCM-Equipment-Key is optional. It is intended for equipment manufacturers who wish to use an externally generated key provided by the SCM120 to communicate with one or more Equipment140 systems. The Equipment-Key is a reverse-use model.

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

[0271] The SCM-Equipment-Key key may be separated from the SCM-Key key so that the equipment manufacturer may use any security model it deems desirable, including a model in which equipment 140 is not sufficiently protected and therefore it is preferable not to even disclose the SCM-Key public key.

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

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

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

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

[0276] There may be one or more devices 140 that are attached to a particular SCM 120. In this way, system 100 can define a 1SCM multi-device system. In a 1SCM multi-device system, device 110 may obtain the status of individual devices 140 or any combination thereof, issue commands, and / or receive responses from individual devices 140 or any combination thereof.

[0277] An SCM-Equipment-Key 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 (e.g., equipment 140) if the system component already has a stored Equipment-Key public key.

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

[0280] In one embodiment, an SCM-Key may be used instead of an SCM-Equipment-Key. In such a case, various specified SCM-Equipment-Key processing 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 can still be stored securely. For example, the SCM-Equipment-Key private key may be encrypted at quiescent, and software-based and / or hardware-based countermeasures may be implemented to prevent access to such data, or hardware and / or physical obstacles or shields may be implemented. JTAG and other ports may be disabled. Enhanced software interfaces may be implemented to eliminate attack vectors. A trusted execution environment, hardware or software may be established, and a detection system may be implemented to detect any incursions of root access or security breaches to the operating system. In an alternative embodiment, the SCM-Equipment-Key private key is not stored securely.

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

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

[0284] A plurality of system components (e.g., device 140) can communicate with a single SCM 120, and a plurality of pairs of SCM-Equipment-Key public / private keys 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, instead of the SCM-Equipment-Key, another authentication key or token type and / or challenge / response mechanism may be used.

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

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

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

[0289] This technique allows the exposure of each compromised Device-SCM-Key to a single SCM120, so that a virtually unique Device-SCM-Key can be used for each device / SCM pair. This is in contrast to exposure to all SCM120 associated with a particular device 110, as would occur if a single key were used (e.g., with the Device-Key) for all SCM120 associated with that particular device 110.

[0290] In one embodiment, the Device-SCM-Key private key may be securely stored in the device 110 within the secure memory 220, or within a secure element such as a secure enclave or hardware security module (HSM), or an equivalent hardware module. The Device-SCM-Key private key does not need to be transmitted to other system components. On the other hand, the Device-SCM-Key public key may be securely transmitted to and stored in a system component that utilizes the Device-SCM-Key public key, such as the cloud 130.

[0291] The Device-SCM-Key private key may be used by 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 device 110. These messages may or may not be sent directly to device 110, such as during the authorization issuance process, or when 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 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 SCM 120 to the associated device 110.

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

[0293] While a change in Device-ID is not expected, some system components may allow the device owner 10 to report changes as security anomalies or product failures. Security anomalies may be the result of tampering, impersonation attempts, or protocol violations. Even with the same physical device 110, a given device 110 may cycle through numerous unique Device-IDs throughout its product lifecycle if applications are removed and reinstalled, or if memory is wiped or upgraded; therefore, product failures may result from memory corruption.

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

[0295] In alternative embodiments, the Device-ID may not be specific to a particular device 110. Examples of non-specific types of Device-IDs include International Standard Book Numbers (ISBNs), USB device identifiers, and product models, classes, or types.

[0296] In one embodiment, the Device-ID may not be stored securely. For example, the Device-ID may not be used for secure storage if it is only used for logging or reporting purposes, or as part of additional identification information that is not dependent on any system component.

[0297] Please understand that in one or more embodiments, the Device-ID may not exist or may not be used.

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

[0299] In one embodiment, there may be multiple identifiers similar to the Device-ID, and each identifier may not be unique to a particular device 110. For example, device 110 may include a cellular identifier that includes 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 Mobile Device Identifier (MEED), a device name, or a user identifier, or any combination thereof.

[0300] A Device-SCM-ED may be similar to a Device-ED, but in the illustrated embodiment, the Device-SCM-ED is intended for use with a constrained device or a constrained bandwidth interface, or both. In one embodiment, the Device-SCM-ED 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 system 100. A Device-SCM-ED may be relatively smaller in size than a Device-ED with respect to storage and / or representation (e.g., 8-bit or 16-bit vs. 32 or 64-bit).

[0301] Device-SCM-ED may be transferred via System 100 to other system components such as Cloud 130, Device 110, and SCM 120, and used by them, in order to help establish a secure communication channel between Device 110 and SCM 120. In one embodiment, Device-SCM-ED may be stored only in Cloud 130 so that it can be delivered within ACP 400 and / or ACP container 410. Device-SCM-ID may, in some cases, not be transferred or stored securely.

[0302] Changes to 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, impersonation attempts, or protocol violations. Even with the same physical device 110, a given device 110 may cycle through a large number of unique Device-SCM-IDs throughout its product lifecycle if applications are removed and reinstalled, or if memory is wiped or upgraded, so product failures may result from memory corruption.

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

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

[0305] In one embodiment, the Device-Key may be unique to a specific 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 by 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 can still be stored securely. For example, secure storage without secure memory 220 can be achieved by one or more of the following: the Device-SCM-Key private key may be encrypted at quiescent; software-based and / or hardware-based countermeasures may be implemented to prevent access to such data; and hardware and / or physical obstacles or shields may be implemented. JTAG and other ports may be disabled. Enhanced software interfaces may be implemented to eliminate attack vectors. A trusted execution environment, hardware or software may be established, and detection systems may be implemented to detect inviting root access or security breaches to the operating system. In alternative embodiments, the Device-SCM-Key private key is not stored securely.

[0308] In one embodiment, the Device-SCM-Key public / private key may be modified, generated, or both as a result of key cycling or a factory reset.

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

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

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

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

[0313] This technique allows for limiting the exposure of each compromised User-SCM-Key to a single SCM120, effectively ensuring that a unique User-SCM-Key is used for each user account / SCM pair. This is in contrast to exposure to all SCM120s associated with a particular user account, as would occur if a single key were used (e.g., using the User-Key) for all SCM120s associated with that user account.

[0314] In one embodiment, the User-SCM-Key private key may be securely stored by the user account service of Cloud 130. The User-SCM-Key private key does not need to be sent to other system components. On the other hand, the User-SCM-Key public key may be securely sent to and stored in a system component that utilizes 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 SCM120, and may be used to decrypt and / or verify messages sent from the associated SCM120 to the user account service. The User-SCM-Key public key may be used by the SCM120 to decrypt and / or verify messages originating from the user account service, and may be used to encrypt and / or sign messages from the SCM120 to the user account service.

[0316] In one embodiment, a User-SCM-Key may be used instead of a Device-SCM-Key. In this embodiment, 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 the Device-SCM-Key are used. In this embodiment, for example, the ACP outer layer 2 of the ACP400 may be signed using the User-SCM-Key, while the device 110 is authenticated separately using the Device-SCM-Key.

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

[0319] In one embodiment, the User-SCM-Key public key may not be securely transmitted to and / or stored by 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 Secure Element, or an equivalent hardware module. However, the User-SCM-Key private key can still be stored securely. For example, secure storage without Secure Memory 220 can be achieved by one or more of the following: the User-SCM-Key private key may be encrypted at quiescent; software-based and / or hardware-based countermeasures may be implemented to prevent access to such data; and hardware and / or physical obstacles or shields may be implemented. JTAG and other ports may be disabled. Enhanced software interfaces may be implemented to eliminate attack vectors. A trusted execution environment, hardware or software may be established, and a detection system may be implemented to detect any incursions of root access or security breaches to the operating system. In alternative embodiments, the User-SCM-Key private key is not stored securely.

[0321] In one embodiment, the User-SCM-Key public / private key may be modified or generated, or both, as a result of key cycling 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, a different authentication key or token type and / or challenge / response mechanism may be used instead of the User-SCM-Key.

[0323] In one embodiment, one or more User-SCM-Key keys may be created and stored by the user account service of cloud 130 for a specific SCM120 (or for all SCM120 as a global key pool) for later use. This technique avoids requiring the user account service of cloud 130 to generate such keys during normal operation. Multiple keys may be utilized so that the user account service of cloud 130 can support key circulation and / or multiple SCM120s. In this embodiment, the user account service of cloud 130 can manage which User-SCM-Key keys are available but not in use, in use, discarded, or removed.

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

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

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

[0327] A substantially unique Cloud-SCM-Key key may be used for each cloud / SCM pair. This approach can substantially limit the exposure of a compromised Cloud-SCM-Key key to a single SCM120, unlike all SCM120 associated with a particular cloud 130. This is in contrast to exposure to all SCM120 associated with a particular cloud 130, as would occur if a single key were used (e.g., with Cloud-Key) for all SCM120 associated with that particular cloud 130.

[0328] The Cloud-SCM-Key private key may be securely stored in the secure memory 220 of the cloud 130, or within 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 to and stored in a system component that utilizes the Cloud-SCM-Key public key, such as the cloud 130, device 110, or 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, or 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, or to encrypt and / or sign messages from the SCM 120 to the cloud 130. The message may or may not be sent directly to SCM120. For example, during the authorization issuance process, the signed ACP400 may be sent to the owner device 110 for approval. After approval, the cloud 130 may sign the completed ACP container 410 (including the previously signed ACP400) which is delivered to SCM120 via device 110.

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

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

[0331] In one embodiment, the Cloud-Key key may be specific to a particular cloud 130 and / or cloud service, instead of the Cloud-SCM-Key key. In this embodiment, the Cloud-Key may be generated during the provisioning and / or initial setup of the cloud 130.

[0332] In one embodiment, the Cloud-SCM-Key public key may not be securely transmitted to and / or stored in 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 Secure Element or equivalent hardware module. However, the Cloud-SCM-Key private key can still be stored securely. For example, secure storage without Secure Memory 220 can be achieved by one or more of the following: the Cloud-SCM-Key private key may be encrypted at quiescent; software-based and / or hardware-based countermeasures may be implemented to prevent access to such data; and hardware and / or physical obstacles or shields may be implemented. JTAG and other ports may be disabled. Enhanced software interfaces may be implemented to eliminate attack vectors. A trusted execution environment, hardware or software may be established, and detection systems may be implemented to detect inviting root access or security breaches to the operating system. In alternative embodiments, the Cloud-SCM-Key private key is not stored securely.

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

[0335] In one embodiment, one or more certificates may be used for the Cloud-SCM-Key key. Alternatively, the Cloud-SCM-Key key may be a symmetric key. In another alternative embodiment, the Cloud-SCM-Key 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 instead of the Cloud-SCM-Key key.

[0336] In one embodiment, one or more Cloud-SCM-Key keys may be created for a specific SCM120 (or for all SCM120s as a global key pool) for later use and stored in the cloud 130. This technique avoids requiring the cloud 130 to generate such keys during normal operation. Multiple keys may be utilized so that the cloud 130 can support key circulation and / or multiple SCM120s. In this embodiment, the cloud 130 can manage which Cloud-SCM-Key keys are available but not in use, in use, discarded, or removed.

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

[0338] The Root-Cert may be the root certificate of system 100 according to one embodiment. The Root-Cert may be a self-signed certificate that establishes the trust roots of system 100. The private Root-Cert may be stored offline or securely on a server that is not generally accessible to cloud 130 or other system components. The public Root-Cert may be distributed to cloud 130 and each system component that can communicate with cloud 130, such as device 110 or 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 examples of system 100, cloud 130, cloud service, or device 110 and 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, system 100 may be configured to have one trusted root for online verification and another for offline verification.

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

[0342] The content and / or creation process of the Root-Cert may differ 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] In the illustrated embodiment, the Cloud-Node-Cert is a certificate signed by the private Root-Cert of the corresponding system 100. Thus, each Cloud-Node-Cert can form part of a chain of trust for verifying the identity of a particular cloud server 130. Private Cloud-Node-Certs may be securely stored in each cloud server 130. Public Cloud-Node-Certs may be delivered to the cloud 130 and to each system component that may communicate with the cloud 130, including, for example, device 110 and OEM cloud 135. If any other encryption keys are materialized as certificates rather than encryption keys, these certificates may be signed by the Root-Cert or Cloud-Node-Cert, or an alternative trust root certificate.

[0344] In one embodiment, there may be multiple layers of Cloud-Node-Cert, such as layers for different examples 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, i.e., a higher-level private Cloud-Node-Cert, thereby forming a longer chain of trust.

[0345] Cloud-Node-Cert can be signed in various ways. For example, in one embodiment, Cloud-Node-Cert may be self-signed, or it may be signed by a non-parent certificate or an asymmetric private / public key.

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

[0347] The Device-Rights-Key key can uniquely identify a specific device 110 to the rights management system of Cloud 130. The Device-Rights-Key key may be an asymmetric private / public key pair generated and stored by device 110 at some point before device 110 is first registered with Cloud 130. The Device-Rights-Key private key can be securely stored in secure memory 220 within 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 to and stored in system components that utilize the Device-Rights-Key public key, such as Cloud 130.

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

[0349] In one embodiment, the Device-Rights-Key key may not be substantially unique for each device 110. Examples of such configurations include the Device-Rights-Key key being substantially unique for each account, used for a certain number of devices 110 within an account, or being identical across all devices 110 or unique only to a specific 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 owned by a particular organization and used for all devices 110.

[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 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 to and / or stored by 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 can still be stored securely. For example, secure storage without secure memory 220 can be achieved by one or more of the following: the Device-Rights-Key private key may be encrypted at quiescent; software-based and / or hardware-based countermeasures may be implemented to prevent access to such data; and hardware and / or physical obstacles or shields may be implemented. JTAG and other ports may be disabled. Enhanced software interfaces may be implemented to eliminate attack vectors. A trusted execution environment, hardware or software may be established, and detection systems may be implemented to detect inviting root access or security breaches to the operating system. In alternative embodiments, the Device-Rights-Key private key is not stored securely.

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

[0355] In one embodiment, one or more certificates may be used for the Device-Rights-Key key. Alternatively, the Device-Rights-Key key may be a symmetric key. In another alternative embodiment, the Device-Rights-Key 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 instead of the Device-Rights-Key key.

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

[0357] In one embodiment, the Device-Rights-Key key may not exist, in which case an authorization type or some other means may be used to establish the device rights, or some other means may be used to enable device 110 to communicate with and / or verify the authenticity of the rights management system of 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 containing ACP version information) to uniquely identify a specific pairing (or cloud / SCM pair) between the cloud 130 and the SCM 120. In the illustrated embodiment, the ACP-Version-Key key is an asymmetric private / public key pair generated and stored by the cloud 130 when the initial owner device 110 is established with the SCM 120 after a factory reset, such as during manufacturing, or when ownership is transferred. In the illustrated embodiment, the ACP-Version-Key key may not be provided to device 110.

[0359] A potentially unique ACP-Version-Key may be used for each cloud / SCM pair. This approach can substantially limit the exposure of each compromised ACP-Version-Key to a single SCM120, unlike all SCM120 associated with a particular cloud 130. This is in contrast to the exposure to all SCM120 associated with a particular cloud 130, as would occur if a single key were used (e.g., with one ACP-Key) for all SCMs associated with that particular cloud 130.

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

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

[0362] In one embodiment, the ACP-Version-Key private key may be generated and managed in a similar manner to the SCM-Key. For example, the ACP-Version-Key private key may reside on the SCM120, while the public key may reside in the cloud130.

[0363] In an alternative embodiment, an ACP-Key key specific to a particular cloud 130 may be implemented instead of the ACP-Version-Key key.

[0364] In one embodiment, the ACP-Version-Key public key may not be securely transmitted to and / or stored by 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 can still be stored securely. For example, secure storage without secure memory 220 can be achieved by one or more of the following: the ACP-Version-Key private key may be encrypted at quiescent; software-based and / or hardware-based countermeasures may be implemented to prevent access to such data; and hardware and / or physical obstacles or shields may be implemented. JTAG and other ports may be disabled. Enhanced software interfaces may be implemented to eliminate attack vectors. A trusted execution environment, hardware or software may be established, and a detection system may be implemented to detect any incursions of root access or security breaches to the operating system. In an alternative embodiment, the ACP-Version-Key private key is not stored securely.

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

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

[0368] One or more certificates may be used as the ACP-Version-Key key. Alternatively, the ACP-Version-Key key may be a symmetric key. In another alternative embodiment, the ACP-Version-Key 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 instead of the ACP-Version-Key key.

[0369] In one embodiment, one or more ACP-Version-Key keys may be created for a specific SCM120 (or for all SCM120s as a global key pool) for later use and stored in the cloud 130. This technique avoids requiring the cloud 130 to generate such keys during normal operation. Multiple keys may be utilized so that the cloud 130 can support key circulation and / or multiple SCM120s. In this embodiment, the cloud 130 can manage which ACP-Version-Key keys are available but not in use, in use, discarded, or removed.

[0370] In one embodiment, the ACP-Version-Key may not exist, in which case other means may be used for the system component to communicate with the ACP container version package 412 and / or to verify the authenticity of the ACP container version package 412. In one embodiment, the system component may not need to verify the authenticity of all 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 stores and can use two or more ACPs 400, it may be considered 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 using multiple ACP-Version-Key keys. K.Device-SCM-Session-Key

[0372] The Device-SCM-Session-Key key may be a target key used to secure communication between a pairing (or device / SCM pair) defined between a particular device 110 and SCM 120 after at least one pair has been authenticated, so as to be authenticated in a manner similar to a TLS master secret. To improve system performance and responsiveness with constrained system components, the Device-SCM-Session-Key key may persist the connection (e.g., in a manner similar to continuing a TLS session) or may be periodically cycled 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 can be done in a similar manner to a TLS session ID or session ticket.

[0375] In one embodiment, the Device-SCM-Session-Key key is an asymmetric key pair. Alternatively, the Device-SCM-Session-Key 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 instead of the Device-SCM-Session-Key key.

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

[0377] System components (such as device 110) communicating with Cloud 130 and / or OEM Cloud 135 may obtain an OEM Cloud Session Token and / or Cloud Session Token during the 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 can be mapped to specific Cloud-User-EDs and OEM-EDs, allowing Cloud 130 to restrict access to data associated with specific Cloud-User-EDs and OEM-EDs. OEM Cloud 135 can communicate with Cloud 130 using the Cloud-to-OEM Cloud Session Token. The Cloud-to-OEM Cloud Session Token may be similar to a Cloud Session Token, except that it can restrict access only to data associated with specific OEM-IDs.

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

[0379] In one embodiment, the OEM cloud session token and the cloud session token may be the same. Alternatively, the OEM cloud session token may not be used. In an alternative embodiment, 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 that are single-purpose and / or temporary may exist within System 100. An example of a single-purpose key is one used within a specific message set or internally for a specific system component. An example of a temporary key is a session key used between other system components operating within the context of a standard security protocol such as TLS or DTLS. N. User

[0381] In one embodiment, user 10 may play a role similar to that of a cryptographic key in the system. User 10 has the following potentially unique properties / features that can be incorporated as a cryptographic key used for authentication (or two-factor or multi-factor authentication) mechanisms or in connection with authorization gates by system components within system 100: 1) Eyes and / or face (e.g., retina / facial key / signature, visual confirmation of receipt) 2) Fingerprints (e.g., fingerprint key / signature, Apple Touch ID or other verification 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 the device screen) 7) Proximity (e.g., proximity based on minute position or proximity based on IR detection to system components) 8) Access (e.g., demonstrated physical access to system components such as button pushes) 9) Proximity to or access to other devices (e.g., other user devices such as a watch or band) XIII. Key Cycle

[0382] In one embodiment, key cycling, also known as key rotation or key updating, is a process in which keys are changed for existing objects without directly notifying the user of the change or requiring interaction with the user. For example, keys can be changed for objects including authorization, device 110, SCM 120, cloud 130, equipment component 130, and OEM cloud 135.

[0383] Keys can be cycled periodically, such as every few hours, daily, weekly, monthly, every six months, or annually, or when a breach or anomaly is detected. Changes can be made automatically or manually, such as through administrative or operational actions.

[0384] Properly supporting key cycling may be a significant task for system 100. One problem with system components that may be offline is that a key change request may not be delivered to the target system component before another key change request has been made. For example, sequential key cycling can result in non-delivery or delayed delivery of key changes. Configuration changes that depend on keys (e.g., ACP400) may also result in non-delivery or delayed delivery due to the system component being offline. This is unlikely for many system components, as key changes are delivered quickly. However, SCM120 may remain unused for days, months, or even years, and therefore some key cycling events may be missed, after which the previous owner may be unable to transfer SCM120 to a new owner using system 100. More specifically, in this case, SCM120 would be unable to decrypt the updated ACP400 or updated ACP container 410 and / or authenticate the cycled device 110. In this case, a factory reset of the SCM120 might be acceptable. In another scenario, if a circular event of multiple keys occurs that renders the SCM120 unusable (by the owner or guest) over several hours, this might be unacceptable from a user experience or usability standpoint.

[0385] Key cycle events affecting multiple keys are also possible. Multiple keys can be affected under various circumstances, such as a system-wide key cycle, in a device 110 managing multiple SCM120s, or in an SCM120 with multiple authenticated accounts and / or devices 110. An example sequence is shown below.

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

[0387] At some point after Cloud 130 has received the updated Device-SCM-Key (and any other required input keys) from all Device 110 associated with SCM 120, Cloud 130 sends the updated ACP400 ("Version 2") to Device 110 for distribution to SCM 120 (e.g., via ACP container 410) (Step 1203). Device 110 distributes the updated ACP400 to SCM 120, which includes all required updated keys (Step 1204). SCM 120 notifies Device 110 that the ACP400 update was successful (Step 1205). Device 110 notifies Cloud 130 that SCM 120 has applied ACP400 "Version 2". This allows Cloud 130 to maintain the correct set of keys for the correct version of ACP400 for each SCM120, and as a result, if an SCM120 or device 110 (or other system component) fails to update its keys, previous updates can be delivered in order for recovery, or the latest update can be delivered using the previous keys (step 1206).

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

[0389] To cycle the keys in SCM120, both the "new key" and the "old key" (known key) may be included in the ACP400 for the target SCM120. Each time an ACP400 is accepted by SCM120, an acknowledgment of receipt 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 SCM120 last accepted, the cloud 130 can prevent the generation of subsequent ACP containers 410 for that SCM120, including key changes where the "old key" field is different from the (previous / rejected) ACP400 being sent, until the ACP400 being sent is accepted by SCM120.

[0390] In an alternative embodiment, regardless of which ACP400 is accepted by SCM120, Cloud 130 may send a normal subsequent ACP container 410 to SCM120. In this embodiment, minimal preceding versions may be added to the ACP container version package 412, ACP container 410, ACP400, and / or the cloud API response.

[0391] If SCM120 detects that its current ACP version is not equal to or greater than the minimum preceding version (i.e., the last version for which SCM120's current set of keys was valid), SCM120 may reject the ACP update and request the minimum preceding version. This results in a series of rollbacks of older ACP containers 410, after which the updated packages will be sent in order or performed by a sending system component (e.g., device 110). Rejection of ACP updates may be accompanied by Cloud 130 maintaining a copy of the previously committed ACP container 410 for each SCM120, or at least for SCM120s that have not received the latest ACP.

[0392] Additionally or alternatively, a minimum prerequisite version may be communicated only to the receiving system component via a response to the cloud API, after which the receiving system component can request the appropriate ACP container 410. Additionally or alternatively, the cloud 130 may sequentially provide only the executable ACP containers 410 to the SCM 120; that is, the cloud does not need to perform any reordering.

[0393] In one embodiment, if an ACP400 being transmitted has not yet been accepted by a particular SCM120, the cloud 130 does not need to send subsequent ACP containers 410 to that SCM until the ACP400 being transmitted is accepted.

[0394] In one embodiment, if an ACP400 being transmitted has not yet been accepted by a particular SCM120, the cloud 130 may merge the key change being transmitted into a new ACP version. 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 SCM120.

[0395] In the illustrated embodiment, the ACP container 410 targets a specific SCM 120 and is signed by one or more system components or services, so 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 simultaneously.

[0396] With respect to an ACP container 410 containing only a circular key, in one embodiment where authorization is not issued to an account (for example, authorization is issued to a specific device 110 instead), 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 indicating that the owner device identifier is a circular key ACP 400, and then the ACP outer layer 2 may be encrypted using a key used by another layer (for example, ACP outer layer 1 or ACP outer layer 3). Additionally or alternatively, the circular key ACP 400 may not be encrypted, in which case the signature and key fields may be used for further verification.

[0397] With respect to an ACP container 410 containing only circulating keys, in one embodiment where authorization is issued to an account, 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] ACP400 may have a key cycle attribute that can be configured to further verify the legitimacy of the package. Legitimacy may indicate that the encryption of ACP outer layer 2, or its absence, was intentional. During the verification of ACP container 410, SCM120 may verify that the current key of SCM120 (i.e., the key received by SCM120 and identified in the previous ACP400) matches the "old key" in the new ACP. If either key does not match, ACP400 may be rejected.

[0399] In an alternative embodiment, the SCM120 may verify that the authorization has not been updated for the key circulation ACP400 (except for the keys related to authorization). In yet another alternative embodiment, only the keys may be updated for the key circulation ACP400.

[0400] In an alternative embodiment, the owner device 110 may be configured to approve and, if possible, sign the key change ACP400 with or without user intervention. The owner device 110 may simply sign the ACP400 automatically in this situation. In an alternative embodiment, the owner device may be configured to approve and, if possible, sign the key change ACP400 with user intervention. User 10 may be asked to approve the ACP400 as if it were any other authorization change.

[0401] When cycling keys, system components may retain zero or more preceding keys for a period of time to assist in addressing missed key cycles in ACP400. System components may attempt to use earlier keys if more recent keys fail. System components may retain preceding keys until it is determined that doing so is no longer necessary, such as after a new key is used, after another configuration arrives, or after a certain period of time has elapsed.

[0402] In one embodiment, when a key is circulated, the connection to the entity using the key may be re-established or at least re-verified. Examples of such connections include device / SCM pairs, cloud / device pairs, and equipment / SCM pairs. While key circulation can be cumbersome in some respects if poor implementation degrades the user experience, it can be viewed as a security measure and is not necessarily cumbersome. In one embodiment, a key may be circulated to prevent a breach using a hacked device, thereby causing a system component such as an SMC120 to disconnect in order to force a reconnection. In the case of a hacked device, the attempt to reconnect would likely fail.

[0403] In an alternative embodiment, key changes to the SCM120 may be delivered in a similar manner to how they are delivered within the ACP container 410, or they may be delivered in a separate package, such as a Key Change Package (KCP), which may or may not have a separate KCP version tracked by the cloud 130 for each SCM120. If such a method is used and a KCP version is 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 circulation. Device 110, the cloud server 130, the equipment component 140, the OEM cloud 135, and others (if any) can also be configured to update keys in response to a breach.

[0405] A key circulation request can originate from Cloud 130, and each system component may verify that the key circulation request is authentic. As described herein, each system component may possess a number of keys. Zero or more of these keys may be generated by that system component, and zero or more may be obtained from other system components. Since each system component can generate at least one of these keys, the key circulation process may involve cooperation, coordination, and ordering of multiple system components.

[0406] The SCM120 may not generate its own keys, and therefore may not be required to circulate keys. In this case, the SCM120 becomes the receiver of the key circulation process. Keys not generated by the SCM120 include at least one of the SCM-Key and SCM-Equipment-Key.

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

[0408] In an alternative embodiment, SCM120 may generate its own keys and therefore may be required to circulate keys. In an alternative embodiment, a system component may circulate a particular key or initiate a key circulation and issue a new key to Cloud 130 for distribution.

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

[0410] In another alternative embodiment, system 100 does not have to directly support key cycling and instead may utilize processes within system 100 to perform one or more of the following: delete 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] In the embodiment illustrated in Figure 14, the device / SCM communication channel may employ a step-by-step, slow authentication process or method, or both, to improve the user experience (responsiveness) and enable communication with the device 110 in a way not previously seen by the SCM 120. The secure connection process may occur on any communication link, but may be configured for relatively slow and insecure wireless communication links between constrained hardware, such as Bluetooth Slow Energy (BLE) communication links.

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

[0413] The pre-unknown communication link initialization and connection sequences can 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 transmission / reception connection / connection protocol sequences / processing may differ somewhat due to differences in the underlying technologies. Furthermore, differences in the underlying technologies may allow one or more protocol steps to be combined into a single step (conversely, it may be useful or necessary to split a single step into many smaller steps to overcome very small packet / message limits). However, the higher-level protocol steps can remain the same. In the illustrated embodiment, the connection establishment process is performed using Bluetooth Low Energy (BLE), but this disclosure is not limited to this.

[0414] Significant effort may have been expended to set up a pre-unknown communication link before the SCM120 and device 110 reached the start of the unknown phase—step 1401. One such example is the application of this embodiment in combination with the systems described in U.S. Patent Application No. 14 / 620959 by J. Michael Ellis et al., filed February 12, 2015, entitled “System and Method for Communicating with a Vehicle,” and U.S. Patent Application No. 15 / 488136 by Raymond Michael Stitt, filed April 14, 2017, entitled “System and Method for Establishing Real-Time Location.” Their disclosures, including a microlocation system using BLE, are incorporated herein by reference in their entirety. A method using this system is shown in an illustrated embodiment in Figure 13 and designated 1300. Method 1300 can use a connection strategy in which the master device (SCM120) starts as peripheral and the portable device (device 110) starts as central (initial connection) (step 1301). After agreeing to communicate with each other, the roles are switched, with the master device 110 becoming the central and the portable device 110 becoming the peripheral as part of the microlocating 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 the systems described in U.S. Patent Application No. 14 / 620959 filed February 12, 2015, entitled “System and Method for Communicating with a Vehicle,” and U.S. Patent Application No. 15 / 488136 filed April 14, 2017, entitled “System and Method for Establishing a Real-Time Location,” the disclosures thereof are incorporated herein by reference in their entirety. • Unknown communication link - initial connection

[0416] A previously unknown communication link can be the initial connection in relation to Method 1300. In other words, Device 110 and SCM 120 have not yet exchanged roles, and therefore the initial interaction 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 security phase or a trust phase within the context of the initial connection. The process can be completed through either a security phase or a trust phase, depending on whether mutual authentication is performed during the unknown phase or the security phase.

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

[0419] This technique allows the SCM120 to properly deliver device connections to alternative system components (e.g., the SCM120 or a similar module) at the boundary of role reversal. 2. Unknown prior communication link - Microlocation connection

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

[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] In the illustrated embodiment of Figure 14, the initial connection in the microlocation system begins when device 110 decides to connect to a particular SCM 120. For example, device 110 may decide to connect to SCM 120 because it recognizes SCM 120 as a system component that device 110 believes to be either a) configured to communicate with, b) wants to own SCM 120, or c) is a nosy (or malicious) device that connects to SCM 120.

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

[0424] In this approach, device 110 may be unable to authenticate SCM120, and / or SCM120 may be unable to authenticate device 110 before deciding whether to switch to a microlocation connection or attempt to establish a secure communication channel with device 110.

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

[0426] In one embodiment, since some device platforms / libraries do not allow BLE peripherals to advertise all desired information during background processing mode, the SCM120 and / or device 110 may store BLE coupling information to complete the transition to a microlocation connection. In an alternative embodiment, the BLE coupling may be completed on behalf of the user during the initial connection phase. B. Establishing a secure connection

[0427] Device 110 can initiate a connection with SCM 120 according to the embodiment illustrated in Figure 14. SCM 120 can accept the connection and initiate the connection establishment process, which consists of steps 1401 - first (unknown) phase, step 1402 - second (safe) phase, and step 1403 - third (trust) phase. • Phase 1 (unknown)

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

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

[0430] During this phase, or in step 1401, device 110 may send a request to SCM 120 to switch to a secure communication channel (step 1410). This request may prompt 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 contained within the ACP container version package 412. The Device-SCM-ID can be used by SCM 120 to determine which set of cryptographic keys to use for subsequent messages, such as Device-SCM-Key, ACP-Version-Key, or Device-SCM-Session-Key, or a combination thereof.

[0431] As described in section (Section III) of at least ACP container 410, SCM120 may not allow a transition to a secure communication channel if ACP400 should be updated. If SCM120 determines that ACP400 should be updated, SCM120 may send a request back to device 110 to send the updated ACP400.

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

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

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

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

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

[0437] In one embodiment, SCM120 may verify the authenticity of device 110 (instead of device 110 verifying the authenticity of SCM120) during this phase or step 1401. As a result, in a later stage, when a command is sent, device 110 may verify the authenticity of SCM120.

[0438] In one embodiment, in addition to or as an alternative to one or more embodiments described herein, device 110 and SCM 120 may authenticate each other during step 1401. If successful, devices 110 and SCM 120 may proceed to the trust phase.

[0439] The SCM120 may be configured to disconnect from the device 110 after a predetermined period of inactivity. The SCM120 may disconnect from the device 110 at any time or in response to any event. For example, the SCM120 may disconnect due to high system resource utilization in the SCM120, failure to respond to a request within a predetermined time, or connection duration exceeding a predetermined maximum duration.

[0440] As described at the beginning of this Section XIV.B, SCM120 may request device 110 to send the ACP container 410 with the ACP container version package 412. Device 110 may send the ACP container 410 to SCM120 during this phase. In response to receiving the ACP container 410, SCM120 may provide a response with a status indicator that may or may not indicate that the ACP container 410 was accepted, not processed, or rejected. Acceptance may indicate that the ACP container 410 has been processed and stored, and that any changes contained in the ACP container 410 have been successfully applied. Not processing may be due to the ACP container 410 being old or the same version. Rejection may indicate that verification failed. In an alternative embodiment, SCM120 may not provide a status indicator to device 110 regarding the ACP container 410 in order to update processing.

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

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

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

[0444] Messages from devices 110 and SCM120 using a secure communication channel may be encrypted and sent using the Device-SCM-Session-Key session key along with an incrementing sequence number to perform MAC (e.g., encrypt the message using the Device-SCM-Session-Key and append a MAC [Message Authentication Code] calculated from the encrypted message), thereby enabling devices 110 and SCM120 to verify and authenticate the sent / received messages. This communication mode may resemble some features of TLS / DTLS. Note that other methods besides post-encryption MAC may be used (e.g., post-MAC encryption, or encryption and MAC), however these may be less secure.

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

[0446] Session keys can be cycled by executing a session key rolling algorithm within an existing secure communication channel and / or by computing a new session key using a challenge-response authentication process or another process similar in some respects to the processes described herein with respect to the unknown phase and the computation of session keys during the unknown phase. Additionally or alternatively, session keys can be cycled by invalidating a stored session key and then disconnecting and re-establishing the session key during the unknown phase. In one embodiment, device 110 can initiate the cycling of session keys.

[0447] At the start of step 1402, device 110 may send either a request to SCM 120 to verify that the session key (Device-SCM-Session-Key) is valid (verify that the channel is operational), or a request to verify both the validity of the channel and the authenticity of SCM 120 (steps 1416, 1418). For example, if an existing session key is used, such as when the previous phase has not been performed recently, the validity and authenticity of SCM 120 may be verified (step 1418).

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

[0449] To complete the session key verification step 1418, device 110 and SCM120 may execute a challenge-response protocol in the security phase. The primary purpose of this protocol is for device 110 to verify the channel's operation when the authenticity of SCM120 has already been established and the system is immediately moving from the unknown phase to the verification phase. However, the challenge-response protocol in the security phase may be used periodically by either device 110 or SCM120 to maintain the channel connection or for other purposes. An example of a (simple) challenge-response protocol is shown below. 1) Device 110 (or SCM120) can generate a random number (N). 2) Device 110 can transmit N to the SCM. 3) SCM120 can calculate N+1(M). 4) SCM120 can send M to device 110. 5) Device 110 can verify that N+1 is equal to M. If they do not match, the verification will fail, presumably because the message was not communicated properly.

[0450] When device 110 executes the challenge-response protocol in the secure phase, device 110 may verify that the communication channel is operational. At this stage, device 110 does not need to verify anything about the authenticity of SCM 120, except that SCM 120 possesses the correct session key. The roles of SCM 120 and device 110 may be reversed, as SCM 120 can also initiate the challenge-response protocol in the secure phase to verify the secure communication channel. In an alternative embodiment, the challenge-response protocol in the secure phase may not be utilized. In this case, an authentication protocol may always be used, or no authentication protocol may exist.

[0451] In one embodiment, device 110 may use a secure phase challenge-response authentication protocol to verify the authenticity of SCM 120. The secure phase challenge-response authentication protocol may be executed periodically when the secure phase is entered after a predetermined period of time, or when any other event occurs. Exemplary events include SCM 120 requesting device 110 to execute the secure phase challenge-response authentication protocol, and the updated ACP 400 being received by 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 can be implemented as follows (alternative challenge-response authentication protocols may also be used): 1) Device 110 can generate an encryption nonce (N). 2) Device 110 can transmit N to the SCM. 3) The SCM120 can compute N+1(M) cryptographic hashes. 4) The SCM120 can create MS by encrypting M with the SCM-Key (private) key. 5) SCM120 can send MS to device 110. 6) Device 110 can decrypt the MS using the SCM-Key (public) key and create the MSD. 7) Device 110 can calculate an N+1(MD) cryptographic hash. 8) Device 110 can verify that MD is equal to MSD. If they do not match, authentication will fail because SCM120 may not possess the appropriate encryption key to prove its authenticity.

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

[0453] Similar to the described processing in the unknown phase, device 110 may send the ACP container version package 412 to SCM 120 using a secure communication channel. For example, device 110 may send the ACP container version package 412 in response to, or based on, the device's receipt of an updated ACP container 410. If SCM 120 determines that it needs or wants to receive the corresponding ACP container 410, SCM 120 may request device 110 to send the ACP container 410 accompanying the ACP container version package 412. SCM 120 may also request device 110 to send the most recent ACP container version package 412 stored in device 110 periodically or in response to the occurrence of an event.

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

[0455] In one embodiment, the firmware update package (FUP) may be delivered from device 110 to SCM 120 only via a secure communication channel, such as during the security or trust phase. Device 110 can obtain the FUP from the cloud 130 or as part of an executable / loadable image stored in 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 delivered from device 110 to SCM 120 via any communication channel. In one embodiment, the FUP may be delivered from device 110 to SCM 120 only via a secure communication channel authenticated by device 110, such as only during the trust phase. In one embodiment, the FUP may be delivered from device 110 to SCM 120 only by the owner device 110. In one embodiment, device 110 does not have to deliver the FUP to SCM 120. Additional or alternative firmware update settings and embodiments are described in at least Section XV, which include additional information relating to the firmware update package itself.

[0457] SCM120 may use a secure communication channel to send a blacklist package to device 110, which will be discussed in more detail herein in at least Section XXI. Device 110 may provide a response to the blacklist package that includes a status indicator. In one embodiment, device 110 may request SCM120 to send a blacklist package to device 110. If there are no items to blacklist, SCM120 may do nothing, or SCM120 may send an indication that there are no items to blacklist.

[0458] Devices 110 and SCM120 may perform various system-level processes in the background while communicating with each other over a secure communication channel. These processes may not involve the explicit execution of commands that utilize authentication and / or authorization for initiation or completion. For disclosure purposes, any process performed as a result of communication between Device 110 and SCM120, or as a result of no communication, is considered a command. Therefore, such background processes are considered commands. Anything that may be performed or an action can be considered a command. There may be operations or actions that occur when nothing is connected (e.g., turning off a light), and there may be operations or actions that occur when something is connected (e.g., tracking a device, turning on a light, etc.). Commands may relate to actions or operations of Device 110 or SCM120, or other system components.

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

[0460] It is also worth noting that in this phase (step 1402), SCM120 may not have explicitly verified the authenticity of the device. Explicit verification may not have been performed recently or initially. However, there may be sufficient evidence to give high confidence that device 110 is authentic. At some point in this phase (step 1402), device 110 and / or SCM120 may generate, issue, or receive commands that can encapsulate sending / receiving one or more of the following commands: 1) Command (e.g., device 110 may be instructing SCM120 or its instrument component 140 to do something); 2) Request (e.g., device 110 may be requesting SCM120 or its instrument component 140 to send data); 3) Update (e.g., SCM120 or its instrument component 140 may be providing periodic / aperiodic data); 4) Response (e.g., SCM120 or its instrument component 140 may be providing a response to a request).

[0461] The SCM120 can perform an action that includes one of the listed commands based on the presence, location, authentication status, or authorization status of device 110, or any combination thereof.

[0462] The above descriptions of various types of commands and things considered to be commands are not exhaustive and are not limited to the list above, nor are the list of commands limited to this phase of communication (for example, a command is a command that is generated, issued, or received, regardless of which phase of communication it is).

[0463] If SCM120 receives a command and device 110 is not authenticated, the command may be queued while device 110 is authenticated. If device 110 fails to authenticate, 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, if device 110 is not yet authenticated, the command may be rejected.

[0465] In one embodiment, system-level background processing may not be permitted unless it is during the trust phase (step 1403).

[0466] To improve the user experience, SCM120 may (preemptively) authenticate device 110 even if no command is sent or received. In another embodiment, SCM120 does not need to preemptively authenticate device 110.

[0467] In one embodiment, for device 110 to send or receive a command to or from 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 authorizing the execution of a 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 can generate a cryptographic nonce (N). 2) SCM 120 can send N to the device. 3) Device 110 can compute a cryptographic hash of N+1 (M). 4) Device 110 can encrypt M using the Device-SCM-Key (private) key to create an MS. 5) Device 110 can send the MS to SCM. 6) SCM 120 can decrypt the MS using the Device-SCM-Key (public) key to create an MSD. 7) SCM120 can calculate an N+1(MD) cryptographic hash. 8) SCM120 can verify that MD is equal to MSD. If MD and MSD do not match, authentication fails. In other words, if MD and MSD do not match, device 110 does not possess the appropriate cryptographic key to prove its authenticity.

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

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

[0470] In one embodiment, authentication of device 110 may be performed by SCM120 on all commands issued by and transmitted by device 110. In one embodiment, authentication of device 110 may be performed on all commands issued by device 110. In one embodiment, authentication of SCM120 may be performed on all commands issued by SCM120.

[0471] If the challenge-response process or challenge-response authentication process fails, devices 110 and SCM120 may immediately disconnect and / or return to an unknown phase in step 1401.

[0472] After SCM120 verifies the authenticity of device 10, device 110 and SCM120 can proceed to the trust phase. 3. The third (trust) phase

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

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

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

[0476] In one embodiment, a mutual authentication challenge-response protocol similar to the challenge-response protocol described above may be implemented, with one or more exceptions. One difference is that both SCM120 and device 110 are authenticated in a single sequence. This single-sequence authentication can incorporate one or more features of TLS / DTL mutual authentication. If the challenge-response authentication process fails, device 110 and SCM120 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 SCM120 and device 110 for use in transferring abstract, user-defined commands and / or data to each other. The ODC allows SCM120 to reliably pass commands and / or data from one system component (e.g., device 110) to another device (e.g., instrument component 140), while ensuring that device 110 is authorized to do so, but likely does not utilize knowledge of device 110's API or data details. One or more of the authorization, verification, and confirmation of commands and / or data used within the ODC may not be performed by SCM120. ACP400 may also include additional information that may be useful with the ODC, such as additional authentication types and identifiers. XV. Firmware Upgrade

[0478] In one embodiment, the system 100 may be configured to ensure that system components can safely and reliably upgrade their firmware. The ability to upgrade firmware can correct security vulnerabilities or firmware defects. Firmware updates can be delivered to the SCM 120 via firmware update packages (FUPs) as described herein.

[0479] FUPs can be received using FUP version packages (similar in many ways to ACP container version packages 412, but adapted to facilitate FUP transfer instead of ACP400). FUPs (and the accompanying FUP version packages) can be delivered via the cloud 130 to system components such as equipment components 140, and then delivered to the SCM 120 in a similar manner to ACP containers 410.

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

[0481] The FUP is similar to the design of the ACP container 410 and other secure firmware image / distribution methods described herein in that the FUP can be transmitted from any system component to a specific SCM 120, stored, and delivered. However, in one embodiment, the system 100 may be configured so that transmission is only possible from one or more specific system components. In another embodiment, the firmware update may be transmitted to the SCM 120 via any type of communication channel.

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

[0483] If the FUP is specific to target SCM120, target SCM120 can be identified within the package. The identity of Cloud 130 can be provided within the FUP and FUP version package.

[0484] In one embodiment, the FUP and FUP version packages may be encrypted and / or signed only by the cloud 130. The FUP and FUP version packages may be visible and / or applicable to many SCM 120s, or they 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 SCM 120s. In one embodiment, the FUP version package may be encrypted and / or signed using the ACP-Package-Version key.

[0485] In one embodiment, the FUP and FUP version package may not be encrypted. In another embodiment, the FUP may be further signed and / or encrypted with a manufacturer-provided encryption key (e.g., Firmware-Key) which 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 package, which makes the FUP version package 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) within a secure memory 220, or within a secure element such as a secure enclave or hardware security module (HSM), or an equivalent hardware module.

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

[0488] The SCM120 and its subcomponents can continue to operate normally while receiving a firmware update image. The SCM120 and its subcomponents can apply the update immediately and / or when not in use and / or at a predetermined time, such as a specific time of day or day of the week. In one embodiment, the SCM120 and its subcomponents can enter an update mode that interrupts or disables normal operation while the firmware is being updated.

[0489] The SCM120 can roll back to a previous version of its own firmware and all SCM subcomponents if its currently running firmware is corrupted or not operating within expected or required constraints. For example, if an excessive number of exceptions occur within a unit of time, if the SCM120 cannot operate continuously for a long enough period to perform another firmware update, if the SCM120 cannot establish a connection with another system component (such as device 110, cloud 130, or instrument component 140), or if image hash / CRC verification fails during loading, or any combination thereof, the SCM120 can initiate a rollback procedure. Operating constraints may be hardcoded within the boot selector, boot loader, firmware / application, or other loadable items.

[0490] In one embodiment, the operational constraints may be configurable at runtime. Statistical and / or other information useful for evaluating operational constraints may be stored in a memory area that survives resets and / or power outages. In one embodiment, operational constraints may include runtime behavior or statistical analysis, runtime performance (e.g., timing or throughput) analysis, classification using machine learning, or other dynamic analyzers that determine whether the firmware is functioning correctly, or any combination thereof. In one embodiment, when a firmware rollback occurs, the subcomponents of the SCM120 may be notified and choose whether or not to roll back. In one embodiment, the SCM120 and its subcomponents may not roll back for a variety of reasons, including, for example, one or more of these components are unable to perform the rollback, or one or more of those components do not have enough statistical data to determine whether or not to downgrade.

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

[0492] If a FUP is determined to be applicable, the FUP may be requested by 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 being newer than (or equivalent to, but with a more recent timestamp than) the current firmware, the minimum compatible versions of various settings being compatible with the new firmware, and all other constraints being met. Once the complete firmware image is obtained (and possibly again when written to ROM), the image may be verified by the target. Verification may include performing an integrity hash, signing, analyzing other attributes that may be verified, or any combination thereof.

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

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

[0495] In one embodiment, the distribution of firmware updates to the subcomponents of the SCM120 may be synchronized and / or ordered among the subcomponents. The SCM120 may update all subcomponents before updating itself and verify that each subcomponent has been successfully updated by verifying the version of the loaded items. In one embodiment, the SCM120 may update its own firmware before the firmware of the subcomponents. In one embodiment, the system 100 may be able to configure, based on data in the FUP, whether the SCM120 updates the subcomponents first, or whether the SCM120 is updated first, or whether there are other ordering constraints that must be satisfied.

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

[0497] In one embodiment, delta updating may be used to send the FUP to the SCM120. Compression may be used to send the FUP to the SCM120.

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

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

[0500] After initial manufacturing, or in response to a command to perform a factory reset, the SCM120 can enter factory reset mode. In response to a command to perform a factory reset, the SCM120 may discard its ACP400, other configuration records, and cryptographic keys in order to return to its factory (initial manufacturing) state. Zero or more of the following identifiers and cryptographic keys may not be reset as a result of the 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 recycled by the SCM120 as a result of a factory reset. Changing the SCM-Key key causes the system 100 to present the SCM120 as a new SCM120, and no system component with the old SCM-Key key can encrypt or decrypt messages from the SCM120. Although the SCM120 may appear new, it can still be identified as the same SCM120 as long as its SCM-ID is not changed (or the alternative identifier used to identify the SCM120 remains unchanged).

[0502] In one embodiment, if the SCM-Key is not circulated and an attacker successfully connects to the cloud 130 using a device 110 under the attacker's control and authenticates with the cloud 130, the attacker may be able to gather information to infiltrate a part 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 rejects any messages that must be signed by the cloud 130, including the ACP 400 which authorizes the attacker's device 110 to send and / or receive commands to and from the SCM 120. In this case, the attacker's actions may be clearly identifiable and reversible.

[0503] Changing the SCM-Key during a factory reset allows the cloud 130 to reject any request to become the first owner device 110 of the SCM 120, which 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 key to be delivered to the SCM 120 as part of a response to a new owner registration request.

[0504] In one embodiment, the SCM-ID identifier may be recirculated by the SCM120 as a result of a factory reset. The SCM-ID identifier may be intended to be a persistent identifier. However, by changing the SCM-ID identifier, the system 100 may no longer be able to identify the SCM120 as the same physical part, especially if the SCM-Key is also changed. In one embodiment, the cloud 130 can generate a new SCM-ID identifier to be delivered to the SCM120 as part of a new owner registration request response. In one embodiment, the SCM-ID may be recirculated, and the cloud 130 may maintain a history of the SCM-IDs for its SCM120.

[0505] In one embodiment, the Equipment-Key key may be cleared by the SCM120 as a result of a factory reset. The SCM-Equipment-Key key may be recycled by the SCM120 as a result of a factory reset according to one embodiment. By clearing and / or changing the equipment key, the SCM120 may become unable to communicate with the equipment component 140 coupled to or possibly attached to the SCM120. In one embodiment, the cloud 130 can generate a new SCM-Equipment-Key key to be delivered to the SCM120 as part of a new owner registration request response.

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

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

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

[0509] In one embodiment, the SCM120 may be instructed by the cloud 130 to perform a factory reset, either directly or indirectly, through one or more system components. If the SCM120 is connected to the cloud 130, a direct command to perform a factory reset may be received. An indirect command to perform a factory reset may be received through one or more system components, such as from the cloud 130 to the device 110 to the SCM120, or from the cloud 130 to the equipment component 140 to the SCM120, similar to the ACP400.

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

[0511] When SCM120 is in factory reset mode, there is no owner device 110 for SCM120, but SCM120 can accept a new owner initiation request. A new owner initiation request can establish the first owner device 110 for SCM120, resulting in the generation and transfer of the first ACP400 for SCM120, providing SCM120 with cloud keys (e.g., Cloud-SCM-Key, Cloud-SCM-Approval-Key, and ACP-Version-Key) and authorization, as well as other configuration data. Registration of SCM120 and establishment of a new owner can be carried out according to one or more of the following steps. 1) Device 110 can send a new owner initiation request to SCM 120. 2) SCM120 can send its SCM-Key (public) key and SCM-ID identifier to device 110. 3) Device 110 can generate a new Device-SCM-Key public / private key pair. 4) Device 110 can send a new owner registration request to the cloud 130. As part of the new owner registration request, device 110 can send some or all of the following to the cloud 130: • 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 address, BLE UUID, APNS / GCM token) 5) Cloud 130 can register device 110 and generate one or more of the following: • Generate new Cloud-SCM-Key public / private keys (e.g., Cloud-SCM-Key and Cloud-SCM-Approval-Key). • Generate new ACP-Version-Key public / private keys • Generate new User-SCM-Key public / private keys • Generate owner device authorization • Generate the first ACP400 and distribute it. 6) Cloud 130 can send the Cloud-SCM-Key (public) key to device 110. 7) Cloud 130 can send the ACP container 410 (including the first ACP) to device 110. 8) Device 110 can transfer ACP400 to SCM120. 9) The SCM120 can accept the ACP400 and exit factory reset mode.

[0512] After the SCM120 accepts its initial ACP400 and exits factory reset mode, authorization for additional devices 110 may be added as usual.

[0513] In one embodiment, the SCM-ID does not have to be obtained via an insecure connection, and therefore the SCM-Key may be used to establish a secure connection. Establishing a secure connection may be similar to a device / SCM connection establishment process that begins with an unknown phase, after which 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 device 110 and cloud 130 may be protected by using TLS 1.2 or higher, which includes server-side (cloud) authentication based on certificates and cloud session tokens.

[0515] The application layer and / or application programming interface within system 100 can 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 used 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 received by device 110 from cloud 130 for a particular SCM may be signed with the corresponding Cloud-SCM-Key key of the SCM. XVII. Cloud / Cloud Communication - Mutual Authentication

[0516] In one embodiment, communication channels used within Cloud 130 (inside the cloud) and / or between cloud systems may be protected using TLS 1.2 or higher with certificate-less mutual authentication.

[0517] The application layer and / or application programming interface can 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 used 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. XVIII. Equipment / SCM communication

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

[0519] The application layer and / or application programming interface can 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 SCM120 may be equipment for another SCM120, establishing one or more inter-SCM communication channels for each SCM120. Such a configuration can facilitate one or more of the following: sharing of connections, authorization, and / or authentication activities between SCMs, load balancing (e.g., communication connections or computing resources), redundant / multifactorial verification / authentication of devices or other system components (e.g., other equipment), execution and verification of redundant / lockstep systems (e.g., cross-checking), and expansion of system control capabilities (e.g., more input / output ports or improved communication range). XEX. Time-based distribution

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

[0522] In one embodiment, 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, in contrast to traditional blockchains (where each node can have at most one parent and at most one child). The Blockfan tree structure may be used to manage and verify peer rights granted through parent permissions. For example, device 110 is granted the right to access SCM 120 (parent permission) and, within the context of that right, is granted the right to issue certain commands (peer permission).

[0523] The blockfan chain structure may be used to order permissions over time. In one embodiment, a Merkle tree may be used to verify the hash and / or signature of the blockfan nodes (including sibling nodes of the granting nodes to ensure that token grants have not been used multiple times). Thus, the Merkle tree may be used to verify the integrity, validity, and accuracy of the entire rights management system. A blockfan-based rights management system can define token grants, where one-time use rights are granted for subsequent use. For example, at some point in the future, a particular device 110 may want to acquire ownership of a particular SCM 120. Blockfans can form a ledger. In other words, rights are never deleted, and all rights can be traced back to one or more grant sources. If a right cannot be traced back to a grant source, this is considered a verification failure.

[0524] In the rights management system according to the embodiment illustrated in Figure 15, rights can be defined by dividing them into three components. 1) The right to take action as specified in 1501. 2) The right to grant the right to perform an action as specified in 1502. 3) The right to grant the right to grant the right to perform an action, as specified in 1503. Please note that having the right to grant rights does not necessarily mean that the grantor is able to act on their own. This right may include the right to grant this right to someone else.

[0525] In one embodiment, a grantor cannot assign rights to themselves, nor can a grantor who has been granted the right to grant the right to permit the granting of rights grant that authorization to themselves.

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

[0527] In one embodiment, all grants may include the following information: ·action ·context ·Grantee • A copy of the recipient's public key • It was granted ·start date Expiration date ·Parent-granted ED • Check value

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

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

[0530] This set may be encrypted with the revoker's private key and may include the revoker's ED, the revoked item's ED, the revocation authorization ED, the action, the context, and the revoked status.

[0531] By signing and dated the grant issuance, it becomes possible to trace the grant of all rights back to the beginning of System 100, and to verify the data within System 100 while it is being processed.

[0532] The types of rights listed below may be utilized in accordance with one embodiment of this disclosure. Note that grants may have different models depending on the action. · Dependent. If the grantor's right to grant the right expires, the dependent right may also expire. This type of right can be used primarily for operational rights for SCM120, and all such dependent rights may be revoked when SCM120 is transferred or when the owner of SCM120 is removed. · Independent. An independent right may not require the grantor's right to grant permission to be valid after the time of grant. To ensure that the grantor's right is valid at the time of grant, tracking may still be possible through System 100. This type of right may be useful within an organization for administrative tasks. · Token. In one embodiment, a token grant can only be used once. In one embodiment, a token grant is the only right in System 100 that cannot be used without side effects. Use of a token right may invalidate sibling tokens. A token right may be used for the transfer of SCM120. · Immortal. The right to immortality may be granted for the lifetime of the SCM120 and may transcend ownership of the SCM120. The right to immortality, if granted, may only be granted to the OEM and may represent a right included in all configurations created for the SCM120 referenced by the right to immortality.

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

[0534] In one embodiment, system 100 can be considered to be plagued by potential vulnerabilities. If there is no way to communicate, updates may not be delivered. The distributed nature of system 100 can make it more tolerant of connectivity failures than other systems 100. However, system 100 may not provide a substantially absolute solution to this problem, which is likely not available in online systems.

[0535] Authorization and configuration updates can be delivered to SCM120 via other system components (e.g., device 110). If a system component cannot communicate with SCM120, or if it cannot receive updates due to a lack of connectivity, the system component may not deliver the updates to SCM120. The inability to receive updates in a timely manner due to unintended or intentional lack of connectivity is of particular concern with respect to authorization revocation.

[0536] Consider a scenario where user A revokes the authorization of device 110 belonging to user B for the SCM 120, but user B wants to continue accessing the equipment component 140 to which the SCM 120 is attached (i.e., the "Crazy X" scenario). In this scenario, if user B disables the radio on their device 110, device 110 cannot deliver the updated ACP 400 revoking its authorization to the SCM 120, and therefore user B can continue to use the equipment component 140 associated with the SCM 120. The distributed nature of system 100 may help avoid this sequence, as any device 110 with 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, yet user A still has access to the SCM 120 and the attached equipment component 140.

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

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

[0539] If device 110 establishes a secure communication link with SCM 120 (at least during the security phase, for each device / SCM connection establishment process), SCM 120 may send a blacklist package to device 110. SCM 120 may also send a blacklist package to device 110 at some point after device 110 has connected, or when SCM 120's blacklist has been modified, after processing the updated ACP 400.

[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 SCM120, may be signed and encrypted with an SCM-Key (private) key, and then signed and encrypted with a Cloud-SCM-Key (public) key. In one embodiment, SCM120 may send the blacklist package to another SCM120 or another system component via 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 equipment component 140 may receive a list of valid authorizations and send the blacklisted authorizations to SCM120.

[0541] When device 110 receives a blacklist package, device 110 may send the blacklist package to cloud 130 without modification (device 110 may not be able to decrypt the blacklist package). Cloud 130 may perform one or more of the following: validate the blacklist package, apply the revocations described in the blacklist package, and notify the owner device 110 of SCM 120 that the updated ACP400 is available for approval. The ACP400 may include Blacklist-Item-IDs that have been processed since cloud 130 last received confirmation that the configuration has been delivered to SCM 120. For example, an ACP blacklist may be incremented until confirmation is received that the contents of the blacklist have been processed, at which point the blacklist may be decremented. If the updated ACP400 is not accepted by owner 10, owner 10 may modify the ACP400 until it meets the approval requirements.

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

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

[0544] Each system component may maintain a system log capable of storing (i.e., logging) 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 runtime) and may change depending on the system state. Such changes may occur automatically and / or manually, for example, when instructed to do so by another system component.

[0545] System components may log events in real time, batch, or via deliverable system log packages 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. System log packages may be delivered to other system components (e.g., device 110, equipment 140, SCM 120, etc.) for transmission to the cloud 130 (e.g., SCM 120 may deliver the SCM 120 system log package to devices for transmission to the cloud). Alternatively, system log packages may be delivered directly to the cloud 130, similar to blacklist packages. System log packages may be delivered via any communication channel in a manner that encrypts them. In one embodiment, real-time and batch logs may be delivered to the cloud 130 only via a secure communication link. In one embodiment, system log packages may be delivered only via a secure communication channel.

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

[0547] One or more embodiments of this disclosure can be implemented in connection with a variety of applications, and it should be understood that this disclosure is not limited to the specific applications described herein. For the purposes of the disclosure, some use cases or applications, including use cases that can be combined with a microlocation system, are identified below. 1) Automobile • Passengers / light truck ·bus ·long haul • Regional delivery • Versatile / Specialized RV Ridesharing ·rental ·dealer • Shared access 2) Heavy machinery (bulldozer) 3) Agricultural machinery (John Deere, Kubota) 4) Motorcycles (and four-wheeled vehicles, three-wheeled vehicles, and snowmobiles) 5) Airplane ·General aviation ·Commercial ·Military 6) Ship • Personal watercraft • Boats (houses) / Yachts ·Commercial ·Cargo ship 7) Door lock ·Residential & Commercial • Hotel / Rental • Secure and controlled access 8) Office equipment and automation • Conference room facilities • Safe button (a separate patent is available) ·automation 9) Office furniture • Space usage Open desk • Space customization • Mobile devices • Adjustable chair Brody Chair ·display 10) Conference events • Entry into the session (by scanning the tag) Where is my seat? / Am I in the correct seat? 11) Theme parks (Disney, Six Flags) 12) Hospital • Access to rooms and facilities Who is in which room? • RTLS (Real-time Location System) - Tracking objects 13) Retail (stores) 14) Industrial equipment / manufacturing automation (large and expensive items) 15) Vending machines 16) Restaurants • Waiter / Manager Which table ordered which food? Order from the table, get yours. 17) Computer monitor / laptop

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

[0549] Directional terms such as “vertical,” “horizontal,” “up,” “down,” “upward,” “downward,” “inward,” “outward,” and “outward” are used to help describe the invention based on the directions of the illustrated embodiments. The use of directional terms should not be construed as limiting the invention to any particular direction.

[0550] The above description is a description of current embodiments of the invention. Various modifications and changes can be made without departing from the spirit and broad aspects of the invention as defined in the appended claims, which should be interpreted in accordance with the principles of patent law, including the doctrine of equivalents. This disclosure is presented for illustrative purposes and should not be construed as a comprehensive description of all embodiments of the invention, nor should the claims be limited to specific elements illustrated or described in relation to these embodiments. For example, any individual element of the described invention may be replaced by alternative elements that provide substantially similar functionality or otherwise appropriate operation. This includes, for example, currently known alternative elements, such as those currently known to those skilled in the art, and alternative elements that may be developed in the future, such as those recognized as alternative elements by those skilled in the art at the time of development. Furthermore, the disclosed embodiments include several features that are described together and work together to provide a set of benefits. The invention is not limited to embodiments that include all of these features or that provide all of the benefits described, unless expressly stated in the published claims. For example, referring to a claim element in the singular form using the articles “a,” “an,” “the,” or “said” should not be construed as limiting that element to the singular. A reference to a claim element as "at least one of X, Y, and Z" means that it includes, individually, any one of X, Y, or Z, and any combination of X, Y, and Z, e.g., X, Y, Z; X, Y; X, Z: Y, Z.

Claims

1. A vehicle control unit that communicates with vehicle equipment components, A communication interface capable of operating to communicate wirelessly with a remote device, A device interface capable of communicating with the aforementioned vehicle equipment components, The system comprises a controller configured to establish a communication link with the remote device via the aforementioned communication interface. The controller is configured to receive authorization setting information from the remote device via the communication link. The remote device is configured to receive the authorization configuration information from the server. The controller is configured to receive multiple sets of authorization configuration information from multiple remote devices. Each of the multiple authorization setting pieces defines information for authenticating the corresponding remote device and access attributes for the vehicle equipment components of the remote device. The controller is a vehicle control unit that determines the location information of the remote device relative to the vehicle, and, based on the authorization setting information and the location information, determines whether the vehicle equipment component should unlock the vehicle using the remote device.

2. The vehicle control unit according to claim 1, wherein the authorization setting information includes encrypted data, and the controller can decrypt the encrypted data.

3. The vehicle control unit according to claim 1 or 2, wherein the vehicle control unit receives commands relating to vehicle operation from the remote device.

4. The vehicle control unit according to claim 3, wherein the vehicle control unit approves an action based on a command received from the remote device, based on authorization from the remote device.

5. The vehicle control unit according to claim 4, wherein the authorization of the remote device relates to an access attribute which is a restriction on the authority of the remote device.

6. A method for obtaining authorization setting information for a remote device in a vehicle control unit that communicates with vehicle equipment components, The remote device receives the authorization setting information from the server. The vehicle control unit communicates wirelessly with the remote device. The vehicle control unit establishes a communication link with the remote device via wireless communication, and The vehicle control unit includes receiving the authorization setting information from the remote device via the communication link. The vehicle control unit is configured to receive multiple sets of authorization setting information from multiple remote devices. Each of the multiple authorization setting pieces defines information for authenticating the corresponding remote device and access attributes for the vehicle equipment components of the remote device. A method comprising: the vehicle control unit performing location information of the remote device relative to the vehicle; and, based on the authorization setting information and the location information, determining whether the vehicle equipment component should unlock the vehicle using the remote device.

Images