Using blockchain and DICE-RIOT to remotely manage devices

Abstract

Techniques for remotely managing computing devices using blockchain and DICE-RIoT are disclosed. In one embodiment, a method is disclosed, comprising: scanning a network to obtain a list of devices on the network; classifying the devices as controlled, uncontrolled, or restricted devices; establishing a secure channel with the controlled devices; issuing one or more control commands to the controlled devices through the secure channel, the one or more control commands being contained in a signed message, the signed message being signed using a sender's private key and verified using a recipient's public key, the private key and public key being generated during the establishment of the secure channel; receiving a response to the control command; and recording the control command and the response in a blockchain.

Description

[0001] Related Applications

[0002] This application claims priority to U.S. Patent Application No. 16 / 363,295, filed on March 25, 2019, and entitled “REMOTELY MANAGING DEVICES USING BLOCKCHAIN ​​AND DICE-RIOT,” the entire disclosure of which is hereby incorporated by reference herein.

[0003] Copyright Notice

[0004] This application contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent disclosure as it appears in the Patent and Trademark Office files or records, but otherwise reserves all copyright rights whatsoever. Background Art

[0005] The disclosed embodiments relate to computer security and, in particular, to devices, computer-readable media, and methods for remotely managing computing devices using blockchain and DICE-RIoT.

[0006] There are different environments where it is important for an agency to be able to regulate the functionality of some networked devices (e.g., instruments, phones, laptops, etc.) for safety reasons. For example, in a hospital, the functionality of devices in intensive care units and operating rooms, as well as the functionality of specific devices such as laboratory equipment, hyperbaric chambers, etc., must be strictly regulated. As another example, during an emergency, an agency may need to restrict the use of a device to obtain bandwidth for emergency rescue.

[0007] To improve safety in hazardous environments, it is important to have direct control over networked electronic devices present in some areas. However, requiring individuals (and therefore individual devices) to perform this control presents significant safety issues. Two techniques are currently used to allegedly compensate for the need for individual control of other devices.

[0008] In one scenario, user devices are coercively controlled. That is, users are forced to obey a central authority (e.g., turn off their cell phones, etc.) under threat of negative behavior. For example, during air travel, users are required by law to turn off their cell phones and other wireless devices or they will be removed from the aircraft or subject to civil penalties.

[0009] In the second scenario, the user voluntarily grants management of the device to a remote entity. For example, the user may accept that the user's employer can access their device and install / remove applications, control settings, etc. via provisioning a configuration file. In some embodiments, these scenarios may be limited to the geographic area in which control can be applied or the type of control applied.

[0010] These systems have numerous drawbacks. In the first scenario, the user may simply not comply, thus defeating the purpose of the control. In practice, since the scenario is not technically implemented, compliance cannot be confirmed without manually checking each device. In the second system, the user must typically have a relationship with the controlling entity (e.g., employer-employee) and must explicitly consent to be controlled. Therefore, in a public scenario, this solution is technically impossible. Furthermore, the user may utilize different devices that are not controlled, thereby defeating the purpose.

[0011] Therefore, the art needs a way to remotely manage electronic devices without relying on user intervention. In addition, in order to implement this technical solution, it is necessary to ensure that the control device can be reliably identified as a device with appropriate permissions. Summary of the invention

[0012] Disclosed herein are methods, computer-readable media, and devices for remotely managing computing devices using blockchain and DICE-RIoT.

[0013] In one embodiment, a method is disclosed, comprising: scanning a network to obtain a list of devices on the network; classifying the devices as controlled, uncontrolled, or restricted devices; establishing a secure channel with the controlled devices; issuing one or more control commands to the controlled devices through the secure channel, the one or more control commands being included in a signed message, the signed message being signed using a sender's private key and verified using a receiver's public key, the private key and public key being generated during the establishment of the secure channel; receiving a response to the control command; and recording the control command and the response in a blockchain.

[0014] In another embodiment, a non-transitory computer-readable storage medium for tangibly storing computer program instructions executable by a computer processor is disclosed, the computer program instructions defining the following steps: scanning a network to obtain a list of devices on the network; classifying the devices as controlled, uncontrolled, or restricted devices; establishing a secure channel with the controlled devices; issuing one or more control commands to the controlled devices through the secure channel, the one or more control commands being included in a signed message, the signed message being signed using a sender's private key and verified using a recipient's public key, the private key and public key being generated during the establishment of the secure channel; receiving a response to the control command; and recording the control command and the response in a blockchain.

[0015] In another embodiment, a device is disclosed, comprising: a processor; and a storage medium for tangibly storing program logic thereon for execution by the processor, the stored program logic comprising: logic executed by the processor to scan a network to obtain a list of devices on the network; logic executed by the processor to classify the devices as controlled, uncontrolled, or restricted devices; logic executed by the processor to establish a secure channel with the controlled devices; logic executed by the processor to issue one or more control commands to the controlled devices through the secure channel, the one or more control commands being included in a signed message, the signed message being signed using a sender's private key and verified using a recipient's public key, the private key and public key being generated during the establishment of the secure channel; logic executed by the processor to receive a response to the control command; and logic executed by the processor to record the control command and the response in a blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The foregoing and other objects, features and advantages of the present disclosure will be apparent from the following description of the embodiments as illustrated in the accompanying drawings, wherein reference characters refer to the same parts throughout the various views. The drawings are not necessarily drawn to scale, emphasis instead being placed upon illustrating the principles of the present disclosure.

