System and method for cleaning data in memory

Abstract

This invention provides a system and method for clearing data in memory. A non-transitory computer-readable medium stores instructions that, when executed by a processor, cause the processor to: receive a command to perform memory clearing; retrieve code for a clearing firmware package from non-volatile memory; store the code in volatile memory; execute the code from the volatile memory, thereby causing the processor to clear the non-volatile memory; and cyclically power an industrial automation component, wherein cyclically powering the component includes clearing the volatile memory.

Description

Technical Field

[0001] This disclosure generally relates to industrial automation components that have memory. More specifically, this disclosure relates to cleaning up the memory of industrial automation components so that the industrial automation components can be reused. Background Technology

[0002] Industrial automation systems can be used for the automatic control of one or more actuators. Specifically, a controller can receive power from a power source and output regulated electrical signals to the actuators to control their movement. One or more components of an industrial automation system may be equipped with memory. Some entities (e.g., governments, military, government / military contractors, private sector companies, etc.) may implement strategies for reusing equipment containing memory because sensitive data may be stored in and recoverable from the memory. Therefore, many such entities damage equipment with memory when it is no longer used in the application and purchase new equipment for new applications instead of reusing previously used equipment. This can be costly, resource- and material-intensive, and generates more electronic waste. Therefore, it may be desirable to develop technologies for cleaning up the memory of equipment so that the equipment can be reused without the risk that previously stored data can be recovered.

[0003] This section is intended to introduce the reader to various aspects of the technology that may be related to the various aspects of this disclosure described below and / or claimed. It is believed that this discussion will help provide the reader with background information to better understand the various aspects of this disclosure. Therefore, it should be understood that these statements are to be understood in this context and not as an admission of prior art. Summary of the Invention

[0004] The following provides an overview of the specific embodiments disclosed herein. It should be understood that these aspects are presented only to provide the reader with a brief overview of these specific embodiments, and are not intended to limit the scope of this disclosure. In fact, this disclosure may cover several aspects that may not be set forth below.

[0005] In one implementation, the industrial automation component includes a processor, volatile memory, and non-volatile memory. The non-volatile memory is accessible to the processor and stores instructions that, when executed by the processor, cause the processor to: receive a command to perform memory cleanup; retrieve code for a cleanup firmware package from the non-volatile memory; store the code in the volatile memory; execute the code from the volatile memory, thereby causing the processor to clean up the non-volatile memory; and cyclically power the industrial automation component, wherein cyclically powering the component includes cleaning up the volatile memory.

[0006] In another embodiment, the industrial automation component includes a processor, volatile memory, and non-volatile memory. The non-volatile memory is accessible to the processor and stores instructions that, when executed by the processor, cause the processor to: receive a command from a device communicatively coupled to the industrial automation component via a network for performing memory cleanup; store code for a cleanup firmware package in the volatile memory; execute code from the volatile memory, thereby causing the processor to clean up the non-volatile memory; and cyclically power the industrial automation component, wherein cyclically powering the component includes cleaning up the volatile memory.

[0007] In another embodiment, a method for cleaning up the non-volatile memory of an industrial automation component includes: retrieving code for cleaning up a firmware package from the non-volatile memory; storing the code in volatile memory; executing the code from the volatile memory, thereby causing a processor to clean up the non-volatile memory; and cyclically powering the industrial automation component, wherein cyclically powering up includes cleaning up the volatile memory.

[0008] Various modifications to the features described above may exist regarding the various aspects of this disclosure. Other features may also be incorporated into these aspects. These modifications and additional features may exist individually or in any combination. For example, the various features discussed below with respect to one or more of the illustrated embodiments may be incorporated individually or in any combination into any of the foregoing aspects of this disclosure. The brief overview presented above is intended only to familiarize the reader with certain aspects and context of embodiments of this disclosure and is not limited to the claimed subject matter. Attached Figure Description

[0009] These and other features, aspects, and advantages of the embodiments will be better understood when the following detailed description is read with reference to the accompanying drawings, in which the same characters denote the same parts throughout the drawings:

[0010] Figure 1 A schematic diagram of an industrial automation system including a controller, a computing device, and a remote server, according to an embodiment presented herein, is shown.

[0011] Figure 2 The embodiments presented herein are shown as being usable Figure 1 A block diagram of example components of the controller, computing device, and / or remote server;

[0012] Figure 3 The embodiments presented herein are illustrated for directing... Figure 1 A schematic diagram of a system in which the controller provides software and / or firmware updates;

[0013] Figure 4 This disclosure illustrates various aspects of the disclosure. Figure 4A swimlane diagram of communication between devices (e.g., controllers and / or computing devices) and remote servers;

[0014] Figure 5 The present disclosure illustrates various aspects of cleaning. Figure 4 A flowchart of the process of storing the device's memory;

[0015] Figures 6A to 6F This disclosure illustrates various aspects of the use of [the invention / method] in [the context of] [the invention / method]. Figure 5 The example pattern shown is rewriting addressable locations in non-volatile memory during cleanup;

[0016] Figure 7 This disclosure illustrates various aspects of cleaning up by executing locally stored firmware packages. Figure 3 A flowchart of the process of controlling or storing a computing device;

[0017] Figure 8 This disclosure illustrates aspects of remote cleaning. Figure 4 A flowchart of the process of storing the device's memory; and

[0018] Figure 9 The present disclosure illustrates various aspects of cleaning. Figure 4 The flowchart describes the process of cleaning up the device's memory and generating a cleanup report. Detailed Implementation

[0019] One or more specific implementations will be described below. To provide a concise description of these implementations, not all features of the actual implementations are described in the specification. It should be understood that in the development of any such actual implementation, as in any engineering or design project, many implementation-specific decisions must be made to achieve the developer's specific goals, such as complying with system-related and enterprise-related constraints, which may vary depending on the implementation. Furthermore, it should be understood that while such development efforts may be complex and time-consuming, they remain routine tasks of design, fabrication, and manufacturing for those skilled in the art who benefit from this disclosure.

[0020] When describing elements of various embodiments of the invention, the articles “a,” “an,” “the,” and “the” are intended to indicate the presence of one or more elements. The terms “comprising,” “including,” and “having” are intended to be inclusive and indicate that additional elements may be present besides those listed.

