Using distributed ledgers to monitor equipment components

Abstract

The technology disclosed herein provides a method for controlling resources used in a device. An implementation of such a method includes: generating a device configuration ledger block based on an initial assembly of components of a storage device; storing the device configuration ledger block on a node of a distributed ledger; detecting activation of the device; in response to detecting the activation of the device, generating a current distributed ledger block based on a current assembly of components of the storage device; comparing the current distributed ledger block with the device configuration ledger block; and disabling operation of the device in response to determining that the current distributed ledger block does not match the device configuration ledger block.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to pending U.S. non-provisional patent application Ser. No. 16 / 176,365, filed on Oct. 31, 2018, entitled “MONITORING DEVICE COMPONENTS USING A DISTRIBUTED LEDGE,” the contents of which are specifically incorporated herein by reference for its disclosure and teachings in their entirety. Background Art

[0003] It is difficult to verify various information about device components. For example, a given storage device may be manufactured using a given configuration of components or resources, such as a power supply, various storage drivers, bus components, etc. The specific components used in a storage device and their specific configuration are often very important to the proper operation of a given storage device, its functionality, and various guarantees related to device performance. Therefore, it is very useful to know if and when any user or third party changes the configuration or replaces one or more of the components of a storage device. Summary of the invention

[0004] This Summary is provided to introduce a selection of concepts that are further described below in the Detailed Description in a simplified form. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Other features, details, utilities, and advantages of the claimed subject matter will become apparent from the following more specific written detailed description of various implementations as further illustrated in the accompanying drawings and defined in the appended claims.

[0005] In at least one implementation, the technology disclosed herein provides a method of controlling resources used in a device. One implementation of such a method includes: generating a device configuration ledger block based on an initial assembly of components of a storage device; storing the device configuration ledger block on a node of a distributed ledger; detecting activation of the device; in response to detecting the activation of the device, generating a current distributed ledger block based on a current assembly of components of the storage device; comparing the current distributed ledger block with the device configuration ledger block; and disabling operation of the device in response to determining that the current distributed ledger block does not match the device configuration ledger block.

[0006] These and various other features and advantages will be apparent from a reading of the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] A further understanding of the nature and advantages of the present technology may be achieved by reference to the accompanying drawings described in the remainder of the specification. In the accompanying drawings, similar reference numerals are used to refer to similar components in several figures. In some instances, a reference numeral may have an associated sub-label consisting of lowercase letters to indicate one of multiple similar components. When reference is made to a reference numeral without a designated sub-label, the reference is intended to refer to all such multiple similar components.

[0008] Figure 1 An example block diagram of an equipment component monitoring system using an example distributed ledger is shown.

[0009] Figure 2 A block diagram of an example hash value transaction recorded to an example distributed ledger is shown.

[0010] Figure 3 An example flow chart illustrating components for configuring a distributed ledger annotation to monitor a device during a manufacturing phase is shown.

[0011] Figure 4 An alternative example flow diagram illustrating use of a distributed ledger to ensure device configuration in response to device activation is shown.

[0012] Figure 5 Another alternative example flow chart illustrating the use of a distributed ledger to secure device configurations in response to changes in device configurations is shown.

[0013] Figure 6 A further alternative example flow diagram illustrating use of a distributed ledger to ensure device configuration in response to a component being removed from the device is shown.

[0014] Figure 7 An example processing system is shown that can be used to implement the described techniques. DETAILED DESCRIPTION

[0015] The implementation described herein provides a system for monitoring trusted components of a device using a distributed ledger. In one implementation, the device component monitoring system disclosed herein provides a method for controlling resources used in a large storage system by using a distributed ledger and secure binding technology to prevent counterfeiting and gray market activities.

[0016] In one implementation, the hash generator is configured to automatically generate a hash based on a configuration of the components of the device including a list of the device components and various attributes of the device components. Specifically, in one implementation, a hash generator in a device generates a hash based on a configuration of the device components when the device is manufactured. For example, such a device may be a storage device such as a disk drive or a collection of disk drives. The hash may also include other device metadata including the time when the hash was generated, identification of all components or parts of the device such as a motherboard, a drive, a memory, a power supply, a communication bus, one or more microprocessors, etc.