[0017] Figure 1 is a block diagram of a system for managing a remote device according to one embodiment of the present disclosure.

[0018] Figure 2A is a flow chart illustrating a method for controlling a remote device in an enclosed area according to some embodiments of the present disclosure.

[0019] Figure 2B is a flow chart illustrating a method for controlling a remote device in an open area according to some embodiments of the present disclosure.

[0020] Figure 3is a flow chart illustrating a method for responding to a remote control request according to some embodiments of the present disclosure.

[0021] Figure 4 is a block diagram illustrating a DICE-RIoT communication system according to some embodiments of the present disclosure.

[0022] Figure 5 is a diagram of a blockchain data structure and corresponding blocks of the structure according to some embodiments of the present disclosure.

[0023] Figure 6 is a block diagram of a computing device according to some embodiments of the present disclosure. DETAILED DESCRIPTION

[0024] Figure 1 is a block diagram of a system for managing a remote device according to one embodiment of the present disclosure.

[0025] In the illustrated embodiment, the network (118) connects the scanner (102), the devices (108a-108n), the certificate authority (120), the unrestricted device (116), and the uncontrolled device (114). In one embodiment, the network (118) may include a plurality of different networks, such as a Wi-Fi network, a cellular network, a personal area network (e.g., Bluetooth), a near field communication (NFC) network, and any other network.

[0026] In one embodiment, the scanner (102) comprises a device designed to control one or more devices. As an example, the scanner (102) comprises a hardware module or a standalone device placed in an enclosed area where control is desired. For example, the scanner (102) may comprise a device attached to an x-ray machine at an airport, a hospital laboratory, an airplane cabin, or other area where control of electronic devices exists.

[0027] The scanner (102) includes a DICE / RIoT subsystem (104) and a blockchain module (106). In one embodiment, the DICE / RIoT subsystem (104) includes L0 and L1 DICE / RIoT subsystems that generate layer 1 public keys, device identifiers, and certificates as will be described herein. The DICE / RIoT subsystem (104) may include a combination of firmware (ROM) code and upper layer software. The operation of the DICE / RIoT subsystem (104) is combined with Figure 4 is more fully described herein, which is incorporated herein by reference in its entirety.

[0028] The scanner (102) further includes a blockchain module (106). In one embodiment, the blockchain module (106) is responsible for the actual storage of the blockchain data (e.g. Figure 5) and performs all blockchain operations (e.g., block verification, consensus, etc.). As will be described, the blockchain module (106) provides a tamper-proof record of instructions sent to devices (108a-108n) and the manner in which those devices reacted to the instructions.

[0029] Devices (108a-108n) are referred to as controlled devices because they can be controlled by the scanner (102). In one embodiment, a device is controllable if it contains a DICE / RIoT subsystem (112). Figure 4 As will be described in the , the presence of the DICE / RIoT subsystem allows the controlled devices to verify the identity of the scanner and also generate their own verifiable identities that can be used to mutually confirm that each device (scanner and controlled device) is what they say they are. As illustrated, each controlled device includes a variety of standard network interfaces (110a-110c). These interfaces operate as standard interfaces and enable the controlled devices (108a-108n) to communicate with the scanner (102) via various networks.

[0030] In addition to controlled devices, the figure also illustrates unrestricted devices (116) and uncontrolled devices (114). In the illustrated embodiment, an unrestricted device may (or may not) have a DICE / RIoT subsystem, but is otherwise exempt from control. In one embodiment, an unrestricted device has a triplet recorded as a known unrestricted device and therefore the scanner (102) ignores this device when attempting to control devices within its coverage area. One example of an unrestricted device includes telecommunication equipment (e.g., routers, etc.) that may be present in the area covered by the scanner.

[0031] In contrast to unrestricted devices (116), uncontrolled devices (114) are devices that do not include a DICE / RIoT subsystem. Due to the lack of this subsystem, uncontrolled devices (114) cannot verify the identity of the scanner (102) and therefore will not respond to commands to control the device (for security purposes). For these devices, the system can fall back to existing methods of controlling the device (discussed previously). It should be noted that while DICE / RIoT is primarily discussed in the specification, other authentication schemes may also be used, provided that they meet the requirements described herein.

[0032] Finally, the system describes a certificate authority (120). This certificate authority (120) comprises a trusted entity that can sign certificates generated by the scanner (102) or controlled devices (108a-108n). In some embodiments, the certificate authority (120) may not exist and the devices may sign their own certificates.

[0033] Figure 2Ais a flow chart illustrating a method for controlling a remote device in an enclosed area according to some embodiments of the present disclosure. In the illustrated embodiment, Figure 2A The method can be performed by the aforementioned scanner.

[0034] In step 202, the method scans the network.