[0021] This disclosure includes techniques for cleaning up the memory of a device so that data previously stored in the memory cannot be recovered using various laboratory techniques, thereby allowing the device containing the memory to be reused for another application instead of being corrupted. Specifically, the memory can be cleaned up via a self-deleting firmware package. The firmware package can be stored in the device's non-volatile memory. The firmware package can be received from another device via a wired or wireless network connection, via removable media (e.g., SD card, USB drive, optical disc, etc.), or in any other suitable manner. The firmware package can be copied to the volatile memory and executed by a processor to perform the cleanup process. This can include, for example, rewriting some or all of the addressable locations of the memory multiple times using a specific sequence of 1 and 0 patterns, such that data stored in the memory prior to the start of the cleanup process cannot be recovered using various laboratory techniques.

[0022] In some implementations, when a firmware package is received from a different device, input for authorized memory cleanup can be provided. In some implementations, the entire non-volatile memory and volatile memory of the device can be cleaned up. In other implementations, a portion (e.g., less than all) of the non-volatile memory of the device used by a specific application with a sensitivity level above a threshold level can be cleaned up. After the non-volatile memory cleanup is complete, power is cyclically supplied to the device, thereby clearing the volatile memory. At this point, both the non-volatile memory and volatile memory of the device have been cleaned up.

[0023] With this in mind, in some implementations, the device can receive and execute a baseline software package and / or firmware package that returns the device to its original factory settings. In some implementations, the device can generate and display a hash value or some other visualization indicating that the device has been cleaned. In other implementations, the device can generate a report indicating that the device has been cleaned, and the report may include the generated hash value or other suitable representative visualization. The report may or may not be encrypted. If the report is encrypted, it can be encrypted using asymmetric encryption. That is, the report can be encrypted using a public key. In such an implementation, the client will use the provided private key to decrypt the report. However, in some implementations, the use of the public and private keys can be reversed, such that the report is encrypted using the private key and decrypted using the public key. The use of these techniques allows entities to clean the memory of devices containing storage, making data previously stored in the device's pre-cleaned memory unrecoverable using various laboratory techniques (e.g., live CDs, live digital video discs (DVDs), magnetic microscopy, reference recovery, cross-drive analysis, document engraving, etc.), allowing the device to be reused for new applications rather than being corrupted. The following will refer to Figures 1 to 9To provide additional details on cleaning the memory of various devices using the techniques described above.

[0024] Through the introduction, Figure 1 This is a schematic diagram of an example industrial automation system 10 that can implement the embodiments described herein. As shown, the industrial automation system 10 includes a controller 12 and actuators 14 (e.g., motors). The industrial automation system 10 may also include or be coupled to a power source 16. The power source 16 may include a generator, an external power grid, a battery, or some other power source. The controller 12 may be an independent control unit that controls multiple industrial automation components (e.g., multiple motors 14), a controller 12 that controls the operation of a single automation component (e.g., motor 14), or a sub-component within a larger industrial automation system 10. In this embodiment, the controller 12 includes a user interface 18 (e.g., a human-machine interface (HMI)) and a control system 20, which may include a memory 22 and a processor 24. The controller 12 may include a cabinet or other enclosure for housing various components of the industrial automation system 10 (e.g., motor starters, disconnect switches, etc.).

[0025] Control system 20 can be programmed (e.g., via computer-readable code or instructions stored on memory 22 and executable by processor 24) to provide signals for controlling motor 14. In some embodiments, control system 20 can be programmed according to a specific configuration required for a particular application. For example, control system 20 can be programmed to respond to external inputs, such as reference signals, alarms, command / status signals, etc. External inputs may originate from one or more relays or other electronic devices. Programming of control system 20 can be achieved through software configuration or firmware code that can be loaded onto internal memory 22 of control system 20 (e.g., via a locally or remotely located computing device 26) or programmed via user interface 18 of controller 12. The firmware of control system 20 can respond to a set of operating parameters. The setting of various operating parameters can determine the operating characteristics of controller 12. For example, various operating parameters can determine the speed or torque of motor 14, or can determine how controller 12 responds to various external inputs. In this way, operating parameters can be used to map control variables within controller 12 or to control other devices communicatively coupled to controller 12. These variables may include, for example, speed presets, feedback types and values, calculated gains and variables, algorithm adjustments, status and feedback variables, and programmable logic controller (PLC) control programming.

[0026] In some embodiments, the controller 12 may be communicatively coupled to one or more sensors 28 for detecting operating temperature, voltage, current, pressure, flow rate, and other measurable variables associated with the industrial automation system 10. Using feedback data from the sensors 28, the control system 20 can track in detail various conditions under which the industrial automation system 10 can operate. For example, the feedback data may include conditions such as actual motor speed, voltage, frequency, power quality, alarm conditions, etc. In some embodiments, the feedback data may be transmitted back to the computing device 26 for additional analysis.

[0027] The computing device 26 can be communicatively coupled to the controller 12 via a wired or wireless connection. The computing device 26 can receive input from a user using a native application running on the computing device 26 or a website accessible via a browser application, software application, etc., to define industrial automation projects. Users can define industrial automation projects by writing code, interacting with a visual programming interface, entering or selecting values ​​via a graphical user interface, or providing other inputs. The computing device 26 can send the project to the controller 12 for execution. Execution of the industrial automation project enables the controller 12 to control components (e.g., motor 14) within the industrial automation system 10 by performing one or more tasks and / or processes. In some applications, the controller 12 can be communicatively positioned behind a firewall, such that the controller 12 has no communication access outside the local network and does not communicate with any devices outside the firewall other than the computing device 26. As previously mentioned, the controller 12 can collect feedback data during project execution, and this feedback data can be provided back to the computing device 26 for analysis. Feedback data may include, for example, one or more execution times, one or more alarms, one or more error messages, one or more alarm conditions, one or more temperatures, one or more pressures, one or more flow rates, one or more motor speeds, one or more voltages, one or more frequencies, etc. The project can be updated via computing device 26 based on the analysis of the feedback data.