[0017] For example, during the manufacture and initial provisioning of a device (such as a storage system), a hash may be generated based on information about all components of the storage system. Subsequently, a distributed ledger node may be generated based on the hash and digital signature of the storage system. Such a distributed ledger node may be stored on a distributed ledger. In one implementation, a copy of the distributed ledger may be stored in a memory of the storage system. Alternatively, the distributed ledger may be stored on a network (such as the Internet) that other third parties may access for independent verification.

[0018] An example of a distributed ledger is a blockchain. Specifically, a blockchain is a decentralized and distributed digital ledger that is used to record transactions across multiple computers so that the record cannot be altered retroactively without changing all subsequent blocks and colluding with the network. This allows participants to verify and audit transactions at a low cost. Thus, a distributed ledger provides rich documentation and authentication of various properties of components of a device.

[0019] Figure 1 An example block diagram 100 of a system for monitoring the configuration and component registry of a storage device 110 using an example distributed ledger 102 is shown. Specifically, Figure 1 A block diagram 100 of a storage device 110 is shown that generates a device hash and stores the device hash using a distributed ledger 102. The distributed ledger 102 is used to ensure the integrity of the configuration and components of the storage device 110. The distributed ledger 102 stores an immutable history of the storage device 110 configuration and component registry.

[0020] The distributed ledger 102 records various transactions related to the configuration of the storage device 110 when it is manufactured and at various other stages during the use of the storage device 110. Figure 1In the embodiment of the present invention, the distributed ledger 102 is a blockchain, but it should be understood that the distributed ledger 102 can be configured in different formats, such as a directed acyclic graph, a transaction chain, etc. In the illustrated implementation, the distributed ledger 102 includes a plurality of blocks, which include a plurality of verified transactions related to the storage device 110, each of which can represent the activation of the storage device 110, the change of the configuration of the storage device 110, the removal and / or change of a component of the storage device 110, etc. Block N 104 includes transactions 1 to N, and block N+1 106 includes transactions 1 to N. Blocks (e.g., block N 104 and block N+1 106) can include other data and metadata, such as a previous hash, a nonce, a Merkle root, a date, a time node software version, etc.

[0021] The distributed ledger 102 is supported by a number of different "nodes." A node is a computer system that executes processor-executable instructions for supporting the distributed ledger 102. In some example implementations, the nodes may be implemented in various types. For example, a full ledger node is a node that stores a substantially complete copy of the distributed ledger 102. A validating node is a node that can verify and approve transactions and / or blocks for inclusion in the distributed ledger 102. A contributor node is a node that contributes transactions for verification on the distributed ledger 102. A consumer node is a node that can consume and verify transactions on the distributed ledger 102. It should be understood that other types of nodes are contemplated.

[0022] The distributed ledger 102 can be implemented as a private (permissioned) ledger, a hybrid private / public ledger, or a fully public ledger. A private ledger is a ledger in which each node supporting the ledger is authenticated or authorized to use the ledger. In addition, a private ledger may not be publicly visible or accessible by some nodes or external parties. In a public distributed ledger, the complete distributed ledger 102 is publicly distributed to many nodes and is accessible by all nodes in the network. Each node supporting the ledger includes a cryptographic identity, which may include a public / private key pair.

[0023] Different types of storage device transactions may be transmitted to the distributed ledger 102, approved by the distributed ledger 102, and stored in the distributed ledger 102. The storage device transaction includes information proving the authenticity and integrity of the configuration of the storage device 110 and the registry of the components of the storage device 110. The storage device transaction sent to the distributed ledger 102 may include information such as how the components are configured on the motherboard of the storage device 110, identification numbers of various components of the storage device 100, digital certificates (e.g., keys), etc.

