WO2020197729A1 - Gestion à distance de dispositifs utilisant une chaîne de blocs et dice-riot - Google Patents

Gestion à distance de dispositifs utilisant une chaîne de blocs et dice-riot Download PDF

Info

Publication number
WO2020197729A1
WO2020197729A1 PCT/US2020/021116 US2020021116W WO2020197729A1 WO 2020197729 A1 WO2020197729 A1 WO 2020197729A1 US 2020021116 W US2020021116 W US 2020021116W WO 2020197729 A1 WO2020197729 A1 WO 2020197729A1
Authority
WO
WIPO (PCT)
Prior art keywords
devices
control commands
controlled
secure channel
network
Prior art date
Application number
PCT/US2020/021116
Other languages
English (en)
Inventor
Antonino Mondello
Alberto TROIA
Original Assignee
Micron Technology, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Micron Technology, Inc. filed Critical Micron Technology, Inc.
Priority to KR1020217031916A priority Critical patent/KR20210126141A/ko
Priority to JP2021557295A priority patent/JP2022528359A/ja
Priority to EP20777542.0A priority patent/EP3949254A4/fr
Priority to CN202080028173.8A priority patent/CN113678402A/zh
Publication of WO2020197729A1 publication Critical patent/WO2020197729A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0847—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving identity based encryption [IBE] schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2816—Controlling appliance services of a home automation network by calling their functionalities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/28—Restricting access to network management systems or functions, e.g. using authorisation function to access network configuration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3215—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a plurality of channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/16—Discovering, processing access restriction or access information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Definitions

  • the disclosed embodiments are directed toward computer security and, specifically, to devices, computer-readable media, and methods for remotely managing computing devices using blockchain and DICE-RIoT.
  • user devices are coercively controlled. That is, users are forced to submit to a central authority (e.g., turn off mobile phones etc.) under threat of negative action. For instance, during air travel, users are legally required to shut off cell phones and other wireless devices under threat of removal from an aircraft or civil penalties.
  • a central authority e.g., turn off mobile phones etc.
  • a user willingly grants management of a device to a remote entity. For example, a user may accept that the user's employer may access their device and install/remove applications, control settings etc. via provisioning profiles. In some embodiments, these schemes may be limited in the geographic area in which control can be exerted or in the type of control exerted.
  • a method comprising scanning a network to obtain a list of devices on the network; classifying the devices as either controlled or uncontrolled devices; establishing a secure channel with the controlled devices; issuing one or more control commands to the controlled devices over the secure channel, the one or more control commands included within a signed message, the signed message signed using a private key of the sender and verified using a public key of the receiver, the private key and public key generated during the establishing of the secure channel; receiving a response to the control commands; and logging the control commands and the response in a blockchain.
  • a non-transitory computer readable storage medium for tangibly storing computer program instructions capable of being executed by a computer processor, the computer program instructions defining the steps of: scanning a network to obtain a list of devices on the network; classifying the devices as either controlled, uncontrolled, or restricted devices; establishing a secure channel with the controlled devices; issuing one or more control commands to the controlled devices over the secure channel, the one or more control commands included within a signed message, the signed message signed using a private key of the sender and verified using a public key of the receiver, the private key and public key generated during the establishing of the secure channel; receiving a response to the control commands; and logging the control commands and the response in a blockchain.
  • a device comprising: a processor; and a storage medium for tangibly storing thereon program logic for execution by the processor, the stored program logic comprising: logic, executed by the processor, for scanning a network to obtain a list of devices on the network; logic, executed by the processor, for classifying the devices as either controlled, uncontrolled, or restricted devices; logic, executed by the processor, for establishing a secure channel with the controlled devices; logic, executed by the processor, for issuing one or more control commands to the controlled devices over the secure channel, the one or more control commands included within a signed message, the signed message signed using a private key of the sender and verified using a public key of the receiver, the private key and public key generated during the establishing of the secure channel; logic, executed by the processor, for receiving a response to the control commands; and logic, executed by the processor, for logging the control commands and the response in a blockchain.
  • FIG. 1 is a block diagram of a system for managing remote devices according to one embodiment of the disclosure.
  • FIG. 2A is a flow diagram illustrating a method for controlling remote devices in a closed area according to some embodiments of the disclosure.
  • FIG. 2B is a flow diagram illustrating a method for controlling remote devices in an open area according to some embodiments of the disclosure.
  • FIG. 3 is a flow diagram illustrating a method for responding to a remote control request according to some embodiments of the disclosure.
  • FIG. 4 is a block diagram illustrating a DICE-RIoT communications system according to some embodiments of the disclosure.
  • FIG. 5 is a diagram of a blockchain data structure and respective blocks of the structure according to some embodiments of the disclosure.
  • FIG. 6 is a block diagram of a computing device according to some embodiments of the disclosure.
  • FIG. 1 is a block diagram of a system for managing remote devices according to one embodiment of the disclosure.
  • a network (118) connects a scanner (102), devices (108a-108n), certificate authority (120), unrestricted devices (116), and uncontrolled devices (114).
  • the network (118) can comprise multiple different networks such as a Wi-Fi network, cellular network, personal area network (e.g., Bluetooth), near-field communication (NFC) network, and any other network.
  • scanner (102) comprises a device that is designed to control one or more devices.
  • scanner (102) comprises a hardware module or standalone device placed in a closed area requiring control.
  • the scanner (102) may comprise a device attached to an x-ray machine at an airport, in a hospital laboratory, an airplane cabin, or other area where control over electronic devices are present.
  • the scanner (102) includes a DICE/RIoT subsystem (104) and a blockchain module (106).
  • the DICE/RIoT subsystem (104) comprises an Lo and Li DICE/RIoT subsystem that generates a layer 1 public key, device identifier, and certificate as will be described herein.
  • the DICE/RIoT subsystem (104) can comprise a combination of firmware (ROM) code, and upper layer software. The operation of the DICE/RIoT subsystem (104) is described more fully in connection with FIG. 4, incorporated herein by reference in its entirety.
  • the scanner (102) additionally includes a blockchain module (106).
  • the blockchain module (106) is responsible for the actual storage of blockchain data (illustrated in FIG. 5) as well as performing all blockchain operations (e.g., block validation, consensus etc.).
  • blockchain module (106) provides for a tamper-proof record of instructions sent to devices (108a-108n) and how those devices reacted to the instructions.
  • Devices (108a-108n) are referred to as controlled devices since they are capable of being controlled by the scanner (102).
  • a device is controllable if it contains a DICE/RIoT subsystem (112).
  • the presence of a DICE/RIoT subsystem allows the controlled devices to verify the identity of the scanner and also generate their own verifiable identifies that can be used to mutually acknowledge that each device (scanner and controlled device) is who they say they are.
  • each controlled device includes a variety of standard network interfaces (llOa-llOc). These interfaces operate as standard interfaces and enable the controlled devices (108a-108n) to communicate with the scanner (102) via various networks.
  • an unrestricted device may have a DICE/RIoT subsystem (or may not) but is otherwise exempt from control.
  • an unrestricted device has a triple that is recorded as a known unrestricted device and thus scanner (102) ignores such a device when attempting to control devices within its coverage area.
  • scanner 102 ignores such a device when attempting to control devices within its coverage area.
  • an unrestricted device comprises telecommunications equipment (e.g., routers, etc.) that may be present in the area covered by the scanner.
  • an uncontrolled device (114) is one that does not include a DICE/RIoT subsystem. Since this subsystem is missing, uncontrolled device (114) cannot verify the identity of the scanner (102) and thus will not respond to commands to control the device (for security purposes). For these devices, the system may fall back to existing methods of controlling devices (discussed previously). Notably, while DICE/RIoT is discussed primarily in the specification, other authentication schemes may be used provided they meet the requirements described herein.
  • 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 devices may sign their own certificates.
  • FIG. 2A is a flow diagram illustrating a method for controlling remote devices in a closed area according to some embodiments of the disclosure.
  • the method in FIG. 2A may be performed by the aforementioned scanner.
  • step 202 the method scans networks.
  • the networks include a Bluetooth network, that is, a listing of nearby networks available to connect to via Bluetooth.
  • the method may transmit a broadcast request over a Wi-Fi network or other network to identify devices on the network.
  • the method obtains a listing of devices and network addresses (e.g., IP addresses, MAC addresses, Bluetooth address etc.).
  • step 204 the method classifies the devices identified in step 202.
  • a device when a device is detected it may report various properties of the device. For instance, in the Bluetooth scenario, the scanner may establish an insecure socket with the device to control after detecting its Bluetooth address. If the device includes a DICE/RIoT system, it may be configured to broadcast that ability over the insecure channel. For devices that do not include a DICE/RIoT system, the method receives no such indication and classifies the device as an unsupported device.
  • the scanner may establish an insecure socket with the device to control after detecting its Bluetooth address. If the device includes a DICE/RIoT system, it may be configured to broadcast that ability over the insecure channel. For devices that do not include a DICE/RIoT system, the method receives no such indication and classifies the device as an unsupported device.
  • step 206 for each device, the method determines if the device is supported or unsupported.
  • the method proceeds to fallback to existing methods of controlling devices. 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 inform the user of a desired action. Of course, the user may opt to ignore this notification.
  • the method may jam communications in addition to notifying the user to turn off the device (step 210).
  • the jamming of communications may be optional an only employed in specific scenarios.
  • step 212 the method then logs the notification sent to the uncontrolled device in a blockchain block.
  • the method records all messages sent to device, regardless of whether or not the device can or does respond to the message. In this manner, the method maintains a record of the messages sent during operation of the scanner in a secure tamper-proof data structure.
  • the method proceeds to authenticate with the device and establish a secure channel (step 214).
  • this comprises the method transferring identification information to the device and the device acknowledging the identity of the scanner.
  • the identification information comprises a triple comprising a device identifier, public key, and certificate generated via an Li DICE- RIoT key generation process (described herein).
  • layer 0 and 1 are used for authentication while layers 2 and beyond (in both devices) are used for messaging.
  • the secure channel comprises a TLS connection formed after exchanging keys.
  • step 216 after authenticating, the method issues a communication control command.
  • the method generates control commands that will result in the device performing an action (e.g., turning off). 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 event, the method selects the necessary command based on configuration parameters of the device implementing the method.
  • the method packs the control instruction into a message and signs the message using its Li private key. The method then transmits this instruction to the device wherein the device may verify the signature using its L2 public key.
  • the message additionally includes a freshness value to avoid a replay attack such as a monotonic counter, timestamp etc.
  • the device After receiving the command, the device executes the command as described in FIG. 3. After executing the command (or if the command is to effect its ability to send a message), the device returns a response to the method (step 218).
  • the response may include various data regarding the execution of the order. For example, it may include an explicit acknowledgement of the order, a timestamp of when the order will be executed, a stack trace at the time executed, and any other data related to the order. Similar to the order, the response may be signed using the devices Fi key and verified using the methods F2 key (e.g., a scanners F2 key). [0046] In step 220, the method determines if the response is authentic. In one embodiment, this comprises verifying the signature of the response by using the method's L2 key. Additionally, the method may confirm that the sender's certificate and public identifier are valid.
  • the method logs the response to the blockchain (step 222). Similar to step 212, the scanner logs the order and the response to the blockchain to record the interactions between the devices. In one embodiment, the method may record the order prior to receiving a response. Alternatively, the method may record both records at the same time.
  • FIG. 2B is a flow diagram illustrating a method for controlling remote devices in an open area according to some embodiments of the disclosure.
  • step 224 the method receives a broad request.
  • the method illustrated in FIG. 2B may be applied to a large geographic area (e.g., a few acres, a city, etc.).
  • the broadcast request may be issued by an authority (e.g., police).
  • the broadcast request may state that all devices within a defined area perform one or more operations included within the request (e.g., turn off, limit bandwidth).
  • the method checks to see whether the device transmitting the request is authenticated (step 226).
  • the method may employed a DICE-RIoT certificate check to confirm the identity of the sender (e.g., by doubly- decrypting a triple associated with the sender to confirm their identity).
  • the method denies the request (step 228) and logs the request (230) to a blockchain storage device. In the illustrated embodiment, the method denies the request by simply ignore the request. The method also logs the request for law enforcement or other purposes. In some embodiments, the log includes an identity of the sender (e.g., IP address, etc.) to identify a potentially malicious user.
  • 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 re-packs the request and signs the request using its own private key, to ensure security of the message.
  • step 234 the method performs separate actions based on the type of receiver.
  • the method receives an ignore message (step 240) from an emergency vehicle or personnel. For example, if the control instruction is to turn off all cell phones during an emergency (or to limit bandwidth), this control instruction may be ignored by emergency workers and equipment.
  • the method transmits a control instruction to those devices and receives acknowledgement responses (step 238).
  • steps 216, 218, 220, 208, 210, 212, and 222 the disclosure of which is incorporated herein by reference in its entirety.
  • step 234 may comprise identifying a list of devices within the service area similar to that described in steps 202 and 204 of FIG. 2 A.
  • the network scanned may comprise a cellular network area (e.g., one or more areas serviced by a given cell tower).
  • scanning the network comprises identifying a listing of IP addresses in a given area (e.g., by querying cellular base station equipment).
  • FIG. 3 is a flow diagram illustrating a method for responding to a remote control request according to some embodiments of the disclosure.
  • the method may be performed by a controlled device.
  • Many features of the controlled device have been described from the context of a controlling device and those details are not repeated herein but are incorporated by reference.
  • step 302 the method receives a request.
  • this request comprises a control instruction from a remote device (e.g., a scanner in FIG. 1).
  • step 304 the method authenticates the request. As described above, this may comprise verifying a digital signature using an L2 public key. [0061] In step 310, the method denies the request if the signature validation fails and, optionally, transmits a notice to the sender that the device will not honor the request.
  • step 306 the method honors the request if the signature validation passes.
  • the device may perform one or more actions included within the request such as turning off the device, limiting bandwidth, enabling full bandwidth (if the device is a router or other telecommunications equipment), etc.
  • step 308 the method generates, signs, and transmits a response.
  • the response comprises service information of the request such a time the request will be fulfilled, what specific actions will be taken etc.
  • the method signs the request using its private key and transmits the response to the sender for recordation in a blockchain, as described above.
  • FIG. 4 is a block diagram illustrating a DICE-RIoT communications system according to some embodiments of the disclosure.
  • a scanner (502a) and target (502b) communicate via a bi directional communications path (512). All communications over path (512) are secured via UDS servers (504, 408) installed within the scanner (502a) and target (502b) respectively.
  • the UDS servers (504, 408) comprise the same, or similar, hardware devices installed within the scanner (502a) and target (502b). Thus, descriptions of one UDS server are equally applicable to other unless otherwise distinguished.
  • Each UDS server has a "device secret” (e.g., 404a).
  • the device secret is known only to the manufacturer of the device and processing core of the server (e.g., Lo ROM 404b), and is used in the creation of a Compound Device Identifier ("CDI") by the processing core.
  • CDI is a set of data used to identify the software running on a system that was used to generate the data.
  • the CDI is created using a one-way hash function (denoted as H).
  • the UDS server calculates a hash (or other unique measurement of the Li code (504c).
  • the UDS server further can utilize the hardware state and configuration data of the device when computing 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 is completely removed from volatile memory. Control of the device is then transferred to the Li code (504c) (step 420e).
  • a hash message authentication code (HMAC) function may be used in lieu of a one-way hash function.
  • the device secret may be used as a key and the hash of the Li code is used as the message.
  • the Li code (504c) receives the CDI and uses the CDI to generate secure keys and certificates to identify the device. Since the CDI is generated using the UDS and hash of the code generating such keys, it ensures authenticity of the generated keys/certificates. After generating the CDI, the Li code (504c) permanently deletes the CDI from memory, thus preventing leakage of the CDI. In one embodiment, the Li code (504c) is never modified and thus the CDI remains the same throughout the life of the device providing the Li code (504c).
  • a UDS server generates a secure key pair in a DICE-RIoT architecture for use by other layers (e.g., Layer Lz 406a).
  • the UDS server generates an asymmetric DevicelD key pair using the CDI received from the Lo code (discussed supra).
  • the method uses a deterministic asymmetric key generation algorithm to generate a public and private key, the choice of specific algorithm is not intended to be limiting.
  • the UDS server exports the public portion of the key pair to the next layer of code (e.g., the Lz layer).
  • the UDS server creates a certificate structure containing the public key.
  • the certificate may comprise an X.509-formatted certificate.
  • the UDS server may additionally generate one or more alias keys using the CID and a hash of the next layer of software. For instance, the UDS server can generate the alias keys using the CID and a hash of the Lz software (506a).
  • a UDS server can query a target device (502b) to request the hash of the Lz code.
  • the UDS server stores the hash of the Lz code installed during manufacturing or updated out-of-band by a remote service.
  • the Lz code is associated with specific hardware installed in the target (502b) or scanner (502a) and thus is relatively static and unchanging during the life of the device. For example, a single entity may manufacture the chips associated with the Li and Lz software, thus the hashes of this code may be well known to the system.
  • the Lz software may load additional modules, assuming they are authorized by a firmware security descriptor. Eventually, the Lz software (or code loaded by the Lz software) can use the keys and certificates provided by Li to authenticate itself using Transport Layer Security (TLS). In one embodiment, the Lz software ensures that the software only uses the alias key issued to it. That is, the Lz software should not use an alias credential issued to an earlier firmware version.
  • TLS Transport Layer Security
  • the aforementioned process may be repeated throughout the target (502b). That is, the Lz software (506a) generates a new alias key for the next layer, together with an alias certificate that encodes a hash of the layer above. For example, the Lz software (506a) generates an alias key for the OS (506b) using a hash of the OS (506b), the OS (506b) generates an alias key for app (506c) using a hash of the app (506c), etc.
  • the alias certificates issued to the next layers are signed with the alias key granted to the underlying layer (rather than the DevicelD key.) In other words, additional layers serve as additional subordinate certificate authorities.
  • This scheme can be extended all the way to the application layer, where each application gets a unique alias key and certificate that encodes it identity. In these cases, relying parties can walk the alias certificate chain to establish both the identity of the top layer and the identity of all the lower layers that comprise the top layer's trusted computing base.
  • the illustrated system distributes the layers of the protocol among two or more devices. That is, instead of the Lz software (506a) resident on the scanner, it is resident on the target device and is associated with separate hardware.
  • the scanner and target device may only be operating using the DICE-RIoT protocol when in close proximity to one another (i.e., within 100 meters or within Bluetooth® range).
  • the two devices may employ a personal area network (PAN), near -field communication network, or other high-speed ad hoc network to exchange hashes of layers used to generate alias keys in the manner described above.
  • PAN personal area network
  • near -field communication network or other high-speed ad hoc network
  • these keys and certificates may be used to sign and, in some embodiments, encrypt all future communications between the two devices, ensuring that man-in- the-middle attacks are prevented which would control the target device using a spoofed key.
  • the scanner will generally transmit a message that includes a digital signature generated using the private key of the scanner.
  • the Lz software (506a) can verify the identifying using the scanner certificate received during the process described above.
  • the message will also be secured against replay attacks.
  • the Lz software (506a) provides a random string (e.g., a random message) to the Li code.
  • the Li code When signing the message, the Li code will sign the messaging using both its private key as well as the random message.
  • the Lz software (506a) will know the random message and be able to verify that the sender is indeed authorized.
  • FIG. 5 is a diagram of a blockchain data structure and respective blocks of the structure according to some embodiments of the disclosure.
  • a blockchain represents an immutable and cryptographically verified record of transactions or changes in state of data.
  • the request and response is recorded to the blockchain.
  • scanner devices or other controlling devices
  • all requests/responses are verified and recorded for future retrieval if needed.
  • the inherent verification of a blockchain ensures that rogue entities cannot maliciously attempt to issue control commands (or erroneously pretend to respond to them).
  • FIG. 5 additionally illustrates the contents of a block (502) in the chain generated by a controlling device such as a scanner.
  • the block includes a main ledger block header (502a) that includes a hash of the current block and hash of the previous block.
  • the block additionally includes a triple including the scanner ID (502b), the scanner's certificate (502c), and the public key of the scanner (502d) described above.
  • the destination of the request (the "target") device is also recorded (502e).
  • a freshness field (502f) is included which may comprise a timestamp, monotonic value, or other value.
  • the block additionally includes order details (502g) which may, optionally, be encrypted. These details include the specific control instructions issued to the target device by the scanner.
  • each block is signed by the sender (e.g., the scanner for block 502) and the signature is packed and included in the block as packed digital signature (502h).
  • the signature (502h) is signed using the senders private key and is verified by a receiver using the receivers public key.
  • the chain includes responses such as response block (503).
  • This response block (503) is generated by the scanner, but utilizes the data returned by a controlled device in response to a request.
  • the block (503) is similar to block (502) and many details of block (502) are incorporated by reference in the description of block (503).
  • block (503) includes a header (503a), a freshness value (503f), a triple (503b-503d) and a destination identifier (503e).
  • the triple and destination identifier refer to the target device and scanner, respectively, the opposite of block (502).
  • block (503) includes service information (503g) which comprises the details of how the target device responded to an order.
  • the methods log data to a blockchain data structure in multiple steps.
  • logging data comprises adding a block to the blockchain data structure.
  • a block is recognized as part of the blocking (i.e., is included in the ledger) if two conditions are met.
  • the hash of the previous block must match the hash of the previous block as previously computed. That is, referring to FIG. 5, the "Hash (previous local block)" of header 503a must match "Hash (current local block)" of previous block 502a, before block 503 is inserted.
  • the block must satisfy a second, non-standard condition that the block be generated by an authorized host of the system.
  • FIG. 6 is a block diagram of a computing device according to some embodiments of the disclosure.
  • Processing device can include many more or fewer components than those shown in FIG. 6.
  • the aforementioned instances may not require an audio interface, display, keypad, illuminator, or earner as/sensors.
  • the components shown are sufficient to disclose an illustrative embodiment for implementing the present disclosure.
  • the device illustrated in FIG. 6 can be implemented as a virtual machine while in other embodiments the device can be implemented as a physical machine. In some embodiments, the device is implemented as both, with a virtual machine running on the device depicted in FIG. 6.
  • device (600) includes processing units (CPUs) (602) in communication with a mass memory (604) via a bus (614).
  • 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 a earner a(s) or other optical, thermal or electromagnetic sensors (628).
  • Device (600) can include one earner a/sensor (628), or a plurality of earner as/sensors (628), as understood by those of skill in the art.
  • Device (600) can optionally communicate with a base station (not shown), or directly with another computing device.
  • Network interface (616) includes circuitry for coupling device (600) to one or more networks and is constructed for use with one or more communication protocols and technologies.
  • Network interface (616) is sometimes known as a transceiver, transceiving device, or network interface card (NIC).
  • Audio interface (618) is arranged to produce and receive audio signals such as the sound of a human voice.
  • audio interface (618) can be coupled to a speaker and microphone (not shown) to enable telecommunication with others and generate an audio acknowledgment for some action.
  • Display (620) can be a liquid crystal display (LCD), gas plasma, light emitting diode (LED), or any other type of display used with a computing device.
  • Display (620) can also include a touch sensitive screen arranged to receive input from an object such as a stylus or a digit from a human hand.
  • Keypad (622) can comprise any input device arranged to receive input from a user.
  • keypad (622) can include a push button numeric dial, or a keyboard.
  • Keypad (622) can also include command buttons that are associated with selecting and sending images.
  • Illuminator (624) can provide a status indication and provide light.
  • Illuminator (624) can remain active for specific periods of time or in response to events. For example, when illuminator (624) is active, it can backlight the buttons on keypad (622) and stay on while the device (600) is powered. Also, illuminator (624) can backlight these buttons in various patterns when actions are performed, such as dialing another processing device.
  • Illuminator (624) can also cause light sources positioned within a transparent or translucent case of the device (600) to illuminate in response to actions.
  • Device (600) also comprises input/output interface (626) for communicating with external devices not shown in FIG. 6.
  • Input/output interface (626) can utilize one or more communication technologies, such as USB, infrared, BluetoothTM, or the like.
  • Mass memory (604) includes a RAM (606), a ROM (610), and other storage means. Mass memory (604) illustrates another example of computer storage media for storage of information such as computer-readable instructions, data structures, program modules or other data. Mass memory (604) stores a basic input/output system ("BIOS") (612) for controlling low-level operation of processing device (600). The mass memory can also store an operating system for controlling the operation of processing device (600). It will be appreciated that this component can include a general-purpose operating system such as a version of UNIX, or LINUXTM, or a specialized client communication operating system such as Windows ClientTM, or the Symbian® operating system.
  • BIOS basic input/output system
  • this component can include a general-purpose operating system such as a version of UNIX, or LINUXTM, or a specialized client communication operating system such as Windows ClientTM, or the Symbian® operating system.
  • the operating system can include, or interface with a Java virtual machine module that enables control of hardware components and operating system operations via Java application programs.
  • Memory (604) includes one or more software applications for implementing some or all of the methods described above, with the exception of ROM-based cryptography DICE-RIoT operations described explicitly above (which are performed in ROM (61).
  • terms, such as “a,” “an,” or “the,” again, may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context.
  • the term “based on” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for existence of additional factors not necessarily expressly described, again, depending at least in part on context.
  • These computer program instructions can be provided to a processor of: a general purpose computer to alter its function to a special purpose; a special purpose computer; ASIC; or other programmable digital data processing apparatus, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, implement the functions/acts specified in the block diagrams or operational block or blocks, thereby transforming their functionality in accordance with embodiments herein.
  • a computer readable medium stores computer data, which data can include computer program code (or computer-executable instructions) that is executable by a computer, in machine readable form.
  • a computer readable medium may comprise computer readable storage media, for tangible or fixed storage of data, or communication media for transient interpretation of code-containing signals.
  • Computer readable storage media refers to physical or tangible storage (as opposed to signals) and includes without limitation volatile and non-volatile, removable and non-removable media implemented in any method or technology for the tangible storage of information such as computer- readable instructions, data structures, program modules or other data.
  • Computer readable storage media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid-state memory technology, CD-ROM, DVD, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other physical or material medium which can be used to tangibly store the desired information or data or instructions and which can be accessed by a computer or processor.
  • a module is a software, hardware, or firmware (or combinations thereof) system, process or functionality, or component thereof, that performs or facilitates the processes, features, and/or functions described herein (with or without human interaction or augmentation).
  • a module can include sub-modules.
  • Software components of a module may be stored on a computer readable medium for execution by a processor. Modules may be integral to one or more servers, or be loaded and executed by one or more servers. One or more modules may be grouped into an engine or an application.

Abstract

La présente invention concerne des techniques de gestion à distance de dispositifs informatiques utilisant une chaîne de blocs et DICE-RIoT. Selon un mode de réalisation, la présente invention concerne un procédé comprenant : le balayage d'un réseau afin d'obtenir une liste des dispositifs sur le réseau ; la classification des dispositifs en tant que dispositifs contrôlés ou non contrôlés ; l'établissement d'un canal sécurisé avec les dispositifs contrôlés ; la délivrance d'une ou plusieurs instructions de commande aux dispositifs contrôlés par l'intermédiaire du canal sécurisé, la ou les instructions de commande étant incluses dans un message signé, le message signé étant signé à l'aide d'une clé privée de l'expéditeur et vérifié à l'aide d'une clé publique du récepteur, la clé privée et la clé publique étant générées pendant l'établissement du canal sécurisé ; la réception d'une réponse aux instructions de commande ; et la consignation des instructions de commande et de la réponse dans une chaîne de blocs.
PCT/US2020/021116 2019-03-25 2020-03-05 Gestion à distance de dispositifs utilisant une chaîne de blocs et dice-riot WO2020197729A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
KR1020217031916A KR20210126141A (ko) 2019-03-25 2020-03-05 블록체인 및 dice-riot을 사용한 원격 장치 관리
JP2021557295A JP2022528359A (ja) 2019-03-25 2020-03-05 ブロックチェーン及びＤＩＣＥ－ＲＩｏＴを使用したデバイスのリモート管理
EP20777542.0A EP3949254A4 (fr) 2019-03-25 2020-03-05 Gestion à distance de dispositifs utilisant une chaîne de blocs et dice-riot
CN202080028173.8A CN113678402A (zh) 2019-03-25 2020-03-05 使用区块链及dice-riot来远程管理装置

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/363,295 2019-03-25
US16/363,295 US11128451B2 (en) 2019-03-25 2019-03-25 Remotely managing devices using blockchain and DICE-RIoT

Publications (1)

Publication Number Publication Date
WO2020197729A1 true WO2020197729A1 (fr) 2020-10-01

Family

ID=72604172

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2020/021116 WO2020197729A1 (fr) 2019-03-25 2020-03-05 Gestion à distance de dispositifs utilisant une chaîne de blocs et dice-riot

Country Status (6)

Country Link
US (2) US11128451B2 (fr)
EP (1) EP3949254A4 (fr)
JP (1) JP2022528359A (fr)
KR (1) KR20210126141A (fr)
CN (1) CN113678402A (fr)
WO (1) WO2020197729A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11623671B2 (en) * 2019-04-11 2023-04-11 Progress Rail Locomotive Inc. Blockchain remote command verification
EP3723007B1 (fr) * 2019-04-12 2021-03-10 Siemens Aktiengesellschaft Procédé et système de commande permettant de commander l'exécution des transactions
US11847171B2 (en) * 2019-08-20 2023-12-19 International Business Machines Corporation Facilitating blockchain transactions with an Internet of Things (IoT) device
US20230062244A1 (en) * 2021-09-01 2023-03-02 Qualcomm Incorporated Extended reality control of smart devices
CN115942255A (zh) * 2021-09-15 2023-04-07 华为技术有限公司 通道配置方法及装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001030044A2 (fr) * 1999-10-18 2001-04-26 Ivaylo Nicolaev Popov Procede et dispositif pour l'etablissement de voie de communication, d'identification et de paiement dans des conditions de securite
WO2005024598A2 (fr) * 2003-09-09 2005-03-17 Oto Software, Inc Procede et systeme permettant de securiser et de controler un reseau sans fil
US20080301441A1 (en) * 2007-05-30 2008-12-04 Bank Of America Corporation Secure Channel For Image Transmission
US9871772B1 (en) * 2015-03-17 2018-01-16 The Charles Stark Draper Laboratory, Inc. Cryptographic system for secure command and control of remotely controlled devices
US20190044820A1 (en) * 2017-08-01 2019-02-07 Servicenow, Inc. Automatic Grouping of Similar Applications and Devices on a Network Map

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10121819A1 (de) * 2001-05-04 2002-11-21 Wolfgang Rosner Verfahren zur kontextspezifischen Remote-Authentifizierung des Datenzugriffs
US7031473B2 (en) * 2001-11-13 2006-04-18 Microsoft Corporation Network architecture for secure communications between two console-based gaming systems
JP2003283489A (ja) * 2002-03-20 2003-10-03 Hitachi Ltd パケット認証システムおよび認証方法、ならびにグループ管理サーバとグループメンバー装置
CN202022184U (zh) * 2011-01-24 2011-11-02 陕西理工学院 汽车远程防盗报警器
US10129211B2 (en) * 2011-09-15 2018-11-13 Stephan HEATH Methods and/or systems for an online and/or mobile privacy and/or security encryption technologies used in cloud computing with the combination of data mining and/or encryption of user's personal data and/or location data for marketing of internet posted promotions, social messaging or offers using multiple devices, browsers, operating systems, networks, fiber optic communications, multichannel platforms
MX342909B (es) * 2012-02-21 2016-10-18 Zih Corp Metodos, aparatos y productos de programas para computadora para implementar impresoras conectadas a la nube y un marco adaptable de aplicacion basado en la impresora.
US9170718B2 (en) * 2012-07-25 2015-10-27 Devicescape Software, Inc. Systems and methods for enhanced engagement
WO2014198533A2 (fr) * 2013-06-14 2014-12-18 Koninklijke Philips N.V. Système comprenant un dispositif de commande et un dispositif commandé
JP6268616B2 (ja) * 2013-12-16 2018-01-31 パナソニックＩｐマネジメント株式会社 認証システムおよび認証方法
CN103944734A (zh) * 2014-04-25 2014-07-23 天地融科技股份有限公司 数据安全交互方法
US9906924B2 (en) * 2014-10-09 2018-02-27 General Motors Llc Establishing a local vehicle communication group
US9900159B2 (en) * 2015-07-21 2018-02-20 Micron Technology, Inc. Solid state storage device with command and control access
KR101678795B1 (ko) * 2015-11-30 2016-11-22 전삼구 블록체인 인증을 이용하는 IoT 기반 사물 관리 시스템 및 방법
MY190785A (en) * 2015-12-21 2022-05-12 Koninklijke Philips Nv Network system for secure communication
US11233644B2 (en) * 2017-08-09 2022-01-25 Gridplus Inc. System for secure storage of cryptographic keys
FR3076420B1 (fr) * 2017-12-29 2020-02-07 Commissariat A L'energie Atomique Et Aux Energies Alternatives Methode d'echange de cles par contrat intelligent deploye sur une chaine de blocs
CN108305072B (zh) * 2018-01-04 2021-02-26 上海点融信息科技有限责任公司 部署区块链网络的方法、设备和计算机存储介质
US10678938B2 (en) * 2018-03-30 2020-06-09 Intel Corporation Trustworthy peripheral transfer of ownership
US10937253B2 (en) * 2018-06-11 2021-03-02 International Business Machines Corporation Validation of vehicle data via blockchain
US11223606B2 (en) * 2018-06-29 2022-01-11 Intel Corporation Technologies for attesting a deployed workload using blockchain
CN109492352B (zh) * 2018-10-09 2021-01-29 华为技术有限公司 一种设备标识组合引擎的实现方法及装置
US11716194B2 (en) * 2018-10-12 2023-08-01 Micron Technology, Inc. Vehicle communication for authorized entry
US11070632B2 (en) * 2018-10-17 2021-07-20 Servicenow, Inc. Identifying computing devices in a managed network that are involved in blockchain-based mining

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001030044A2 (fr) * 1999-10-18 2001-04-26 Ivaylo Nicolaev Popov Procede et dispositif pour l'etablissement de voie de communication, d'identification et de paiement dans des conditions de securite
WO2005024598A2 (fr) * 2003-09-09 2005-03-17 Oto Software, Inc Procede et systeme permettant de securiser et de controler un reseau sans fil
US20080301441A1 (en) * 2007-05-30 2008-12-04 Bank Of America Corporation Secure Channel For Image Transmission
US9871772B1 (en) * 2015-03-17 2018-01-16 The Charles Stark Draper Laboratory, Inc. Cryptographic system for secure command and control of remotely controlled devices
US20190044820A1 (en) * 2017-08-01 2019-02-07 Servicenow, Inc. Automatic Grouping of Similar Applications and Devices on a Network Map

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3949254A4 *

Also Published As

Publication number Publication date
CN113678402A (zh) 2021-11-19
EP3949254A4 (fr) 2022-12-21
US11128451B2 (en) 2021-09-21
US20200313877A1 (en) 2020-10-01
EP3949254A1 (fr) 2022-02-09
US20210409201A1 (en) 2021-12-30
JP2022528359A (ja) 2022-06-10
KR20210126141A (ko) 2021-10-19

Similar Documents

Publication Publication Date Title
CN109417553B (zh) 经由内部网络监视来检测使用泄漏证书的攻击
US11128451B2 (en) Remotely managing devices using blockchain and DICE-RIoT
US10680833B2 (en) Obtaining and using time information on a secure element (SE)
US8737965B2 (en) Wireless device monitoring systems and monitoring devices, and associated methods
Karygiannis et al. Wireless Network Security:.
US10630490B2 (en) Obtaining and using time information on a secure element (SE)
US11146532B2 (en) Information security using blockchain technology
US8175578B2 (en) Wireless device monitoring methods, wireless device monitoring systems, and articles of manufacture
EP2127196B1 (fr) Vérification d'échange de clés
WO2013044088A1 (fr) Gestion d'applications pour dispositif mobile dans un réseau sans fil
WO2013044107A2 (fr) Processus d'authentification pour gérer des applications de dispositif mobile
Haataja et al. Bluetooth security attacks: comparative analysis, attacks, and countermeasures
US11431508B1 (en) Distributed ledger-based ad-hoc system, apparatus and method
Zhou et al. Heracles: Scalable, fine-grained access control for internet-of-things in enterprise environments
EP3598333A1 (fr) Gestion de mise à jour de dispositif électronique
CN115001841A (zh) 一种身份认证方法、装置及存储介质
US11539715B1 (en) Distributed ledger-based ad-hoc system, apparatus and method using fingerprint verification
Zhou et al. Towards fine-grained access control in enterprise-scale Internet-of-Things
Echeverria et al. Authentication and authorization for IoT devices in disadvantaged environments
JP2023535474A (ja) アソシエーション制御方法及び関連装置
Kohnhäuser et al. SEDCOS: A secure device-to-device communication system for disaster scenarios
WO2023226778A1 (fr) Procédé et appareil d'authentification d'identité et dispositif électronique et support de stockage lisible par ordinateur
US10972912B1 (en) Dynamic establishment of trust between locally connected devices
Lounis Security of short-range wireless technologies and an authentication protocol for IoT
Graarud Implementing a secure ad hoc network

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20777542

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021557295

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 20217031916

Country of ref document: KR

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2020777542

Country of ref document: EP

Effective date: 20211025