[0028] Computing device 26 can be communicatively coupled to cloud server 30 or a remote server via the Internet or some other network. In one embodiment, cloud server 30 is operated by the manufacturer of controller 12. However, in other embodiments, cloud server 30 can be operated by the vendor, service provider, operator, owner, etc. of controller 12. Cloud server 30 can be used to help customers create and / or modify projects, help resolve any problems that may arise with controller 12, or provide other services (e.g., project analysis, enabling, limiting the capabilities of controller 12, data analysis, controller firmware updates, etc.). Remote / cloud server 30 can be one or more servers operated by the manufacturer, vendor, service provider, operator, or owner of controller 12. Remote / cloud server 30 can be located at a facility owned and / or operated by the manufacturer, vendor, service provider, operator, or owner of controller 12. In other embodiments, remote / cloud server 30 can be located in a data center where the manufacturer, vendor, service provider, operator, or owner of controller 12 owns or leases server space. In other implementations, the remote / cloud server 30 may include multiple servers operating in one or more data centers to provide a cloud computing environment.

[0029] Figure 2 It shows what can be used as Figure 1 The diagram illustrates a block diagram of example components of computing device 100 within system 10, including computing device 26, cloud / remote server 30, controller 12, or some other device. As used herein, computing device 100 may be implemented as one or more computing systems, including laptop computers, notebook computers, desktop computers, tablet computers, HMIs or workstation computers, as well as server-type devices or portable communication devices, such as cellular phones and / or other suitable computing devices.

[0030] As shown in the figure, computing device 100 may include various hardware components, such as one or more processors 102, one or more buses 104, memory 106, input structure 112, power supply 114, network interface 116, user interface 118 and / or other computer components for performing the functions described herein.

[0031] In some implementations, one or more processors 102 may include microprocessors configured to execute instructions stored in memory 106 or other accessible locations. Alternatively, one or more processors 102 may be implemented as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and / or other devices designed to perform the functions discussed herein in a dedicated manner. It will be understood that multiple processors 102 or processing components may be used to perform the functions discussed herein in a distributed or parallel manner.

[0032] Memory 106 may include any tangible, non-transitory medium for storing data or executable routines. For example... Figure 2 As shown, memory 106 may include non-volatile memory 108 and volatile memory 110. Non-volatile memory 108 is static and can store data, program instructions, etc. Data stored in non-volatile memory 108 remains even when computing device 100 is powered off. Non-volatile memory 108 may include, for example, read-only memory (ROM), hard disk drive (HDD), flash memory including NAND flash and solid-state drive (SSD), floppy disk, optical disk, magnetic tape, etc. Volatile memory 110 can store data and program instructions used in real time by processor 102. Volatile memory 110 retrieves and stores data at high speed and is cleared when computing device 100 is powered off. Volatile memory 110 may include, for example, random access memory (RAM), including dynamic random access memory (DRAM) and static random access memory (SRAM); cache memory, etc. Although for convenience... Figure 2 While shown as a single block, memory 106 can be contained in various discrete media located in the same or different physical locations. One or more processors 102 can access the data in memory 106 via one or more buses 104.

[0033] Input structure 112 allows a user to input data and / or commands into device 100 and may include a mouse, touchpad, touchscreen, keyboard, controller, etc. Power supply 114 can be any suitable source for providing power to the various components of computing device 100, including line and battery power. In the depicted example, device 100 includes a network interface 116. Such a network interface 116 can allow communication with other devices on a network using one or more communication protocols. In the depicted example, device 100 includes a user interface 118, such as a display that can show images or data provided by one or more processors 102. User interface 118 may include, for example, a monitor, display, etc. It will be understood that, in a real-world context, a processor-based system (e.g., Figure 2 The computing device 100) implements some or all of the methods in this method, for example, executing Figure 1 The controller, computing device 26 and / or cloud / remote server 30 shown are functionalities including storage devices.

[0034] Return to Figure 1 Enterprises may wish to reuse controller 12, computing device 26, or any other component containing memory component 22 for different applications. For example, an enterprise may cease manufacturing products produced on a production line in which industrial automation system 10 is part. Therefore, an enterprise may wish to reuse industrial automation controller 12 or some other components within industrial automation system 10 in a new industrial automation system 10 that produces different products. However, if industrial automation controller 12 is used in government and / or military applications, in processes involving trade secrets, or otherwise stores information considered sensitive or confidential on memory 22, the enterprise may wish to sanitize memory 22 of industrial automation controller 12 so that sensitive or confidential information previously stored on memory 22 cannot be recovered. Similarly, if an enterprise wishes to transfer computing device 26 or any other device containing memory from one employee to another, from one facility to another, or otherwise return computing device to its factory settings for some new use or purpose, the enterprise may wish to sanitize the memory of computing device 26 so that information previously stored on memory 22 cannot be recovered. This type of media sanitization is defined by the "National Institute of Science and Technology (NIST) 800-88 Guidelines for Media Sanitization," published in December 2014. The NIST 800-88 guidelines outline three levels of media sanitization—wipe, clean, and damage—that reduce the likelihood of data recoverability.

[0035] For reference, media is considered erased when a layperson cannot recover data previously stored on memory. Erasure techniques may include rewriting the user-addressable storage space on the media with non-sensitive data using the device's standard read and write commands. Furthermore, media is considered cleaned when retrieving data previously stored on memory using various laboratory techniques is infeasible. Cleaning techniques may include rewriting, block erasure, cryptographic erasure, applying media-specific techniques to bypass abstract cleanup commands that bypass typical read / write commands, and techniques that render the media unusable, such as destruction, shredding, disintegration, degaussing, and pulverization. Additionally, when media is rendered unusable, it is considered damaged, and retrieving data previously stored on memory using various laboratory techniques is infeasible. Destruction techniques include disintegration, pulverization, melting, destruction, pulverization, etc.

[0036] Given the aforementioned problems, it is difficult to clean the memory of various devices so that previously stored data cannot be recovered using laboratory techniques without rendering the device unusable. Therefore, instead of cleaning the memory of devices used in government and / or military applications, in processes related to trade secrets, or otherwise storing information considered sensitive or classified, the focus is on devices that have been damaged after use in a single application. While such practices may have some advantages, they can be wasteful, costly, and resource-intensive. Therefore, the disclosed techniques involve using memory cleanup firmware packages according to NIST 800-88 guidelines to clean the memory of devices, while enabling the device to be restored to factory settings and reused for another application.