[0024] exist Figure 1, the storage device 110 includes a device clock 112 that generates a clock timestamp that can be stored as part of a hash by the hash generator 112 along with other information about the configuration of the storage device 110. The storage medium 114 can be used to store various data, including the device configuration 120, the component registry 122, etc. In one implementation, the storage medium 114 can be a magnetic medium, such as a conventional media recording (CMR) disk drive, a shingled media recording (SMR) disk drive, etc. In one implementation, a copy of the distributed ledger 102 can be stored as a distributed ledger 102a.

[0025] The storage device 110 also includes device identification information 124 that stores identification information about the storage device 110, such as a serial number of the storage device 110, a network identification number of the storage device 110, information identifying the owner of the storage device 110, etc. Alternatively, the device identification information 124 also stores an Internet Protocol (IP) address of the storage device 110, a Media Access Control (MAC) address of the storage device 110, a Service Set Identifier (SSID) of the storage device 110, an International Mobile Equipment Identity (IMEI) of the storage device 110, a Software Element Identification (SEID) of the storage device 110, etc. In one implementation, such device identification information 124 may be used together with the device configuration 120, the component registry 122, the digital signature 118, etc. of the storage device 110 to generate a hash value stored on a node of the distributed ledger 102.

[0026] The storage device 110 also includes a hash generator 116 that is configured to generate a hash of a combination of the device configuration 120 and the component registry 122, as well as various other information, when the storage device 110 is manufactured. The hash generator 116 may be implemented as processor-executable instructions stored in a memory of a computing machine (e.g., the storage device 110 includes a memory storing instructions for the hash generator 116), and executed by a processor located on the storage device 110. The device configuration 120 may include a schematic diagram of the storage device 110, and the component registry 122 may include a registry of storage components of the storage device 110, the registry including identification information for each of the components, such as a power supply, one or more random access memories (RAMs), a communication bus, etc. of the storage device 110.

[0027] The hash generator 116 may use a hash function to generate hash values ​​(also referred to as hash codes) of the device configuration 120 and the component registry 122. In one implementation, the hash function used by the hash generator 116 may be a cryptographic hash function that allows one to easily verify that given input data maps to a given hash value. Thus, the hash value generated by the hash generator 116 may be mapped to a specific combination of the device configuration 120 and the component registry 122. However, in this case, if the input value of the combination of the device configuration 120 and the component registry 122 is unknown, the user cannot reconstruct the input value by knowing the hash value output by the hash generator 116. Alternatively, the hash function may be collision-resistant because a hash value generated by such a hash function may not be generated by any input data other than the combination of the device configuration 120 and the component registry 122 used to generate the hash value.

[0028] In one implementation, the device configuration 120 also includes a bill of materials (BOM) from the manufacturing plant or manufacturing entity that manufactured the device 100. In addition, since the device 100 is being manufactured, the hash generator 116 may not have the ability to generate hash values, and therefore, the initial hash value used on the blockchain node can be generated by an external processor at the manufacturing facility, and when the device 100 is shipped, the distributed ledger blocks generated using such externally generated hashes can be stored on the storage medium 114. In addition, in one implementation, newly generated blocks can also be added to the distributed ledger 114 in response to one or more critical or catastrophic events affecting the device 100, such as device failures, etc.

[0029] In an alternative implementation, the media generator 116 generates the hash value using a combination of values ​​received from various other components of the storage device 110, including a combination of the device configuration 120 and the component registry 122. Thus, for example, the hash generator 116 generates the hash value using a GPS location received from the GPS module 120, a timestamp received from the clock 122, and a combination of the device configuration 120 and the component registry 122.

[0030] The hash generator 116 communicates with the transmitter 126 to transmit the hash value to the distributed ledger 102. In one implementation, the hash generator 116 transmits the hash value as it is generated. Alternatively, the hash generator 116 may accumulate a predetermined number of hash values ​​and transmit the accumulated chunks of hash values ​​to the distributed ledger 102 at predetermined time intervals. If the hash generator 116 is configured to generate a header using various parameters of the storage device 110 associated with a combination of the device configuration 120 and the component registry 122, such a header is also transmitted to the distributed ledger 102 along with the hash value.