[0035] In one embodiment, the network includes a Bluetooth network, i.e., a list of nearby networks that can be connected to via Bluetooth. Alternatively, the method may transmit a broadcast request over a Wi-Fi network or other network to identify devices on the network. Thus, in step 202, the method obtains a list of devices and network addresses (e.g., IP addresses, MAC addresses, Bluetooth addresses, etc.).

[0036] In step 204 , the method categorizes the devices identified in step 202 .

[0037] In one embodiment, when a device is detected, it may report various properties of the device. For example, in a Bluetooth scenario, the scanner may establish an unsecured socket with the device for control after detecting its Bluetooth address. If the device includes a DICE / RIoT system, it may be configured to broadcast that capability over an unsecured channel. For devices that do not include a DICE / RIoT system, the method does not receive this indication and classifies the device as an unsupported device.

[0038] In step 206, for each device, the method determines whether the device is supported or unsupported.

[0039] If the device is not supported, the method proceeds to fall back to an existing method of controlling the device. For example, the method may transmit a notification to the device to turn itself off (step 208) or perform some other action. This message may in turn be displayed on the device to notify the user of the desired action. Of course, the user may choose to ignore this notification.

[0040] In some embodiments, in addition to notifying the user to turn off the device (step 210), the method may also interrupt the communication. In one embodiment, the interruption of the communication may be optional and only employed in specific scenarios.

[0041] In step 212, the method then records the notification sent to the uncontrolled device in a blockchain block. In one embodiment, the method records all messages sent to the device, regardless of whether the device can or does respond to the message. In this way, the method maintains a record of messages sent during operation of the scanner in a secure, tamper-proof data structure.

[0042] In contrast to the above, if the method determines that the device is classified as a remote control capable device (e.g., a device with a DICE-RIoT subsystem), the method proceeds to authenticate the device and establish a secure channel (step 214). In one embodiment, this includes the method transmitting identification information to the device and the device confirming the identity of the scanner. In one embodiment, the identification information includes a triplet including a device identifier, a public key, and a certificate generated via the L1 DICE-RIoT key generation process (described herein). As used herein, layers 0 and 1 are used for authentication, while layers 2 and above (in both devices) are used for messaging. In one embodiment, the secure channel includes a TLS connection formed after exchanging keys.

[0043] In step 216, after authentication, the method issues a communication control command.

[0044] In one embodiment, the method generates control commands that will cause the device to perform an action (e.g., shut down). In one embodiment, these commands are recorded for various device types. In alternative embodiments, these commands may be transmitted to the method by the receiving device. In any case, the method selects the necessary commands based on the configuration parameters of the device implementing the method.

[0045] In one embodiment, the method packages the control instruction into a message and signs the message using its L1 private key. The method then transmits this instruction to the device, where the device can verify the signature using its L2 public key. In one embodiment, the message additionally includes a freshness value to avoid replay attacks, such as a monotonic counter, a timestamp, etc.

[0046] After receiving the command, the device executes Figure 3 After executing the command (or if the command affects its ability to send messages), the device returns a response to the method (step 218).

[0047] In one embodiment, the response may include various data about the execution of the instruction. For example, it may include an explicit confirmation that the instruction was executed, a timestamp that the instruction was to be executed, a stack trace when executed, and any other data related to the instruction. Similar to the instruction, the response may be signed using a device L1 key and verified using a method L2 key (e.g., a scanner L2 key).

[0048] In step 220, the method determines whether the response is authentic. In one embodiment, this includes verifying the signature of the response by using the method's L2 key. In addition, the method can confirm that the sender's certificate and public identifier are valid.

[0049] If the response is not authenticated, then the method falls back to the existing method (as described in conjunction with steps 208-212).

[0050] If the response is authenticated, the method records the response to the blockchain (step 222). Similar to step 212, the scanner records the instruction and the response to the blockchain to record the interaction between the devices. In one embodiment, the method may record the instruction before receiving the response. Alternatively, the method may record both records simultaneously.

[0051] Figure 2B is a flow chart illustrating a method for controlling a remote device in an open area according to some embodiments of the present disclosure.

[0052] In step 224, the method receives a broadcast request.

[0053] and Figure 2A Compared with the operation in Figure 2B The method described in the can be applied to a large geographic area (e.g., several acres, a city, etc.). In this embodiment, the broadcast request can be issued by an agency (e.g., the police). The broadcast request can declare all devices in the defined area to perform one or more actions contained in the request (e.g., turn off, limit bandwidth).

[0054] Since the request may be sent by any device, and the system does not assume the security of the channel, the method checks to see if the device transmitting the request is authenticated (step 226). The method may employ a DICE-RIoT credential check to confirm the identity of the sender (e.g., by double decrypting a triplet associated with the sender to confirm their identity).

[0055] If the check (226) fails, the method denies the request (step 228) and logs the request (230) to the blockchain storage device. In the illustrated embodiment, the method denies the request by simply ignoring the request. The method also logs the request for law enforcement or other purposes. In some embodiments, the log includes the identity of the sender (e.g., IP address, etc.) to identify potential malicious users.

[0056] Alternatively, if the method authenticates the sender, the method broadcasts the request to a service area (step 232). This service area may be defined in the broadcast request or may be associated with the device implementing the method itself. In one embodiment, the method repackages the request and signs the request using its own private key to ensure the security of the message.