[0037] Considering the foregoing, Figure 3 A schematic diagram of a system 200 for providing firmware to one or more components of an industrial automation system 10 (e.g., industrial automation controller 12, computing device 26, etc.) is shown. As shown, the industrial automation system 10 is located within a private network 202, which may include Network Address Translation (NAT). A remote server 30 may be located in a public network 204 (e.g., the Internet). Devices within the public network 204 may not be able to access devices within the private network 202, but devices within the private network 202 may be able to access devices within the public network 204. Therefore, the computing device 26 can discover and establish a connection with the remote server 30. This may include, for example: sending a discovery request to the remote server 30; receiving location and trust certificates from the remote server 30; requesting policies and identities from the remote server 30; and receiving policies and identities from the remote server 30. The policy may define various activities performed by the computing device 26 or other devices within the industrial automation system 10, including the frequency of checks performed on firmware updates.

[0038] After a connection is established between the computing device 26 and the remote server 30, the computing device can periodically send firmware requests to and receive firmware from the remote server 30. In embodiments where the industrial automation system 10 includes components that cannot communicate with the remote server 30 or are prohibited from communicating outside the private network 202, the computing device 26 can distribute firmware to various devices within the industrial automation system 10 (e.g., the industrial automation controller 12). However, in some embodiments, the industrial automation controller 12 and / or other components of the industrial automation system 10 may be able to communicate directly with the remote server. Therefore, in such embodiments, the industrial automation controller 12 and / or other components of the industrial automation system 10 may undergo the process of establishing a connection with the remote server 30 and individually requesting and receiving firmware from the remote server 30. However, several embodiments are also contemplated in which a first subset of the components within the industrial automation system 10 communicates directly with the remote server 30 for firmware, while a second subset of the components within the industrial automation system 10 receives firmware from the remote server 30 via the computing device 26.

[0039] As will be described in more detail below, the remote server 30 can be used to provide a self-deleting memory cleanup firmware package to one or more devices (e.g., industrial automation controller 12) within the industrial automation system 10, clean up the device's memory and return the device to its factory settings when the above operations are performed.

[0040] Figure 4 This is swimlane diagram 300 illustrating firmware communication between device 302 and remote server 30 in industrial automation system 10. Device 302 can be any device including memory. For example, device 302 may include... Figure 1 The controller 12 shown or Figure 1 The computing device 26 is shown. Additionally, device 302 can be... Figure 1 Any other component of the industrial automation system 10 shown, or any other industrial automation system including a memory, such as a controller, motor starter, motor control center (MCC), server, desktop computer, laptop computer, tablet computer, mobile device, telephone, wearable device, HMI, input and / or output module, embedded computer, etc.

[0041] As shown in the figure, the private network 202 of the industrial automation system 10 may include a NAT 304, which can be used to store the Internet Protocol (IP) addresses used by the network. Specifically, NAT 304 connects the private network 202 to the public network 204 and translates the network addresses of devices within the private network 202 into legitimate IP addresses before packets are sent to a remote server 30 in the public network 204. Therefore, one or more, or all, devices in the private network 202 can share IP addresses. NAT 304 makes communication between the private network 202 and the public network 204 more secure because the addresses of devices within the private network 202 are hidden. Thus, when an output message passes through NAT 304, the address of device 302 is removed from the message and replaced with the IP address assigned to the private network 202. Correspondingly, when an input message passes through NAT 304, the IP address assigned to the private network 202 can be replaced with the address of device 302 and the message routed to the appropriate device 302.

[0042] At 306, device 302 discovers remote server 30 by transmitting a discovery request to remote server 30. The discovery request may include, for example, a request for server location and trusted certificates. At 308, the remote server transmits its server location and trusted certificates to device 302. At 310, device 302 transmits a request for policy and identity to remote server 30. In some embodiments, the request may include default credentials for device 302 to establish a connection with remote server 30. At 312, remote server 30 provides its identity and policy to device 302. The identity identifies remote server 30 and may include, for example, an IP address, URL, media access control (MAC) address, etc. The policy may define one or more operating parameters of device 302 and / or various activities performed by device 302 or other devices within industrial automation system 10, including frequency checks for firmware updates. After a connection is established between device 302 and remote server 30, device 302 enters firmware update loop 314. For example, at 316, device 302 may periodically transmit requests for firmware to remote server 30. The frequency of requests can be determined based on a strategy received from remote server 30. At 318, if an update is available, the firmware update is transferred from remote server 30 to device 302 and stored in the non-volatile memory of device 302. In some embodiments, firmware update ring 314 can be used to receive self-deleting firmware packages to clean up the memory of device 302.

[0043] Figure 5A flowchart is shown for a process 400 for implementing a self-deleting memory cleanup firmware package on a device. Although the following description of process 400 is in a specific order and is performed by device 302, it should be noted that process 400 can be performed by any suitable component in any suitable order.

[0044] At point 402, device 302 can receive a self-deleting memory cleanup firmware package and store the firmware package in non-volatile memory. In some embodiments, device 302 can receive the self-deleting memory cleanup firmware package directly from a remote server, as per [reference to...]. Figure 4 As shown and described. In other embodiments, device 302 may receive a self-deleting memory cleanup firmware package from a computing device within a private network managing an industrial automation system, as per [the description of the package]. Figure 3 As shown and described. In other embodiments, device 302 may have a self-deleting memory cleanup firmware package pre-loaded in non-volatile memory.