[0031] The distributed ledger 102 stores the hash value and / or the associated header value as a transaction on a block 104, 106 of the distributed ledger 102. In an implementation, the transaction 104a, 104b, 104n is signed by a private key of a ledger node of the storage device 110. Other nodes supporting the distributed ledger 102 may verify the transaction based on a public key associated with the private key of the storage device 110. Alternatively, the transaction 104a, 104b, 104n may also include a public key associated with the private key of the storage device 110.

[0032] Since the hash value of the combination of the device configuration 120 and the component registry 122 is recorded in the distributed ledger, a third party can verify the authenticity of the combination of the device configuration 120 and the component registry 122 using the public key associated with the private key of the storage device 110. Therefore, during the life of the storage device, the current value of the combination of the device configuration 120 and the component registry 122 can be used to generate a hash value and compared with the hash value of such combination generated when the storage device 110 was manufactured or supplied. If such current hash does not match the original hash, it can be determined that a change has occurred in at least one of the device configuration 120 and the component registry 122.

[0033] Figure 2 A block diagram 200 of an example hash value transaction recorded to an example distributed ledger is shown. The block diagram 200 includes a storage device 202 executing a ledger node 204. The storage device 202 is shown as executing the storage node itself using a processor 220 located on the storage device 202. Alternatively, a host connected to and separate from the storage device 202 can also be used to execute the ledger node 204.

[0034] The ledger node 204 may be implemented as processor-executable instructions stored in a memory of the storage device 202 (e.g., the storage device 202 includes a memory storing instructions for the ledger node 204) and executed by the processor 220 of the storage device 202. The ledger node 204 is configured to consume transactions from the distributed ledger 310 and transmit transactions to the distributed ledger 210. In some example implementations, the ledger node 204 verifies transactions on the distributed ledger 210. In addition, in some example implementations, the ledger node 204 verifies and approves transactions and / or blocks for inclusion in the distributed ledger 210. In addition, in some example implementations, the ledger node 204 stores a complete or substantially complete copy of the distributed ledger 210. The ledger node 204 is communicatively connected to the distributed ledger 210 (e.g., other nodes of the ledger) via a communication network (not shown). The communication network may include a wired and / or wireless network and include various communication network components for facilitating communications and transactions between nodes and devices.

[0035] exist Figure 2 , the ledger node 204 of the storage device 202 is transmitting a transaction 206 (hereinafter referred to as "device configuration transaction 206") to the distributed ledger 210. The device configuration transaction 206 includes, for example, but is not limited to, a storage device identification (e.g., a serial number or key), configuration information about the storage device, a component registry of the storage device, and other metadata. The storage device identification can be the serial number of the storage device 202. The storage device identification can also include a public key component of a public-private key pair associated with the identity of the storage device 202 or the ledger node 204.

[0036] The device configuration transaction 206 further includes a digital signature 208 that signs the device configuration transaction 206. In some example implementations, the device configuration transaction 206 is signed by a private key of the transaction initiator (e.g., the ledger node 204 of the storage device 202). As such, the digital signature 208 is used to verify that the device configuration hash is transmitted from an authorized entity (e.g., based on a public key associated with the private key).

[0037] By ledger node 204 and Figure 2 The distributed ledger 210 supported by other nodes not depicted in the diagram includes multiple blocks, each block having multiple transactions. The distributed ledger 210 includes block N-1 212 and block N-2 214. Block N-1 214 is the block that was most recently added to the distributed ledger 210. In other words, block N-1 214 is the most recently verified and approved for the distributed ledger 210. Since each subsequent block includes a hash of the previous block, the blocks are "chained". For example, block N-1 214 includes a hash of the previous block (block N-2 212), etc. Block N 216 is the next block in the distributed ledger 210. Block N has not yet been verified. If approved / verified, the device configuration hash transaction 206 can be included in block N once it is included in the distributed ledger 210.

[0038] Figure 3 Example operations 300 are shown for storing a device configuration hash on a distributed ledger using the example distributed ledger described herein. A storage device such as Figure 1 The processor on the storage device 110 shown in FIG. 1 implements one or more of operations 300. Operation 302 determines the provision of a new storage device. For example, when the device is manufactured, a signal may be sent to the processor to notify the storage device of the initiation of a hash transaction. If so, operation 304 activates a hash generator. The hash generator may be software-implemented or firmware-implemented. For example, a hash generator (such as Figure 1 The hash generator 116 disclosed in ).