[0057] In step 234, the method performs separate actions based on the type of recipient. In one embodiment, the method receives an ignore message from an emergency vehicle or personnel (step 240). For example, if the control instruction is to turn off all cell phones (or limit bandwidth) during an emergency, then this control instruction can be ignored by emergency personnel and equipment.

[0058] Alternatively, for any other devices, the method transmits control instructions to those devices and receives confirmation responses (step 238). These two steps are Figure 2A , and specifically in steps 216, 218, 220, 208, 210, 212, and 222, the disclosure of which is incorporated herein by reference in its entirety.

[0059] In one embodiment, step 234 may include identifying a Figure 2A 202 and 204 of the present invention. However, it should be noted that the scanned networks may include cellular network areas (e.g., one or more areas served by a given cellular tower) due to the larger service area. In this example, scanning the networks includes identifying a list of IP addresses in a given area (e.g., by querying cellular base station equipment).

[0060] Figure 3 1 is a flow chart illustrating a method for responding to a remote control request according to some embodiments of the present disclosure. In the illustrated embodiment, the method may be performed by a controlled device. Many features of the controlled device have been described from the context of the controlling device and those details are not repeated herein, but are incorporated by reference.

[0061] In step 302, the method receives a request. As described above, this request includes a request from a remote device (e.g., Figure 1 control instructions for the scanner in the computer.

[0062] In step 304, the method authenticates the request. As described above, this may include verifying the digital signature using the L2 public key.

[0063] In step 310, if the signature verification fails, the method denies the request and optionally transmits a notification to the sender that the device will not accept the request.

[0064] In step 306, if the signature verification passes, the method accepts the request. In this step, the device may perform one or more actions contained in the request, such as shutting down the device, limiting bandwidth, enabling full bandwidth (if the device is a router or other telecommunications equipment), etc.

[0065] In step 308, the method generates, signs, and transmits a response.

[0066] In one embodiment, the response includes service information of the request, such as when the request will be fulfilled, what specific action will be taken, etc. The method signs the request using its private key and transmits the response to the sender for recording in the blockchain, as described above.

[0067] Figure 4 is a block diagram illustrating a DICE-RIoT communication system according to some embodiments of the present disclosure.

[0068] As illustrated, the scanner (502a) and the target (502b) communicate via a bidirectional communication path (512). All communications on the path (512) are ensured via UDS servers (504, 408) installed in the scanner (502a) and the target (502b), respectively. In one embodiment, the UDS servers (504, 408) include the same or similar hardware devices installed in the scanner (502a) and the target (502b). Therefore, unless otherwise distinguished, the description of one UDS server is equally applicable to the other UDS server.

[0069] Each UDS server has a "device secret" (e.g., 404a). In the illustrated embodiment, the device secret is known only to the manufacturer of the device and the processing core of the server (e.g., LO ROM 404b), and is used in the creation of a composite device identifier ("CDI") by the processing core. In one embodiment, a CDI is a set of data used to identify the software running on the system used to generate the data.

[0070] In one embodiment, the CDI is created using a one-way hash function (denoted as H). First, the UDS server calculates a hash (or other unique measure of the L1 code (504c)). In some embodiments, the UDS server may further utilize the device's hardware state and configuration data when calculating the hash. This hash is appended to the retrieved device secret (e.g., 404a) and input into the one-way hash function to generate the CDI. Access to the device secret (e.g., 404a) is then removed and the contents of the device secret are completely removed from volatile memory. Control of the device is then transferred to the L1 code (504c) (step 420e). In some embodiments, a hash message authentication code (HMAC) function may be used instead of a one-way hash function. In this embodiment, the device secret may be used as a key and the hash of the L1 code used as the message.

[0071] The L1 code (504c) receives the CDI and uses the CDI to generate security keys and certificates to identify the device. Since the CDI is generated using the UDS and a hash of the code that generates such keys, it ensures the authenticity of the generated keys / certificates. After generating the CDI, the L1 code (504c) permanently deletes the CDI from memory, thereby preventing CDI leakage. In one embodiment, the L1 code (504c) is never modified and therefore the CDI remains the same throughout the life of the device providing the L1 code (504c).

[0072] The UDS server generates a secure key pair in the DICE-RIoT architecture for use by other layers (e.g., layer L2 406a). The UDS server uses the CDI received from the L0 code to generate an asymmetric DeviceID key pair (discussed above). In one embodiment, the method uses a deterministic asymmetric key generation algorithm to generate public and private keys, and the choice of a specific algorithm is not intended to be limiting. The UDS server exports the public portion of the key pair to the next code layer (e.g., L2 layer). The UDS server creates a certificate structure containing the public key. The certificate may include an X.509 format certificate. The UDS server may additionally use the CID and a hash of the next software layer to generate one or more alias keys. For example, the UDS server may use the CID and a hash of the L2 software (506a) to generate an alias key. In one embodiment, the UDS server may query the target device (502b) to request a hash of the L2 code. In other embodiments, the UDS server stores a hash of the L2 code installed during manufacturing or updated out-of-band by a remote service. In one embodiment, the L2 code is associated with specific hardware installed in the target (502b) or scanner (502a) and is therefore relatively static and unchanging during the life of the device. For example, a single entity may manufacture a chip associated with the L1 and L2 software, so the hash of this code may be well known to the system.

[0073] L2 software can load additional modules, provided they are authorized by the firmware security descriptor. Finally, L2 software (or code loaded by L2 software) can use the keys and certificates provided by L1 to authenticate itself using transport layer security (TLS). In one embodiment, L2 software ensures that it only uses alias keys issued to it. That is, L2 software should not use alias credentials issued to an earlier firmware version.

[0074] The foregoing process can be repeated throughout the target (502b). That is, the L2 software (506a) generates a new alias key for the next layer, along with an alias certificate that encodes the hash of the previous layer. For example, the L2 software (506a) uses the hash of the OS (506b) to generate the alias key of the OS (506b), the OS (506b) uses the hash of the application (506c) to generate the alias key of the application (506c), and so on. The alias certificate issued to the next layer is signed with the alias key (rather than the DeviceID key) granted to the bottom layer. In other words, the additional layer acts as an additional subordinate certificate authority. This scheme can be extended all the way to the application layer, where each application obtains a unique alias key and a certificate that encodes its identity. In these cases, the relying party can traverse the alias certificate chain to establish the identity of the top layer and all lower layers of the trusted computing base including the top layer.

[0075] It should be noted that, in contrast to conventional use of DICE-RIoT, the described system distributes the protocol layers among two or more devices. That is, instead of the L2 software (506a) being resident on the scanner, it is resident on the target device and is associated with separate hardware. In the described embodiment, the scanner and target device may only be in close proximity to each other (i.e., within 100 meters or within 100 meters). The two devices may employ a personal area network (PAN), a near field communication network, or other high-speed ad hoc network to exchange hashes of the layer used to generate the alias key in the manner described above. After the keys and certificates are assigned, these keys and certificates may be used to sign and, in some embodiments, encrypt all future communications between the two devices, thereby ensuring protection against man-in-the-middle attacks that would use counterfeit keys to take control of the target device.

[0076] When sending a message, the scanner will typically transmit a message containing a digital signature generated using the scanner's private key. Upon receiving this message, the L2 software (506a) can use the scanner certificate received during the process described above to verify the identification. In some embodiments, the message will also be protected from replay attacks. In this embodiment, the L2 software (506a) provides a random string (e.g., a random message) to the L1 code. When signing a message, the L1 code will sign the message using both its private key and the random message. When verifying, the L2 software (506a) will know the random message and can verify that the sender is indeed authorized.

[0077] Figure 5 is a diagram of a blockchain data structure and corresponding blocks of the structure according to some embodiments of the present disclosure.

[0078] exist Figure 5In the blockchain illustrated in , a plurality of blocks (501-505) and a genesis block (500) are illustrated. As is known in the art, a blockchain represents an immutable and cryptographically verified record of transactions or data state changes. In a real-time application, whenever a request (and its response) is executed and an operation is performed, the request and response are recorded to the blockchain. In one embodiment, only the scanner device (or other control device) accesses the blockchain. In this way, all requests / responses are verified and recorded for future retrieval when needed. In addition, the inherent verification of the blockchain ensures that a rogue entity cannot maliciously attempt to issue control commands (or mistakenly pretend to respond to them). This is ensured by using the DICE-RIoT key as the blockchain address, as the DICE-RIoT key cannot be destroyed or tampered with.

[0079] Figure 5 The contents of a block (502) in a chain generated by a controlling device, such as a scanner, are further illustrated. As illustrated, the block includes a master ledger block header (502a) that includes a hash of the current block and a hash of the previous block. The block additionally includes a triplet that includes a scanner ID (502b), a scanner certificate (502c), and the public key of the scanner (502d) described above. The destination (502e) of the requesting ("target") device is also recorded. Finally, a freshness field (502f) is included that may include a timestamp, a monotonic value, or other value.

[0080] The block further includes command details (502g), which may be optionally encrypted. These details include specific control instructions issued by the scanner to the target device.

[0081] Finally, each block is signed by the sender (e.g., the scanner of block 502) and the signature is packaged and included in the block as a packaged digital signature (502h). In the illustrated embodiment, the signature (502h) is signed using the sender private key and verified by the recipient using the recipient public key.

[0082] As illustrated, the chain includes a response such as a response block (503). This response block (503) is generated by the scanner, but utilizes data returned by the controlled device in response to the request. Block (503) is similar to block (502) and many details of block (502) are incorporated by reference into the description of block (503). As with block (502), block (503) includes a header (503a), a freshness value (503f), a triplet (503b-503d), and a destination identifier (503e). It should be noted that the triplet and destination identifier refer to the target device and scanner, respectively, which is contrary to block (502). In addition, block (503) includes service information (503g), which includes details of how the target device responds to the command.

[0083] In the illustrated embodiment, the method records data to the blockchain data structure in multiple steps. In each step, recording the data includes adding a block to the blockchain data structure as described above. In the illustrated embodiment, a block is identified as part of a split (i.e., included in the ledger) if two conditions are met. First, during insertion, the hash of the previous block must match the hash of the previous block as previously calculated. That is, reference Figure 5 , before inserting block 503, the "hash (previous local block)" of header 503a must match the "hash (current local block)" of previous block 502a. In addition to this requirement, blocks must also meet the second, non-standard condition that the block is generated by an authorized host of the system. This special requirement is actually an alternative to proof of work in traditional blockchain systems (i.e., a mathematical competition among nodes). Specifically, in the described blockchain, nodes participating in the system attempt to guess the correct signature for inserting blocks into the blockchain. However, in the system, one entity in the system possesses the private key used to generate the signature and can therefore quickly "win" the competition (while the assertion can be verified by any other node using the public key of the private key owner). In this way, only the true signer can win the competition, thereby preventing blocks from entering the blockchain without authorization.

[0084] Figure 6 is a block diagram of a computing device according to some embodiments of the present disclosure.

[0085] The processing device may include Figure 6 More or fewer components than those shown in the examples may be used. For example, the foregoing examples may not require an audio interface, display, keypad, illuminator, or camera / sensor. However, the components shown are sufficient to disclose an illustrative embodiment for implementing the present disclosure. In addition, in some embodiments, Figure 6The device described in the embodiment may be implemented as a virtual machine, while in other embodiments, the device may be implemented as a physical machine. In some embodiments, the device is implemented as both, wherein the virtual machine is Figure 6 The device is shown in Figure 1.

[0086] like Figure 6 , the device (600) includes a processing unit (CPU) (602) that communicates with a mass storage (604) via a bus (614). The device (600) also includes one or more network interfaces (616), an audio interface (618), a display (620), a keypad (622), an illuminator (624), an input / output interface (626), and camera(s) or other optical, thermal, or electromagnetic sensor (628). The device (600) may include one camera / sensor (628) or multiple cameras / sensors (628), as understood by those skilled in the art.

[0087] The device (600) may optionally communicate with a base station (not shown), or directly with another computing device. The network interface (616) includes circuitry for coupling the device (600) to one or more networks and is constructed for use with one or more communication protocols and techniques. The network interface (616) is sometimes referred to as a transceiver, transceiver device, or network interface card (NIC).

[0088] The audio interface (618) is arranged to generate and receive audio signals, such as the sound of a human voice. For example, the audio interface (618) may be coupled to a speaker and microphone (not shown) to enable remote communication with other devices and to generate an audio confirmation of an action. The display (620) may be a liquid crystal display (LCD), a gas plasma, a light emitting diode (LED), or any other type of display used with a computing device. The display (620) may also include a touch-sensitive screen arranged to receive input from an object such as a stylus or a finger from a human hand.

[0089] The keypad (622) may include any input device arranged to receive input from a user. For example, the keypad (622) may include a button number dial or a keyboard. The keypad (622) may also include command buttons associated with selecting and sending images. The illuminator (624) may provide a status indication and provide light. The illuminator (624) may remain active for a specific period of time or in response to an event. For example, when the illuminator (624) is active, it may provide backlighting for buttons on the keypad (622) and remain on when the device (600) is powered. Moreover, when an action is performed, the illuminator (624) may provide backlighting for these buttons in various modes, such as dialing another processing device. The illuminator (624) may also cause a light source positioned within a transparent or translucent housing of the device (600) to illuminate in response to an action.

[0090] The device (600) also includes a Figure 6 The input / output interface (626) is used to communicate with external devices not shown in the figure. The input / output interface (626) can use one or more communication technologies, such as USB, infrared, Bluetooth™, etc.

[0091] The mass storage (604) includes RAM (606), ROM (610), and other storage components. The mass storage (604) illustrates another example of a computer storage medium for storing information such as computer readable instructions, data structures, program modules, or other data. The mass storage (604) stores a basic input / output system ("BIOS") (612) for controlling the low-level operation of the processing device (600). The mass storage may also store an operating system for controlling the operation of the processing device (600). It will be appreciated that this component may include a general-purpose operating system such as UNIX or LINUX TM or a dedicated client communication operating system, such as Windows Client TM or Operating system. The operating system may include or interface with a Java virtual machine module that enables control of hardware components and operating system operations via Java applications. The memory (604) includes one or more software applications for implementing some or all of the methods described above (except for the ROM-based cryptography DICE-RIoT operations explicitly described above, which are executed in ROM (61)).

[0092] However, the subject matter disclosed above may be embodied in a variety of different forms and thus, the covered or claimed subject matter is intended to be construed as not limited to any example embodiments set forth herein; the example embodiments are provided merely illustrative. Likewise, a reasonably broad scope for the claimed or covered subject matter is contemplated. For example, the subject matter may be embodied as a method, apparatus, assembly, or system, among other things. Thus, embodiments may, for example, take the form of hardware, software, firmware, or any combination thereof (other than software itself). Thus, the following detailed description is not intended to be limiting.

[0093] Throughout the specification and claims, terms may have nuanced meanings that are suggested or implied by the context beyond the explicitly stated meaning. Likewise, the phrase "in one embodiment" as used herein does not necessarily refer to the same embodiment and the phrase "in another embodiment" as used herein does not necessarily refer to a different embodiment. For example, claimed subject matter is intended to include, in whole or in part, a combination of example embodiments.

[0094] In general, terms may be understood at least in part based on contextual usage. For example, terms such as "and", "or" or "and / or" as used herein may include multiple meanings that may depend at least in part on the context in which such terms are used. Typically, "or" (if used in an associative list, such as A, B, or C) is intended to represent A, B, and C (used herein in an inclusive sense) as well as A, B, or C (used herein in an exclusive sense). In addition, the term "one or more" as used herein may depend at least in part on the context and may be used to describe any feature, structure, or characteristic in a singular sense, or may be used to describe a combination of features, structures, or characteristics in a plural sense. Similarly, terms such as "one", "an", or "the" may again be understood to convey singular usage or to convey plural usage, depending at least in part on the context. In addition, the term "based on" may be understood to not necessarily be intended to convey a set of exclusive factors and may instead again, at least in part, depend on the context to allow for the presence of additional factors that may not be explicitly described.

[0095] The present disclosure is described with reference to the block diagram and the operating instructions of the method and device.It should be understood that each frame in the block diagram or the operating instructions and the combination of the frames in the block diagram or the operating instructions can be implemented by means of analog or digital hardware and computer program instructions.These computer program instructions can be provided to the processor of a general-purpose computer to change its function, special-purpose computer, ASIC or other programmable data processing equipment as described in detail herein, so that the instruction execution block diagram or the operating frame or the function / action specified in several operating frames via the processor of the computer or other programmable data processing equipment is implemented.In some alternative embodiments, the function / action indicated in the frame may not occur in the order indicated in the operating instructions.For example, depending on the function / action involved, two frames of continuous display can actually be performed substantially simultaneously, or the frames can sometimes be performed in reverse order.

[0096] These computer program instructions may be provided to the processors of: a general-purpose computer to change its functionality for special purposes; a special-purpose computer; an ASIC; or other programmable digital data processing devices, so that the instructions executed by the processors of the computer or other programmable data processing devices implement the functions / actions specified in the block diagram or operation block or several operation blocks, thereby transforming their functions according to the embodiments herein.

[0097] For the purposes of this disclosure, a computer-readable medium (or computer-readable storage medium / several computer-readable storage media) stores computer data, which may include computer program code (or computer-executable instructions) in a machine-readable form that can be executed by a computer. As an example and not limitation, a computer-readable medium may include a computer-readable storage medium for tangible or fixed storage of data, or a communication medium for transient interpretation of code-containing signals. As used herein, a computer-readable storage medium refers to a physical or tangible storage device (as opposed to a signal) and includes, but is not limited to, volatile and non-volatile, removable and non-removable media implemented in any method or technology for tangible storage of information such as computer-readable instructions, data structures, program modules, or other data. Computer-readable storage media include, but are not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid-state memory technology, CD-ROM, DVD or other optical storage devices, cassettes, magnetic tape, disk storage devices or other magnetic storage devices, or any other physical or material media that can be used to tangibly store desired information, data or instructions and can be accessed by a computer or processor.

[0098] For purposes of this disclosure, a module is a software, hardware or firmware (or combination thereof) system, process or function or component thereof (with or without human interaction or augmentation) that performs or facilitates the processes, features and / or functions described herein. A module may include submodules. The software components of a module may be stored on a computer-readable medium for execution by a processor. A module may be integrated with one or more servers, or may be loaded and executed by one or more servers. One or more modules may be grouped into engines or applications.

[0099] Those skilled in the art will recognize that the methods and systems of the present disclosure may be implemented in many ways and are thus not limited by the foregoing illustrative embodiments and examples. In other words, functional elements and individual functions performed by single or multiple components in various combinations of hardware and software or firmware may be distributed among software applications at the client level or server level or both. In this regard, any number of features of the different embodiments described herein may be combined into a single or multiple embodiments, and alternative embodiments having fewer or more than all of the features described herein are possible.

[0100] Functionality may also be distributed, in whole or in part, among multiple components in ways now known or to be known in the future. Thus, a variety of software / hardware / firmware combinations are possible in implementing the functions, features, interfaces, and preferences described herein. Furthermore, the scope of the present disclosure encompasses conventionally known ways of implementing the described features and functions and interfaces, as well as those changes and modifications that may be made to the hardware or software or firmware components described herein as will now and later be understood by those skilled in the art.

[0101] In addition, embodiments of the methods presented and described as flow charts in this disclosure are provided by way of example to provide a more complete understanding of the technology. The disclosed methods are not limited to the operations and logical flows presented herein. Alternative embodiments are contemplated in which the order of the various operations is changed and in which sub-operations described as parts of larger operations are performed independently.

[0102] Although various embodiments have been described for the purposes of this disclosure, such embodiments should not be considered to limit the teachings of this disclosure to those embodiments. Various changes and modifications may be made to the elements and operations described above to obtain results that remain within the scope of the systems and processes described in this disclosure.

Claims

1. A method for operating a scanner, the method comprising: scanning a network to obtain a list of devices on the network; classifying the device as a controlled device or an uncontrolled device, wherein a controlled device can be controlled by the scanner and an uncontrolled device cannot be controlled by the scanner; authenticating to the controlled device to establish a secure channel with the controlled device; issuing one or more control commands to the controlled device through the secure channel, the one or more control commands being contained in a signed message, the signed message being signed using a private key of the scanner and verified using a public key received from the scanner by the corresponding controlled device, the private key and public key being generated by the scanner during the establishment of the secure channel; receiving a response to the control command; and The control command and the response are recorded in the blockchain.

2. The method of claim 1, wherein classifying the device as a controlled device or an uncontrolled device comprises identifying one or more devices that support DICE-RIoT key generation. 3 . The method of claim 1 , wherein scanning a network to obtain a list of devices on the network comprises scanning for one or more Bluetooth-enabled devices. 4 . The method according to claim 1 , wherein establishing a secure channel with the controlled device comprises transmitting a triplet to the controlled device, the triplet comprising a device identifier of the scanner, a certificate of the scanner, and the public key. 5 . The method according to claim 1 , wherein issuing one or more control commands to the controlled device through the secure channel comprises issuing a control command instructing the controlled device to power off. The method of claim 1 , further comprising transmitting a notification to the uncontrolled device, the notification instructing the uncontrolled device to perform an operation.

7. According to the method of claim 1, recording the control command and the response in the blockchain includes recording a triplet of the scanner that generates the control command, a public identifier of the target controlled device, instruction information, and a digital signature.

8. A non-transitory computer readable storage medium for tangibly storing computer program instructions executable by a computer processor of a scanner, the computer program instructions defining the steps of: scanning a network to obtain a list of devices on the network; classifying the device as a controlled device or an uncontrolled device, wherein a controlled device can be controlled by the scanner and an uncontrolled device cannot be controlled by the scanner; authenticating to the controlled device to establish a secure channel with the controlled device; issuing one or more control commands to the controlled device through the secure channel, the one or more control commands being contained in a signed message, the signed message being signed using a private key of the scanner and verified using a public key received from the scanner by the corresponding controlled device, the private key and public key being generated by the scanner during the establishment of the secure channel; receiving a response to the control command; and The control command and the response are recorded in the blockchain.

9. The non-transitory computer-readable storage medium of claim 8, the classifying the device as a controlled device or an uncontrolled device comprises identifying one or more devices that support DICE-RIoT key generation.

10. The non-transitory computer-readable storage medium of claim 8, the scanning a network to obtain a list of devices on the network comprises scanning for one or more Bluetooth-enabled devices.

11. The non-transitory computer-readable storage medium of claim 8, wherein establishing a secure channel with the controlled device comprises transmitting a triplet to the controlled device, the triplet comprising a device identifier of the scanner, a certificate of the scanner, and the public key. 12 . The non-transitory computer-readable storage medium of claim 8 , wherein issuing one or more control commands to the controlled device through the secure channel comprises issuing a control command instructing the controlled device to power off.

13. The non-transitory computer-readable storage medium of claim 8, the steps further comprising transmitting a notification to the uncontrolled device, the notification instructing the uncontrolled device to perform an operation.

14. The non-transitory computer-readable storage medium of claim 8, wherein recording the control command and the response in a blockchain comprises recording a triplet of the scanner that generates the control command, a public identifier of a target controlled device, instruction information, and a digital signature.

15. A scanning device, comprising: processor; and A storage medium for tangibly storing program logic thereon for execution by the processor, the stored program logic comprising: logic executed by the processor to scan a network to obtain a list of devices on the network; logic executed by the processor to classify the device as a controlled device or an uncontrolled device, wherein a controlled device is capable of being controlled by the scanning device and an uncontrolled device is not capable of being controlled by the scanning device; logic executed by the processor to authenticate to the controlled device to establish a secure channel with the controlled device; logic executed by the processor to issue one or more control commands to the controlled device over the secure channel, the one or more control commands being contained in a signed message, the signed message being signed using a private key of the scanning device and verified using a public key received by a corresponding controlled device from the scanning device, the private and public keys being generated by the scanning device during the establishment of the secure channel; logic executed by the processor to receive a response to the control command; and Logic executed by the processor to record the control command and the response in a blockchain.

16. The scanning device of claim 15, wherein classifying the device as a controlled device or an uncontrolled device comprises identifying one or more devices that support DICE-RIoT key generation.

17. The scanning device of claim 15, wherein scanning a network to obtain a list of devices on the network comprises scanning for one or more devices with Bluetooth capabilities.

18. The scanning device of claim 15, wherein establishing a secure channel with the controlled device comprises transmitting a triplet to the controlled device, the triplet comprising a device identifier of the scanning device, a certificate of the scanning device, and the public key.

19. The scanning device according to claim 15, wherein the issuing of one or more control commands to the controlled device through the secure channel comprises issuing a control command instructing the controlled device to power off.

20. According to the scanning device according to claim 15, recording the control command and the response in the blockchain includes recording the triplet of the scanning device that generates the control command, the public identifier of the target controlled device, the instruction information and the digital signature.

Images