[0045] At box 404, device 302 may identify a sensitivity level associated with the device itself and / or the application running on device 302. In some embodiments, the sensitivity level may be binary. That is, device 302 and / or the application running on device 302 may be considered sensitive or non-sensitive. In other embodiments, the sensitivity level may have multiple sensitivity degrees. Thus, different degrees of sensitivity may correspond to the media cleanliness levels described in the NIST 800-88 guideline above. However, it should be understood that the scale of the sensitivity level may or may not have three levels that directly correspond to the three media cleanliness levels described in the NIST 800-88 guideline. In some embodiments, the sensitivity level of device 302 and / or the application running on device 302 may be set by the user. In other embodiments, the sensitivity level of device 302 and / or the application running on device 302 may be beyond the user's control and set by the network administrator, or may be automatically set based on how device 302 is used, the application running on device 302, and how the application running on device 302 is used. In some implementations, the sensitivity level of a device or application can be determined based on data being used or stored. For example, customer data, supplier data, data related to trade secrets, data related to process or equipment lists, data restricted or classified by the government, information classified as top secret, information classified as secret, information classified as confidential, information related to an organization's human resources, information related to the medical history of one or more individuals, information related to military operations, information generated by or used by a government agency or organization, information related to law enforcement, information related to government intelligence, etc., can trigger devices or applications assigned a specific sensitivity level.

[0046] At block 406, device 302 may execute a self-deleting memory cleanup firmware package to clean up the memory based on the sensitivity level identified in block 404. Executing the self-deleting memory cleanup firmware package may include: retrieving program code from non-volatile memory; writing the program code to volatile memory; and executing the program code stored in volatile memory to clean up the non-volatile memory. The cleanup process may involve rewriting addressable locations in the non-volatile memory a sufficient number of times (e.g., 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 or more times) a specific sequence such that retrieving data previously stored on the non-volatile memory using laboratory techniques is infeasible, and the non-volatile memory is considered cleaned up according to NIST 800-88 guidelines. An example sequence of rewriting non-volatile memory is discussed in more detail below with reference to FIG6. In some implementations, the entire non-volatile memory may be cleaned up. For example, if the entire device 302 is classified as sensitive, or if one or more applications running on device 302 meet or exceed a sensitivity threshold level, the entire non-volatile memory of device 302 can be wiped. Alternatively, if sensitivity is limited to a portion of the memory or a subset of memory cells within the non-volatile memory, and the sensitivity level does not meet or exceed a sensitivity threshold level, only a portion of the non-volatile memory can be wiped. In this case, the self-deleting memory cleanup firmware package, along with any other data stored in the non-volatile memory, has been erased from the non-volatile memory, making it unrecoverable.

[0047] At block 408, device 302 can perform a power supply cycle by disconnecting from and reconnecting to the same power source. In some embodiments, device 302 can cycle power itself (e.g., by automatically shutting itself down, physically disconnecting itself from the power source, etc.). In other embodiments, device 302 can cycle power in response to input received from a user. Powering off device 302 includes clearing volatile memory such that instructions associated with the self-deleting memory clearing firmware package, as well as any other data stored on the volatile memory, have been completely erased from memory and cannot be recovered.

[0048] At box 410, device 302 can restore itself to its factory settings. In some implementations, device 302 can receive baseline software / firmware packages from a remote server, such as those related to... Figure 4 As shown and described, or received from computing devices within a private network managing industrial automation systems, such as regarding... Figure 3 As shown and described. The baseline software / firmware package may include software or firmware pre-installed on the device "out of the box".

[0049] Figures 6A to 6FAn implementation of a sequence of rewriting addressable locations in non-volatile memory during memory cleanup is illustrated. As previously discussed, the memory cleanup process may include a specific sequence of rewriting addressable locations in non-volatile memory a threshold number of times, such that retrieving data previously stored in the non-volatile memory using laboratory techniques is infeasible, and the non-volatile memory is considered cleaned up according to NIST 800-88. For example, Figure 6A This illustrates rewriting an addressable location in non-volatile memory using mode 500 with all values ​​set to 1. Figure 6B This illustrates rewriting an addressable location in non-volatile memory using pattern 502, which consists entirely of zeros. Figure 6C This illustrates rewriting an addressable location in non-volatile memory using pattern 504, which consists of alternating 1s and 0s. Figure 6D It shows the use of relative to Figure 6C The pattern 504 shown is an inverted pattern 506 composed of alternating 1s and 0s, which rewrites the addressable location in the non-volatile memory. Figure 6E The diagram illustrates rewriting addressable locations in non-volatile memory using a first random generation pattern 508 consisting of 1s and 0s. Figure 6F This illustrates rewriting addressable locations in non-volatile memory using a second randomly generated pattern 510 consisting of 1s and 0s. However, it should be understood that... Figure 6E and Figure 6F The specific pattern of randomly generated 1s and 0s shown is merely an example, and other patterns of randomly generated 1s and 0s can also be envisioned.

[0050] In some implementations, the memory cleanup process may include, according to Figures 6A to 6F The specific sequence shown rewrites addressable locations in non-volatile memory. However, implementations in which the order in which addressable locations in non-volatile memory are rewritten occurs in a different order include several steps, and additional steps and / or repeated steps are also contemplated.

[0051] Figure 7 A flowchart illustrating an implementation of a process 600 for cleaning up a self-deleting memory firmware package that is locally stored on the device is shown. Although the following description of process 600 is in a specific order and is performed by device 302, it should be noted that process 600 can be performed by any suitable component in any suitable order.

[0052] At 602, device 302 receives a command to clear the memory. This command may be received via a user interface of the device, which may include a display with buttons or a touchscreen. In other embodiments, the command may be received via a hardware switch or other physical input device. For example, a user may press and hold a button such as a reset button to actuate the button or throw a reset switch according to a sequence (e.g., pressing the button a specific number of times). In other embodiments, device 302 may receive the command via other remote devices such as a human-machine interface (HMI), a mobile device, a tablet computer, etc.

[0053] At block 604, device 302 retrieves a self-deleting memory cleanup firmware package from non-volatile memory and copies the self-deleting memory cleanup firmware package to volatile memory for execution. In some embodiments, device 302 may receive the self-deleting memory cleanup firmware package from a remote server, such as... Figure 4 As shown and described, or received from computing devices within a private network managing industrial automation systems, such as self-deleting memory cleanup firmware packages. Figure 3 As shown and described. In other embodiments, device 302 may receive a self-deleting memory cleanup firmware package from a nearby device either from removable media (e.g., a Secure Digital (SD) card, a Universal Serial Bus (USB) drive, an optical disc, or a floppy disk) or via a short-range communication protocol (e.g., Bluetooth, Near Field Communication, etc.). In other embodiments, the device may have a self-deleting memory cleanup firmware package pre-loaded in non-volatile memory.