[0039] Operation 308 receives the location of the storage. For example, operation 308 may receive the configuration of the storage device for which the device configuration hash is to be generated. Operation 310 may receive a component registry of the storage device. Such a component registry may include a list of all components of the storage device, their configuration on the motherboard of the storage device, and their identification. Operation 312 receives other storage device metadata, for example, the storage device metadata may include a serial number, a network identification, an IP address, an IMEI, and a SEID, a SSID, a MAC address, etc., and other metadata of the storage device.

[0040] Operation 316 generates a hash value for the medium stored on the storage medium. In one implementation, operation 316 generates the hash value using one or more of the device configuration, device component registry, and other storage device metadata. In one implementation, operation 316 may use a cryptographic hash function that allows one to easily verify that given input data maps to a given hash value. Alternatively, operation 316 may use a collision-resistant hash function.

[0041] In one implementation, operation 316 uses the information received at one or more of receiving operations 308-312 in generating a hash value. Alternatively, the information received at one or more of receiving operations 308-314 can be used to generate a header separate from the hash value. Operation 318 encrypts the hash value and / or a combination of the hash value and the header. The encrypted output of operation 318 is transmitted to the distributed ledger at operation 320. Operation 322 receives a timestamp when the encrypted output of operation 318 is received at the distributed ledger. Subsequently, operation 324 records information about the hash generation and transmission activities, and the blocks on the distributed ledger where the hash value can be stored, and the timestamp when the encrypted output of operation 318 is received at the distributed ledger. Recording the timestamp when the hash value and metadata about the storage device configuration allow independent verification of the storage device configuration and the component registry when the storage device is manufactured.

[0042] Figure 4 An alternative example flow chart 400 is shown that illustrates the use of a distributed ledger to ensure device configuration in response to device activation. One or more of these operations can be implemented on a storage device. Operation 404 determines whether the device has been activated. For example, whenever the storage device is turned on, a signal can be transmitted to a module in the storage device to notify it of device activation. In response to determining that the storage device has been activated, operation 406 generates a current device configuration and a device component registry. Operation 408 generates an activation hash based on the current device configuration and the device component registry. In one implementation, other metadata may also be used. Specifically, the other metadata is similar to the metadata used when generating a device configuration hash when manufacturing the storage device.

[0043] Operation 410 then transmits the activation hash to a distributed ledger such as Figure 1 414. The method of claim 413 is to store an activation hash on a storage device and / or a device configuration hash on a distributed ledger 102 disclosed in the disclosure. In one implementation, such a ledger node may be stored on a medium on a storage device, and as a result, an activation hash may be transmitted to a processor on the storage device, which may compare the activation hash with a device configuration hash. Alternatively, if the ledger node storing the device configuration hash is stored on a remote server, the storage device may transmit the activation hash to such a remote server. Operation 412 compares the activation hash with the device configuration hash. If it is determined at operation 414 that the activation hash matches the device configuration hash, operation 416 registers the state of the device, and the device may operate normally after the registration. If the activation hash does not match the device configuration hash, operation 418 deactivates the storage device, and then operation 420 notifies the manufacturer of the device about potential changes in the device configuration and / or device components.

[0044] Figure 5 Another alternative example flow chart 500 is shown that illustrates the use of a distributed ledger to ensure device configuration in response to a change in device configuration. One or more of these operations can be implemented on a storage device. Operation 504 determines whether the device configuration has changed. For example, whenever any change is made to the configuration of the storage device (such as adding a new storage drive, removing a component, etc.), a signal can be transmitted to a module in the storage device to notify it of the device configuration change. In one implementation, the device configuration change can be the result of a periodic audit routine performed at the device. For example, periodically, an audit module of the storage device can perform an audit of the storage device configuration to determine whether there are any changes.