[0054] At box 606, device 302 identifies a sensitivity level associated with device 302 and / or the application running on device 302. In some implementations, the sensitivity level may be binary (e.g., sensitive or insensitive). In other implementations, the sensitivity level may have multiple sensitivity degrees, which may or may not correspond to the media cleanup levels described in the NIST 800-88 guideline. The sensitivity level of the device and / or the application running on the device may be set by the user or may be beyond the user's control (e.g., set by a network administrator or automatically based on how the device is used, the application running on the device, how the application running on the device is used, etc.).

[0055] At block 608, device 302 executes a self-deleting memory cleanup firmware package to clean up the memory based on the sensitivity level identified in block 606. Executing the self-deleting memory cleanup firmware package may include executing program code stored in volatile memory to clean up non-volatile memory. The cleanup process may involve rewriting a specific sequence of addressable locations in the non-volatile memory a threshold number (e.g., 3) using laboratory techniques, such that data previously stored in the non-volatile memory cannot be retrieved using laboratory techniques, and the non-volatile memory is considered cleaned according to NIST 800-88 guidelines. The specific sequence of rewriting the non-volatile memory is discussed in more detail with reference to Figure 6. At this point, the self-deleting memory cleanup firmware package, along with any other data stored in the non-volatile memory, has been erased from the non-volatile memory, making it unrecoverable.

[0056] At block 610, device 302 can perform a power cycle by disconnecting from and reconnecting to the same power source. Powering off the device includes erasing volatile memory, such that instructions related to the self-erasing memory cleanup firmware package, as well as any other data stored on the volatile memory, have been completely erased from memory, making them unrecoverable. At block 612, device 302 can restore itself to its factory settings. In some embodiments, the device can receive a baseline software / firmware package from a remote server, such as regarding... Figure 4 As shown and described, or received from computing devices within a private network managing industrial automation systems, such as regarding... Figure 3 As shown and described. The baseline software / firmware package may include software or firmware pre-installed on the device "out of the box".

[0057] Figure 8 A flowchart is shown illustrating an implementation of a process 700 for receiving a self-deleting memory cleanup firmware package from a remote device. While the following description of process 700 is presented in a specific order and is performed by device 302, it should be noted that process 700 can be performed by any suitable component in any suitable order.

[0058] At 702, device 302 receives input for remote cleanup of the authorized memory (e.g., "remote deactivation"). Device 302 may receive input via the device's user interface, via a hardware switch, or some other physical input device. This input may include, for example, actuating a "remote deactivation allowed" switch, providing a personal identification number (PIN), authorization code, password, etc.

[0059] At point 704, device 302 receives a self-deleting memory cleanup firmware package and stores it in memory. In some embodiments, device 302 receives the self-deleting memory cleanup firmware package directly from a remote server, as per [reference to...]. Figure 4 As shown and described. In other embodiments, device 302 receives a self-deleting memory cleanup firmware package from a computing device within a private network managing the industrial automation system, as per [reference to...]. Figure 3 As shown and described. If it is not already in volatile memory, device 302 retrieves the self-deleting memory cleanup firmware package from non-volatile memory and copies it to volatile memory for execution. In some embodiments, the self-deleting memory cleanup firmware package may already be stored in non-volatile memory. In such embodiments, the device can receive commands from a remote device to execute the self-deleting memory cleanup firmware package already stored in memory.

[0060] In some implementations, device 302 can execute a self-deleting memory cleanup firmware package without receiving input for authorized memory cleanup at the device. For example, the device may be identified as compromised, and the memory may be remotely cleaned to protect the data stored in it. Identifying a compromised device may include: detecting an open cabinet / box; using beacons to determine if the device has been moved out of an authorized area; using a Global Positioning System (GPS) to determine if the device has been moved out of an authorized area; determining if the device has been hacked or otherwise remotely accessed by an unauthorized party, etc. In such implementations, a self-deleting memory cleanup firmware package can be used to clean up the device's memory without requiring authorization at the device's physical location.

[0061] At box 706, device 302 identifies a sensitivity level associated with the device and / or the application running on the device. The sensitivity level may be binary (e.g., sensitive or non-sensitive) or may have multiple sensitivity levels that may or may not correspond to the media cleanup levels described in the NIST 800-88 guideline. The sensitivity level of the device and / or the application running on the device may be set by the user or may be beyond the user's control (e.g., set by a network administrator or automatically based on how the device is used, the application running on the device, and how the application running on the device is used, etc.).

[0062] At block 708, device 302 executes a self-deleting memory cleanup firmware package to clean up the memory based on the sensitivity level identified in block 704. Executing the self-deleting memory cleanup firmware package may include executing program code stored in volatile memory to clean up non-volatile memory. The cleanup process may involve a specific sequence of rewriting addressable locations in non-volatile memory a threshold number of times, making it impossible to retrieve data previously stored in non-volatile memory using certain laboratory techniques, and the non-volatile memory is considered cleaned according to NIST 800-88 guidelines. The specific sequence of rewriting non-volatile memory is discussed in more detail with reference to Figure 6. At this point, the self-deleting memory cleanup firmware package, as well as any other data stored in non-volatile memory, has been erased from the non-volatile memory, making it unrecoverable.

[0063] At box 710, power to the device is cycled by powering the device down and then powering it on. Powering down the device involves clearing the volatile memory, such that instructions related to the self-deleting memory cleanup firmware package, as well as any other data stored on the volatile memory, have been completely erased from the memory, making them unrecoverable. At box 712, the device is restored to its factory settings. In some implementations, the device can receive a baseline software / firmware package from a remote server, such as regarding... Figure 4 As shown and described, or received from computing devices within a private network managing industrial automation systems, such as regarding... Figure 3 As shown and described. The baseline software / firmware package may include software or firmware pre-installed on the device "out of the box".

[0064] Figure 9 A flowchart illustrating an implementation of a process 800 for cleaning up a self-deleting memory firmware package and generating a cleanup report is shown. While the following description of process 800 is in a specific order and is performed by device 302, it should be noted that process 800 can be performed by any suitable component in any suitable order.

[0065] At point 802, device 302 retrieves the self-deleting memory cleanup firmware package from non-volatile memory and copies it to volatile memory for execution. In some embodiments, device 302 may receive the self-deleting memory cleanup firmware package from a remote server, such as... Figure 4 As shown and described, or received from computing devices within a private network managing industrial automation systems, such as self-deleting memory cleanup firmware packages. Figure 3 As shown and described. In other embodiments, the device may have a self-deleting memory cleanup firmware package pre-loaded in non-volatile memory.

[0066] At box 804, device 302 identifies a sensitivity level associated with the device and / or the application running on the device. The sensitivity substrate may be binary (e.g., sensitive or non-sensitive) or may have multiple sensitivity levels that may or may not correspond to the media cleanliness levels described in the NIST 800-88 guideline. The sensitivity level of the device and / or the application running on the device may be set by the user or may be beyond the user's control (e.g., set by a network administrator or automatically based on how the device is used, the application running on the device, and how the application running on the device is used, etc.).

[0067] At block 806, device 302 executes a self-deleting memory cleanup firmware package to clean up the memory based on the sensitivity level identified in block 804. Executing the self-deleting memory cleanup firmware package may include executing program code stored in volatile memory to clean up non-volatile memory. The cleanup process may involve a specific sequence of rewriting addressable locations in non-volatile memory a threshold number of times, such that data previously stored in non-volatile memory cannot be retrieved using various laboratory techniques, and the non-volatile memory is considered cleaned according to NIST 800-88 guidelines. The specific sequence of rewriting non-volatile memory is discussed in more detail with reference to Figure 6. At this point, the self-deleting memory cleanup firmware package, as well as any other data stored in non-volatile memory, has been erased from the non-volatile memory, making it unrecoverable.

[0068] At box 808, device 302 can perform a power cycle by disconnecting from and reconnecting to the same power source. Powering off the device involves clearing the volatile memory, such that instructions associated with the self-deleting memory clearing firmware package, as well as any other data stored on the volatile memory, are completely erased from memory, making them unrecoverable. At this point, the device is restored to its factory settings. In some implementations, the device can receive a baseline software / firmware package from a remote server, such as regarding... Figure 4 As shown and described, or received from computing devices within a private network managing industrial automation systems, such as regarding... Figure 3 As shown and described. The baseline software / firmware package may include software or firmware pre-installed on the device "out of the box".

[0069] At 810, the device can provide and / or display a hash value indicating that memory cleanup has been successfully completed. In some implementations, the hash value can be written to a cache or other part of the memory. As described in more detail below, the generated hash value can be included in a cleanup report or used to sign the cleanup report to verify that cleanup has been completed. A hash value can be a fixed-length numerical value that uniquely identifies data. Typically, a hash value can represent a large amount of data with a significantly small number of values. Therefore, hash values ​​are often used as digital signatures or in conjunction with digital signatures. Hash values ​​can be generated via a hash function or hash algorithm that uses a managed hash class to hash an array of bytes or a managed stream object (i.e., generate a hash value). Hash values ​​can also be used to verify the integrity of data that may have been transmitted over an insecure channel or may have been otherwise altered. The hash value of received data can be compared with the hash value of data before transmission to determine whether the data has been altered. For example, data can be hashed at some point and the hash value can be protected in some way (e.g., encrypted). The data can then be hashed again and compared with the protected value to assess the integrity of the data. If the hash values ​​match, the data has not been altered. If the values ​​do not match, the data has been compromised. Hash values ​​can be encrypted (e.g., using asymmetric encryption with a public / private key scheme) or otherwise kept secret from untrusted parties.

[0070] At point 812, device 302 can generate a cleanup report to confirm that the memory cleanup has been successfully completed. The cleanup report can be a text file, a portable document file (PDF), or some other format. The cleanup report may indicate the memory portion cleaned, the time the cleanup occurred, one or more users or devices that requested and / or approved the cleanup, etc. In some implementations, the cleanup report can be signed with a hash value to verify the authenticity of the cleanup report and its contents. For security purposes, a public key can be used to encrypt the hash value. The public key can be unique to the device, the device manufacturer, the device owner, the device operator, etc. The private key can then be used to decrypt the encrypted hash value and verify the report signature. In other implementations, the private key can be used to sign the report. In such implementations, the public key can be used to verify the signature.

[0071] This disclosure includes techniques for cleaning up the memory of a device so that data previously stored in the memory cannot be recovered using various laboratory techniques, thereby allowing the device containing the memory to be reused for another application instead of being corrupted. Specifically, the memory can be cleaned up via a self-deleting firmware package. The firmware package can be stored in the device's non-volatile memory, received from another device via a wired or wireless network connection, via removable media (e.g., SD card, USB drive, optical disc, etc.), or by some other means. The firmware package can be copied to the volatile memory and executed by a processor to perform the cleanup process. This can include, for example, repeatedly rewriting some or all of the addressable locations of the memory using a specific sequence of 1 and 0 patterns, such that data stored in the memory before the cleanup process begins cannot be recovered using certain laboratory techniques.

[0072] In some implementations, if a firmware package is received from a different device, input for authorized memory cleanup can be provided. In some implementations, the entire non-volatile memory and volatile memory of the device are cleaned. In other implementations, only a portion of the non-volatile memory of the device used by a specific application with a sensitivity level above a threshold level is cleaned. Once the cleanup of the non-volatile memory is complete, power is cycled to the device, which clears the volatile memory. At this point, both the non-volatile and volatile memory of the device have been cleaned. In some implementations, the device can receive and execute a baseline software and / or firmware package that returns the device to its original factory settings. In some implementations, the device can generate and display a hash value indicating that the device has been cleaned. In other implementations, the device can generate a report indicating that the device has been cleaned, which may include the generated hash value. The report may or may not be encrypted. If the report is encrypted, a public key can be used to encrypt the report. In such an implementation, the client will use the provided private key to decrypt the report. In other implementations, a private key can be used to sign the report. In such an implementation, a public key can be used to verify the signature.