[0045] In response to determining that the storage device configuration may have changed, operation 506 generates a current device configuration and a device component registry. Operation 508 generates a current configuration hash based on the current device configuration and the device component registry. Subsequently, operation 510 transmits the current configuration hash to a distributed ledger (such as Figure 1 In one implementation, such a ledger node may be stored on a medium on a storage device, and as a result, the activation hash may be transmitted to a processor on the storage device, which may compare the current configuration hash with the device configuration hash. Alternatively, if the ledger node storing the device configuration hash is stored on a remote server, the storage device may transmit the activation hash to such remote server.

[0046] Operation 512 compares the current communication hash to the device configuration hash. If at determination operation 514 there is a match between the current communication hash and the device configuration hash, operation 516 registers the state of the device, and the device may operate normally after the registration. If the current communication hash does not match the device configuration hash, operation 518 deactivates the storage device, and then operation 520 notifies the manufacturer of the device about potential changes in the device configuration and / or device components.

[0047] Figure 6 A further alternative example flow chart 600 is shown that illustrates the use of a distributed ledger to ensure device configuration in response to a component being removed from the device. One or more of these operations may be implemented on a storage device. Operation 604 determines whether any component has been removed. For example, whenever there is any removal of a component, etc., a signal may be transmitted to a module in the storage device to notify it of the component removal. In one implementation, component removal detection may be the result of a periodic audit routine performed at the device. For example, periodically, an audit module of the storage device may perform an audit of the storage device components. Alternatively, such an audit may be performed each time the device is activated or when the device is in idle mode.

[0048] In response to determining that the storage device configuration may have changed, operation 606 generates a current device configuration and a device component registry. Operation 508 generates a device component registry hash based on the current device configuration and the device component registry. Subsequently, operation 610 transmits the device component registry hash to a distributed ledger (such as Figure 1 A ledger node on the distributed ledger 102 disclosed in .

[0049] Operation 612 compares the device component registry hash to the device configuration hash. If there is a match between the device component registry hash and the device configuration hash at the determination operation 614, operation 616 registers the state of the device, and the device can operate normally after the registration. If the device component registry hash does not match the device configuration hash, operation 618 deactivates the storage device, and then operation 620 notifies the manufacturer of the device about the potential change in the device configuration and / or device components. In one implementation, operation 622 determines whether the device is allowed to operate with the components removed. If so, operation 630 reactivates the device to operate in its current state.

[0050] Figure 7An example processing system 700 is shown that can be used to implement the described techniques. The processing system 700 is capable of executing a computer program product embodied in a tangible computer-readable storage medium to perform a computer process. Data and program files can be input to the processing system 700, which uses one or more processors (CPU or GPU) to read the files and execute the programs therein. Some of the elements of the processing system 700 are described in detail in the accompanying drawings. Figure 7 , where a processor 702 is shown as having an input / output (I / O) portion 704, a central processing unit (CPU) 706, and a memory portion 708. There may be one or more processors 702, such that the processor 702 of the processing system 700 includes a single central processing unit 706 or multiple processing units. The processor may be a single core or multi-core processor. The processing system 700 may be a conventional computer, a distributed computer, or any other type of computer. The described techniques are optionally implemented in software loaded into the memory 708, the storage unit 712, and / or communicated via a wired or wireless network link 714 on a carrier signal (e.g., Ethernet, 3G wireless, 8G wireless, LTE (Long Term Evolution)), thereby Figure 7 The processing system 700 in the example embodiment is converted into a dedicated machine for implementing the described operations. The processing system 700 may be a dedicated processing system configured to support a distributed ledger. In other words, the processing system 700 may be a ledger node.

[0051] The I / O portion 704 may be connected to one or more user interface devices (e.g., a keyboard, a touch screen display unit 718, etc.) or a storage unit 712. A computer program product containing mechanisms for implementing systems and methods according to the described techniques may reside in the memory portion 708 or on the storage unit 712 of such system 700.

[0052] The communication interface 724 is capable of connecting the processing system 700 to an enterprise network via a network link 714, through which the computer system can receive instructions and data embodied in a carrier wave. When used in a local area network (LAN) environment, the processing system 700 is connected to the local network (either by wired connection or wirelessly) through the communication interface 724, which is a type of communication device. When used in a wide area network (WAN) environment, the processing system 700 typically includes a modem, a network adapter, or any other type of communication device for establishing communications over the wide area network. In a networked environment, program modules described relative to the processing system 700 or portions thereof may be stored in a remote memory storage device. It should be understood that the network connections shown are examples of communication devices and other means for establishing communication links between computers.

[0053] In an example implementation, user interface software modules, communication interfaces, input / output interface modules, account nodes, and other modules may be implemented by instructions stored in memory 708 and / or storage unit 712 and executed by processor 702. In addition, local computing systems, remote data sources and / or services, and other related logics represent firmware, hardware, and / or software that may be configured to help support distributed ledgers. Account node systems may be implemented using general-purpose computers and special-purpose software (such as servers that execute service software), special-purpose computing systems and special-purpose software (such as mobile devices or network devices that execute service software), or other computing configurations. In addition, keys, device information, identification, configurations, and the like may be stored in memory 708 and / or storage unit 712 and executed by processor 702.

[0054] The processing system 700 may be implemented in a device such as a user device, a storage device, an IoT device, a desktop device, a laptop device, a computing device, etc. The processing system 700 may be a ledger node executed in the user device or external to the user device.

[0055] Data storage and / or memory may be embodied by various types of processor-readable storage media, such as hard disk media, storage arrays containing multiple storage devices, optical media, solid-state drive technology, ROM, RAM, and other technologies. Operations may be implemented by processor-executable instructions in firmware, software, hard-wired circuits, gate array technology, and other technologies, whether performed or assisted by a microprocessor, microprocessor core, microcontroller, dedicated circuit, or other processing technology. It should be understood that the write controller, storage controller, data writing circuit, data reading and recovery circuit, sorting module, and other functional modules of the data storage system may include a processor for processing processor-readable instructions for executing the processes implemented by the system, or work in conjunction with a processor.

[0056] For the purposes of this specification and claims, the term "memory" refers to tangible data storage devices, including non-volatile memory (such as flash memory, etc.) and volatile memory (such as dynamic random access memory, etc.). Computer instructions and other information (such as data, virtual mapping, operating system, application, etc.) accessed by the computer processor to perform the required functions reside permanently or temporarily in the memory. The term "memory" explicitly does not include transient media (such as carrier signals), but computer instructions can be transmitted to the memory wirelessly.

[0057] In contrast to tangible computer-readable storage media, intangible computer-readable communication signals may embody computer-readable instructions, data structures, program modules, or other data residing in a modulated data signal such as a carrier wave or other signal transmission mechanism. The term "modulated data signal" refers to a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, intangible communication signals include: wired media such as a wired network or direct-wired connection; and wireless media such as acoustic, RF, infrared and other wireless media.

[0058] Embodiments of the invention described herein are implemented as logical steps in one or more computer systems. The logical operations of the present invention are implemented as (1) a sequence of steps implemented as a processor executed in one or more computer systems, and (2) as machine or circuit modules interconnected in one or more computer systems. Implementation is a choice, depending on the performance requirements of the computer system implementing the present invention. Therefore, the logical operations that constitute the embodiments of the invention described herein are variously referred to as operations, steps, objects, or modules. In addition, it should be understood that the logical operations can be performed in any order unless otherwise expressly required or the claim language inherently requires a specific order.

[0059] The above description, examples and data provide a complete description of the structure and use of the example embodiments of the disclosed technology. Since many embodiments of the disclosed technology can be made without departing from the spirit and scope of the disclosed technology, the disclosed technology lies in the claims attached below. In addition, the structural features of different embodiments can be combined in another embodiment without departing from the recited claims.

Claims

1. A method comprising: Generating a device configuration ledger block based on an initial assembly of components of the storage device; Storing the device configuration ledger block on a node of a distributed ledger; detecting activation of the device; In response to detecting the activation of the device, generating a current distributed ledger block based on a current assembly of components of the storage device; Comparing the current distributed ledger block with the device configuration ledger block; as well as Disabling operation of the device in response to determining that the current distributed ledger block does not match the device configuration ledger block.

2. The method according to claim 1, characterized in that Comparing the current distributed ledger block to the device configuration ledger block further includes comparing a device configuration hash based on the initial assembly of components of the storage device to a current hash based on the current assembly of components of the storage device.

3. The method of claim 2, further comprising: The device configuration hash is generated based on the initial assembled configuration of components of the storage device and an initial component registration table of the storage device.

4. The method of claim 2, further comprising: The current hash is generated based on an assembled current configuration of components of the storage device and a current component registration table of the storage device.

5. The method of claim 1, further comprising: The device configuration ledger block is stored on the storage device.

6. The method of claim 1, further comprising: In response to determining that the current distributed ledger block does not match the device configuration ledger block, a review of the device configuration is initiated.

7. The method of claim 1, further comprising: The device is deactivated in response to determining that the current distributed ledger block does not match the device configuration ledger block.

8. The method of claim 1, further comprising: detecting removal of a component of the storage device; as well as In response to detecting the removal of the component of the storage device, a new current hash is generated based on a configuration and a registry of the component of the storage device.

9. The method of claim 1, further comprising: performing an audit of a current configuration of a component of the storage device in response to a predetermined event; as well as A current hash is generated based on the configuration and registry of the components of the storage device resulting from the audit.

10. The method according to claim 9, characterized in that The predetermined event is an indication of gray market activity for components of the storage device.

11. One or more processor-readable storage media encoding processor-executable instructions for executing a computer process on a computer system, the computer process comprising: Generating a device configuration ledger block based on an initial assembly of components of the storage device; Storing the device configuration ledger block on a node of a distributed ledger; detecting activation of the device; In response to detecting the activation of the device, generating a current distributed ledger block based on a current assembly of components of the storage device; as well as Comparing the current distributed ledger block with the device configuration ledger block; as well as Disabling operation of the device in response to determining that the current distributed ledger block does not match the device configuration ledger block.

12. One or more processor-readable storage media as claimed in claim 11, characterized in that: Comparing the current distributed ledger block to the device configuration ledger block further includes comparing a device configuration hash based on the initial assembly of components of the storage device to a current hash based on the current assembly of components of the storage device.

13. One or more processor-readable storage media as recited in claim 12, wherein: The computer process further includes generating the current hash based on a current configuration of the assembly of components of the storage device and a current component registration table of the storage device.

14. The one or more processor-readable storage media of claim 12, wherein: The computer process further includes generating the device configuration hash based on the initial assembled configuration of components of the storage device and an initial component registration table of the storage device.

15. The one or more processor-readable storage media of claim 11, wherein: The computer process further includes storing the device configuration ledger block on the storage device.

16. The one or more processor-readable storage media of claim 11, wherein: The computer process further comprises: The device is deactivated in response to determining that the current distributed ledger block does not match the device configuration ledger block.

17. The one or more processor-readable storage media of claim 11, wherein: The computer process further comprises: In response to determining that the current distributed ledger block does not match the device configuration ledger block, a review of device provisioning is initiated.

18. A system comprising: one or more processors; Memory; as well as A ledger node, the ledger node being stored in the memory and executable by the one or more processors to support a distributed ledger, the ledger node being configured to: Generating a device configuration ledger block based on an initial assembly of components of the storage device; Storing the device configuration ledger block on a node of the distributed ledger; detecting activation of the device; In response to detecting the activation of the device, generating a current distributed ledger block based on a current assembly of components of the storage device; as well as Comparing the current distributed ledger block with the device configuration ledger block; as well as Disabling operation of the device in response to determining that the current distributed ledger block does not match the device configuration ledger block.

19. The system of claim 18, wherein: The ledger node is further configured to compare the current distributed ledger block with the device configuration ledger block by comparing a master hash value based on an initial assembly of components of the storage device with a current hash value based on the current assembly of components of the storage device.

20. The system of claim 18, wherein: The ledger node is further configured to: In response to determining that the current distributed ledger block does not match the device configuration ledger block, a review of device provisioning is initiated.

Images