[0073] The use of the disclosed technology allows entities to clean the memory of devices containing storage, making data previously stored in the pre-cleaned memory unrecoverable using certain laboratory techniques. This ability to clean the device without recovering previously stored data allows entities to reuse the device from one application to another, rather than damaging the device and purchasing a new one. Reusing devices instead of damaging and replacing them is less costly, less resource-intensive, and results in less material waste.

[0074] The specific embodiments described above have been illustrated by way of example, and it should be understood that these embodiments are permissible with various modifications and alternatives. It should also be understood that the claims are not intended to limit the specific forms disclosed, but rather to cover all modifications, equivalents, and alternatives falling within the spirit and scope of this disclosure.

[0075] The techniques proposed and claimed herein are referenced and applied to specific examples of material objects and actual properties, which significantly improve the field of expertise, and are therefore not abstract, intangible, or purely theoretical. Furthermore, if any claim appended to this specification contains one or more elements designated as "means for [performing] [function]..." or "steps for [performing] [function]...", it is intended that such elements be interpreted according to 35U.SC112(f). However, for any claim containing elements designated in any other manner, it is intended that such elements not be interpreted according to 35U.SC112(f).

Claims

1. A non-transitory computer-readable medium storing instructions that, when executed by a processor, cause the processor to perform a plurality of operations, the plurality of operations including: The processor receives commands for performing memory cleanup of industrial automation components. The processor retrieves the cleanup firmware package code from non-volatile memory. The code is stored in volatile memory via the processor; Identify one or more software applications running on the industrial automation component that have a corresponding sensitivity level higher than a threshold; The processor executes the code from the volatile memory, thereby causing the processor to clean up the non-volatile memory, including rewriting a subset of the addressable locations of the non-volatile memory, wherein the subset of the addressable locations of the non-volatile memory corresponds to portions of the non-volatile memory used by the one or more software applications determined to have sensitivity levels above the threshold; and The industrial automation components are cyclically powered, wherein cyclic power supply includes clearing the volatile memory.

2. The computer-readable medium according to claim 1, wherein, Rewrite the subset of the addressable locations of the non-volatile memory using the following pattern: The first pattern consists of 1s; The second mode consisting of 0; and The third pattern consists of alternating 1s and 0s.

3. The computer-readable medium according to claim 2, wherein, The subset of addressable locations in the non-volatile memory is also rewritten using the following pattern: A fourth pattern consisting of alternating 1s and 0s, wherein the fourth pattern is inverted relative to the third pattern; and The fifth random generation pattern consists of 1s and 0s.

4. The computer-readable medium according to claim 1, wherein, The multiple operations also include: receiving the cleanup firmware package via a network connection.

5. The computer-readable medium according to claim 1, wherein, The plurality of operations also include receiving the cleanup firmware package from a removable medium, wherein the removable medium includes an SD card, a USB drive, an optical disc, or a floppy disk.

6. The computer-readable medium according to claim 1, wherein, The multiple operations also include: receiving a baseline software package, a baseline firmware package, or a combination thereof to return the industrial automation component to factory settings.

7. The computer-readable medium according to claim 1, wherein, The plurality of operations also include: Indicate the sensitivity level of the industrial automation component.

8. An industrial automation component, comprising: processor; Volatile memory accessible by the processor; as well as A non-volatile memory, comprising multiple addressable locations accessible by the processor and storing instructions that, when executed by the processor, cause the processor to perform multiple operations, the multiple operations including: The processor receives commands from an input device communicatively coupled to the industrial automation component via a network for performing memory cleanup of the industrial automation component; The processor retrieves the cleanup firmware package code from the non-volatile memory. The processor stores the code of the cleanup firmware package in the volatile memory; Identify one or more software applications running on the industrial automation component that have a corresponding sensitivity level higher than a threshold; The processor executes the code from the volatile memory, thereby causing the processor to clean up the non-volatile memory, including rewriting a subset of the addressable locations of the non-volatile memory, wherein the subset of the addressable locations of the non-volatile memory corresponds to portions of the non-volatile memory used by the one or more software applications determined to have sensitivity levels above the threshold; and The industrial automation components are cyclically powered, wherein cyclic power supply includes clearing the volatile memory.

9. The industrial automation component according to claim 8, wherein, The multiple operations also include receiving input via the interface of the industrial automation component, indicating authorization to perform the memory cleanup.

10. The industrial automation component according to claim 8, wherein, The code executes based on an indication that the industrial automation component has been compromised, even without receiving authorized input to perform the memory cleanup.

11. The industrial automation component according to claim 8, wherein, Rewrite the subset of the addressable locations of the non-volatile memory using the following pattern: The first pattern consists of 1s; The second mode consisting of 0; and The third pattern consists of alternating 1s and 0s.

12. The industrial automation component according to claim 11, wherein, The subset of addressable locations in the non-volatile memory is also rewritten using the following pattern: A fourth pattern consisting of alternating 1s and 0s, wherein the fourth pattern is inverted relative to the third pattern; and The fifth random generation pattern consists of 1s and 0s.

13. The industrial automation component according to claim 8, wherein, The plurality of operations also include: Indicate the sensitivity level of the industrial automation component.

14. A method for cleaning up the non-volatile memory of an industrial automation component, comprising: The processor receives a command to perform memory cleanup for the industrial automation components. The processor retrieves the cleanup firmware package code from the non-volatile memory. The code is stored in volatile memory via the processor; Identify one or more software applications running on the industrial automation component that have a corresponding sensitivity level higher than a threshold; The processor executes the code from the volatile memory, thereby causing the processor to clean up the non-volatile memory, including rewriting a subset of the addressable locations of the non-volatile memory, wherein the subset of the addressable locations of the non-volatile memory corresponds to portions of the non-volatile memory used by the one or more software applications determined to have sensitivity levels above the threshold; and The industrial automation components are cyclically powered, wherein cyclic power supply includes clearing the volatile memory.

15. The method of claim 14, further comprising: The cleanup firmware package is received from removable media, including an SD card, USB drive, optical disc, or floppy disk.

16. The method of claim 14, further comprising: The cleanup firmware package is received via a network connection.

17. The method of claim 14, further comprising: Generate a memory cleanup report confirming that the memory cleanup has been completed.

18. The method according to claim 17, wherein, The memory cleanup report includes a hash value.

Images