Resilient software updates in secure storage

Abstract

Methods, computer-readable media, and apparatuses for performing software updates are disclosed herein. In one embodiment, a method is disclosed that includes initializing a storage space of a secure storage device into a plurality of portions; copying an update program to a first portion of the portions and copying update data to a second portion of the portions; generating a first golden measurement of the first portion and a second golden measurement of the second portion; measuring the first portion; updating or rolling back an update to the secure device in response to determining that the measurement of the first portion does not match the first golden measurement of the first portion; and verifying an update operation after determining that the measurement of the first portion matches the first golden measurement of the first portion.

Description

[0001] Related applications

[0002] This application claims priority to U.S. Patent Application No. 16 / 694,583, filed November 25, 2019, entitled “Resilient Software Updates in Secure Storage Devices,” the entire disclosure of which is hereby incorporated by reference.

[0003] Copyright Notice

[0004] This patent document contains a portion of copyrighted material. The copyright holder does not object to any fax copy of this patent document or patent disclosure, as it appears in the patent documents or records of the Patent and Trademark Office, but otherwise retains all copyright. Background Technology

[0005] The disclosed embodiments are for software updates in secure storage devices. Specifically, the disclosed embodiments are for providing reliable and resilient updates for such secure storage devices in potentially variable environments.

[0006] In many environments, security storage devices are frequently updated under conditions where failures in the update storage device software must be avoided or mitigated gradually. For example, software updates to the operating system of an autonomous vehicle may be installed while the vehicle is in motion. Failures during the software update process can potentially render the vehicle's hardware systems unresponsive, which could potentially lead to a collision.

[0007] Currently, many update procedures for secure storage devices effectively require the storage device to be placed in a special mode or to be in a specific environment before the software update is performed. This requirement ensures that any failure during the software update process will not adversely affect the device or users of components that depend on the device.

[0008] This current procedure unnecessarily limits the frequency of software updates and adversely affects the user experience of systems using such storage devices. Therefore, there is a need in the art for an improved, secure storage device that reliably and resiliently supports software updates at any time. The disclosed embodiments provide such a technical solution. Attached Figure Description

[0009] Figure 1 A block diagram illustrating a computer system for managing software updates according to some embodiments of the present disclosure.

[0010] Figure 2A flowchart illustrating a method for initializing a secure storage device for software updates according to some embodiments of the present disclosure.

[0011] Figure 3 A flowchart illustrating a method for executing a startup time sequence according to some embodiments of the present disclosure.

[0012] Figure 4 A flowchart illustrating a method for performing runtime management updates according to some embodiments of the present disclosure.

[0013] Figure 5 A flowchart illustrating a method for performing a software update according to some embodiments of the present disclosure.

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

[0015] Figure 7 This is a block diagram showing the layout of a storage device according to some embodiments of the present disclosure. Detailed Implementation

[0016] The disclosed embodiments describe techniques for enabling modifications to any portion of a software image stored on a secure storage device without impairing the execution of the software image. The disclosed embodiments address the above-mentioned problems by making software updates more resilient across power cycles, thus preventing device software corruption. In doing so, the disclosed embodiments allow software updates to be performed on critical parts of a computer system with virtually no risk, thereby significantly reducing the cost and computational complexity of software updates that would otherwise need to be implemented under severely constrained conditions.

[0017] The technology includes a software update sequence that begins at a first point in time, which can be interrupted by an event and can be resumed or restarted at a later time (even after a reboot). In another aspect, the disclosed embodiments may allow only a licensed user to control the initiation and configuration of the aforementioned software update sequence. Additionally, in yet another aspect, the disclosed embodiments support multiple types of software update schemes, including A / B (full image) software updates and differential (partial) software updates.

[0018] In the embodiments described herein, software updates may include a startup procedure. In these embodiments, any failure in the update process can render the device inoperable (i.e., "disable" the device) and prevent it from booting. Examples of failures include power loss, communication link interruption, and malicious actor intervention. The disclosed embodiments mitigate the risks associated with these failures by leveraging features of the secure storage device. Specifically, the disclosed embodiments utilize the concept of an authorized user to prevent unauthorized users from initiating software update procedures. Additionally, the disclosed embodiments provide state tracking features that enable the secure storage device to maintain system state across startup sequences, allowing the secure storage device to restore the system to its previous state or restart the update sequence.

[0019] As described above, the disclosed embodiments support both full and partial updates. If a full image update scheme is implemented, the previous software image on the security device can be saved until a new image is ready to be installed, after which a startup pointer can be assigned to the new image as the active image. However, in existing systems, there remains a risk that pointer-changing operations may cause the device to malfunction. The disclosed embodiments address this problem as described in more detail herein.

[0020] If the new image is large and the changes introduced in the new image are relatively small, then a full image update unnecessarily consumes a large amount of communication payload and a large amount of buffer space on the storage device. In this scenario, differential updates reduce communication size and buffer utilization. However, due to the "segmented" nature of this update, additional complexity is added during the update procedure. This complexity adds an additional point of failure, which is also addressed by the disclosed embodiments.

[0021] Figure 1 A block diagram illustrating a computer system for managing software updates according to some embodiments of the present disclosure.

[0022] In the illustrated embodiment, the system (100) includes a remote computing device (112) and a target computing device (102) communicatively connected via a network (110). Although described separately, the system (100) may include multiple devices (112, 102) and may communicate via multiple networks. In the illustrated embodiment, the devices (102, 112) include, for example... Figure 7The computing devices described herein. For example, a remote computing device (112) may include one or more server computers and a target computing device (102) may include a consumer computing device. In some embodiments, the target computing device (102) may include an in-vehicle electronic control unit (ECU) or other device. In other embodiments, the target computing device (102) may include a laptop, desktop, mobile, wearable, or other consumer computing device. In other embodiments, the target computing device (102) itself may include a server or other network device. This disclosure does not limit the type and use of the devices (102, 112).

[0023] In the illustrated embodiments, the remote computing device (112) includes a software image storage device (114) and an update manager (116). In one embodiment, the software image storage device (114) is external to the remote computing device (112). In some embodiments, the software image storage device (114) includes a file system for storing software images. In other embodiments, the software image storage device (114) includes a database for storing software images. In these embodiments, the database may include relational, NoSQL, key-value, or any other type of database for storing files. In the illustrated embodiments, a software image refers to a file that defines a piece of software. In some embodiments, a software image refers to a source code image of a replacement for a previous version of software designed to replace the software. In other embodiments, a software image refers to a partial update. A partial update includes an update to a piece of software that includes less than the entire software. In some embodiments, the software image storage device (114) stores both complete and partial software images. Software images may be in the form of human-readable source code or machine-readable binary (compiled) code. This disclosure does not impose any limitation on the specific data format of software images. Software images are generally managed by the operator of the remote computing device (112). When an update to the software is created in the form of a software image, the operator uploads the software image to the software image storage device (114). Other techniques can be used to insert software images into the software image storage device (114), such as version control systems (e.g., Git), continuous integration systems, or other systems.

[0024] The remote computing device (112) further includes an update manager (116). In some embodiments, the update manager (116) and the software image storage device (114) may be implemented on a single device (e.g., as a database and an application server, respectively). In other embodiments, the update manager (116) includes a separate computing device (e.g., a server). As illustrated, the update manager (116) accesses the software image storage device (114). In the illustrated embodiment, the update manager (116) retrieves software images from the software image storage device (114). In some embodiments, the update manager (116) retrieves software images from the software image storage device (114) in response to an update request from the target computing device (102). Alternatively or in combination with the foregoing, the update manager (116) may periodically check for new software images stored in the software image storage device (114) and retrieve software images in response to the detection of new software images. Alternatively or in combination with the foregoing, the update manager (116) may subscribe to the software image storage device (114), and the software image storage device (114) may push software images to the update manager (116) when they are recently stored in the software image storage device (114). The specific mechanism by which the update manager obtains software images is not intended to be restrictive.

[0025] In the illustrated embodiments, the update manager (116) performs various operations relative to certain images. For example, the update manager (116) may be configured to perform checksum verification on the software image to ensure its integrity. In other embodiments, the update manager (116) assumes the integrity of the software image and generates a checksum (e.g., MD5) of the software image to be used by other devices. However, primarily, the update manager (116) is responsible for coordinating the transfer of the software image from the remote computing device (112) to the target computing device (102). This role has been previously described and will not be repeated herein.

[0026] The remote computing device (112) transmits software images to the target computing device (102) via one or more networks (110). In the illustrated embodiment, the network (110) includes the Internet (a network of networks). In this embodiment, the network (110) includes a wide area network (WAN); however, other network types may be used instead of any particular network description.

[0027] The target computing device (102) receives a software image via a network (110). Specifically, the target computing device (102) receives the software image via a corresponding update manager (108). The update manager (108) is configured to process the received software image and load the software image (106) into a secure storage device (104). In the illustrated embodiment, the update manager (108) may be implemented in software or via dedicated hardware. Figures 2 to 6 The specific operations of the update manager (108) are described in more detail in the description and the description is incorporated herein by reference in its entirety.

[0028] In the illustrated embodiment, the secure storage device (104) includes a storage device (e.g., flash-based, disk-based, etc.) and a secure platform module (SPM). In some embodiments, this secure platform module may include modules conforming to the ISO / IEC 11889 standard and may include trusted platform modules. The specific standards used are not limiting. Generally, the secure storage device (104) is configured not only to store software images but also to verify the integrity of the underlying storage medium. The SPM may include features such as random number generation, encryption key generation, encryption / decryption, authentication, and other security functions. In some embodiments, the SPM may alternatively be implemented as part of an update manager (108).

[0029] In the illustrated embodiment, the secure storage device (104) may be segmented into multiple parts. These parts may be configured with various properties to enable and disable unauthorized user writes. The secure storage device (104) will typically include a part called the "in-operation software space" that stores the current software image. In addition to the in-operation storage space, the secure storage device (104) may include a hidden storage portion.

[0030] The reference description system is now used for the process of safely updating software images. Figures 2 to 5 .

[0031] Figure 2 This is a flowchart illustrating a method for initializing a secure storage device for software updates according to some embodiments of the present disclosure. During execution... Figure 2 Prior to the method described herein, the device executes a method containing a first software image (referred to as image A) and has not yet begun any software update steps. The illustrated method prepares an image for updating the device and then restarts the device to begin or restart the update process. In the illustrated embodiment, the method (200) is performed by an authorized user of the device (including a remote authorized user).

[0032] In block 202, method (200) configures a first portion of the secure storage device to operate in write-protected mode. This first portion is also referred to as the "software update source code image space". In the illustrated embodiment, method (200) is operated by a privileged user of the storage space. Reference Figure 1This authorized user may include the update manager (108). For clarity, the authorized "user" refers to a user account on the target computing system (e.g., 102) and does not refer to a human user. Therefore, the authorized user may include software applications running under the authorized user account. In the illustrated embodiment, the first portion is then set to write-protected, meaning only the authorized user can write to the first portion, preventing all other user accounts from writing to the first portion.

[0033] In block 204, method (200) downloads a software image to a first portion configured in block 202. As previously described, method (200) may retrieve the software image from a remote repository via a network. In response to receiving the software image, method (200) copies or otherwise transmits the image to the write-protected first portion configured in block 202. In the illustrated embodiment, the first portion stores the source code of a program for performing a software update. Generally, this may include a first-level bootloader (FSBL) and system code for managing the update program.

[0034] In some embodiments, in block 204, method (200) simultaneously saves the existing content of the first portion to memory. That is, before executing block 204, method (200) copies the current content of the first portion to memory before writing the new software image to the first portion. In some embodiments, the current content of the first portion includes code for installing the current version of the software installed on the device.

[0035] In box 206, method (200) configures a second portion of the secure storage device to operate in write-protected mode. This first portion is also referred to as a "software update buffer." The creation of the second portion of the secure storage device as a write-protected portion is executable, as described in the description of box 202.

[0036] In block 208, method (200) transfers data from the second portion to memory and downloads the updated software image to the second portion. In the illustrated embodiment, the data transfer from the second portion to memory is performed similarly to that described previously in block 204. In the illustrated embodiment, the data stored in the second portion includes actual update data for updating the software on the device. In some embodiments, the entire updated image is downloaded, while in other embodiments, only a portion of the update data is downloaded.

[0037] In block 210, method (200) modifies the recovery block of the secure storage device to point to the first portion created in block 202. Method (200) also caches the recovery block in memory. By executing block 210, the method ensures that the updater is updated on each reboot until completion. The previous recovery block is cached so that normal operation can be resumed after the updater is completed.

[0038] In the illustrated embodiment, the recovery block refers to the first block of the secure storage device executed after startup and before the execution of the FSBL. Generally, the recovery block contains memory detection code and low-level disk verification and recovery code. In block 210, the method (200) overrides this recovery block to instead point to the FSBL that loads the software image written to the first part. Generally, the FSBL is a suitable approximation configured to set up memory segments, reset the disk, locate the second-level boot loader (i.e., the first part), read the second-level boot loader (i.e., the first part) into memory, and transfer control to the second-level boot loader (i.e., the first part). In the illustrated embodiment, the FSBL includes an FSBL responsible for loading and initiating the loading of the update program in the first part.

[0039] In box 212, method (200) calculates a new gold measurement for the updated software image downloaded in the previous box. As used herein, a gold measurement refers to any value that can be used to securely identify a piece of software. Generally, a gold measurement is generated using one or more cryptographic functions. For example, the hash of a piece of software can be used as a gold measurement. In other embodiments, the gold measurement may include a hash tree of the updated software image. This gold measurement forms a root of trust because it can be used to verify whether other software matches the expected format and values.

[0040] In the illustrated embodiment, the gold measurement value comprises two parts. The first measurement value includes a hash of the first-level startup loader loaded in the first part. The second gold measurement value includes a hash of the entire updated image stored in the second part. In some embodiments, the hash may also include a secret key stored in the device and may include a hash-based message authentication code (HMAC) of the underlying data.

[0041] In the illustrated embodiment, method (200) further caches existing gold measurements calculated for the first and second parts. This effectively caches gold measurements for the current state of the system.

[0042] In block 214, method (200) caches the current updated state information of the secure storage device and initializes the newly updated state information to an initial state. As used herein, "state" refers to the operational state of the secure storage device. These states define the current operational state of a given device. As used herein, an initial state refers to one or more values ​​configured to indicate that the secure storage device is in a state requiring initialization. In one embodiment, the initialization portion includes establishing a new root of trust using a gold measurement value and the gold measurement value calculated in block 212 in the illustrated embodiment.

[0043] In box 216, method (200) configures a third portion of the secure storage device to be in write-enabled mode. This third portion is also referred to as the "active storage space". As described above, the third portion contains the current operational software image (referred to as image A) to be updated. By setting the third portion to write-enabled, method (200) allows any user (or a subset of users) to write data to the active storage space.

[0044] Therefore, after the execution of block 216, the secure storage device is configured with three separate parts: a write-protected first part, a second part stored in a hidden portion of the storage medium, and a third write-enabled part that stores the software image during use. Method (200) further modifies the boot preferences of the secure storage device to boot the first part containing the updated software image. A copy of the new software image is also stored in the second part.

[0045] In box 218, after reconfiguring the secure storage device portion and modifying the boot process, method (200) restarts the device. In the illustrated embodiments, restarting includes a software-initiated restart. In some embodiments, method (200) may force the secure storage device to restart. After restarting, method (200) ends and can be followed by... Figure 3 The method described in [the document / article].

[0046] In some embodiments, the restart in block 218 ensures additional security. In other embodiments, method (200) may forgo restarting.

[0047] Figure 3 The flowchart illustrates a method for executing a startup time sequence according to some embodiments of the present disclosure. Method (300) can be executed by a non-authorized user of the device. In the illustrated embodiments, method (300) is executed at startup time and offline in a context considered secure, as it is more difficult to intrude. In contrast, methods (400, 500) are executed at runtime and are susceptible to interference from malicious actors. Therefore, methods (400, 500) are executed by an authorized user with access to a known key.

[0048] In box 302, method (300) measures the contents of the first portion to calculate a first measurement of the first portion (also referred to as the software update source code image space in the description of box 202). As described above, this can be performed using a cryptographic function, such as a hash function or a similar function. Method (300) then compares this first measurement with... Figure 2 The first part of the gold measurement value generated by the system in box 212 is compared. Essentially, method (300) determines whether the first-level startup loader is valid.

[0049] In box 304, method (300) determines whether the first measurement generated in box 302 matches the gold measurement of the first part (generated in box 212).

[0050] In box 306, if method (300) determines that the first measurement matches the first gold measurement (i.e., the startup loader is valid), then the method calculates the second gold measurement and completes the startup sequence.

[0051] In box 308, method (300) runs the runtime update verification program after the startup sequence is completed. Figure 4 Details of box 308 are provided in the text and are incorporated herein without being repeated.

[0052] Generally, during the initial restart, the first gold measurement will not match the FSBL and the method will continue to box 310.

[0053] In box 310, method (300) copies the recovery block to the startup code location. As described above, the recovery block includes a pointer to the startup code location stored in the first part.

[0054] In block 312, method (300) runs FSBL. In the illustrated embodiment, FSBL initializes the system and returns the points to the software update image stored in the first part.

[0055] In block 314, method (300) loads and runs the software update image stored in the first part. In one embodiment, FSBL transfers control to the update software loaded in the first part, which then controls the processing described herein.

[0056] In block 316, method (300) loads the state of the device after performing an update software. In one embodiment, the state of the device refers to data stored in one or more non-volatile registers of the device. This disclosure is not limited to a particular type of data. In one embodiment, the state may include an update counter that increments automatically at each power cycle. Alternatively or in conjunction with the foregoing, the state information may include register data storing various state arrangements described herein. In some embodiments, the registers storing the state may include platform configuration registers.

[0057] In block 318, method (300) analyzes the state of the device. As will be described, the state register loaded in block 316 indicates the current state of any update or rollback operations performed prior to a restart.

[0058] If method (300) determines that the recovery or update operation was completed during the last power cycle, then the method continues the startup sequence in block 306 and finally runs the runtime update verification procedure in block 308. In this block, method (300) has successfully updated the device (or rolled back) and the operation can restart normally. As used in block 318, the update operation refers to the write portion of the update operation described in blocks 322, 326, and 332.

[0059] In block 320, method (300) verifies the status information after determining that a rollback operation is in progress. In the illustrated embodiment, the rollback operation indicates that the system should return to image A. In some embodiments, method (300) measures the updated current status and compares the measured value with a value stored in a register file. Upon detection of a match, method (300) may continue. If method (300) detects a mismatch, then method (300) may terminate or preemptively recover the device.

[0060] In block 322, after verifying the status information, method (300) begins to roll back to the previous software image. In the illustrated embodiment, method (300) performs this block by performing consecutive write operations on the active storage space using data stored in the second portion. Simultaneously, method (300) also updates the status information with the expected measurement of the software image after each consecutive write, thus ensuring that the rollback can continue even in the event of power loss or other interruptions.

[0061] In box 324, method (300) restarts the device and the process can restart method (300). In this scenario, if method (300) completely rolls back the update, then the decision in box 318 branches to box 306. Alternatively, if method (300) interrupts the intermediate rollback, then method (300) will eventually return to box 320 to continue the rollback.

[0062] Alternatively, method (300) may determine that the status information indicates an update should be initiated. In this scenario, in block 326, method (300) initiates an update to the updated image (image B) and incrementally updates the status information. Similar to the operation described in block 322, method (300) accesses the updated image stored in the second part and continuously writes data to the third part to update the software. Simultaneously, method (300) also updates the status information with the expected measurement of the updated software image after each continuous write, thus ensuring that the update can continue even in the event of power loss or other interruptions.

[0063] In box 328, method (300) restarts the device after all writes have been performed and method (300) restarts. This is similar to what is described with respect to box 324. If the update is complete, then method (300) will eventually return to box 306. However, if the update is interrupted, then method (300) will eventually branch to box 330 to restart the update.

[0064] In block 330, method (300) verifies the status information after determining that the status information indicates an update operation is in progress. In some embodiments, method (300) measures the current status of the update and compares the measured value with a value stored in a register file. Upon detection of a match, method (300) may continue. If method (300) detects a mismatch, then method (300) may terminate or preemptively recover the device.

[0065] In block 332, method (300) continues to update the updated image (image B) and incrementally updates the status information. Similar to the operations described in blocks 322 and 326, method (300) accesses the updated image stored in the second part and continuously writes data to the third part to update the software. Simultaneously, method (300) also updates the status information with the expected measurement of the updated software image after each continuous write, thus ensuring that the update can continue even in the event of power loss or other interruptions.

[0066] In box 334, method (300) restarts the device after all writes have been performed and method (300) has restarted. This process is performed similarly to the restart described in box 328 to ensure that the restarted update is not stopped due to power loss.

[0067] Figure 4 The flowchart illustrates a method for performing runtime management updates according to some embodiments of the present disclosure. In the illustrated embodiments, the method (400) can be performed by a licensed user of the device.

[0068] In block 402, device startup is complete, the method connects to an authorized user, and requests an update to management operations. In some embodiments, the authorized user includes a remote user.

[0069] In block 404, the authorized user uploads status information and a second gold measurement from the device register to a remote server. In some embodiments, this information includes information generated by the device during the startup sequence, containing the gold measurement and the contents of the register. In some embodiments, the information is transmitted to the remote server only if an update is required. In some embodiments, the information is transmitted only if method (400) determines that the updated image has been fully written but the remainder of method (400) has not yet been executed. This allows for a restart after the write but before the update in method (400) is complete.

[0070] In box 406, method (400) compares the second measurement generated during startup (as described in the second part of box 206, alternatively referred to as the "software update buffer") with the second golden measurement. In other words, in box 310, the method compares the second measurement of the second part with the second golden measurement associated with the updated image and the second golden measurement associated with the previous image. The updated image and the previous image are referred to as image B and image A, respectively.

[0071] In block 408, method (400) compares the second measurement with the golden ratio of the updated image (the image stored in the second part) and the golden ratio of the previous image (the image cached from the second part). In block 408, method (400) determines whether the calculated value matches image A, image B, or another value. The current golden ratio of the second part is referred to as golden ratio B, while the cached golden ratio of the second part is referred to as golden ratio A. As described above, the second measurement refers to the hash of the updated image itself. Therefore, method (400) compares the value of the updated data to be applied with existing known golden ratios. In the illustrated embodiment, the second measurement refers to the measurement of the second part executed at startup time.

[0072] In box 410, the method completes the update procedure after determining that the second measurement matches the golden ratio of image B (the updated image). In this scenario, the update is successfully completed, and the updated image content is expected to be in active storage. Therefore, method (400) can safely complete the update process. Figure 5 The update procedure is described in more detail below.

[0073] In box 412, method (400) determines that the second measurement matches the gold measurement A (as associated with the previous image A). In this scenario, method (400) cancels the current update and then completes the software update by verifying that the software has been restored to the state before the update was initiated. In this scenario, method (400) has been restored to the previous image (e.g., via the rollback operation performed in boxes 320, 322, 324). Therefore, method (400) cancels the update procedure (i.e., by updating the status register) and continues to complete the update. Figure 5 The program in the middle.

[0074] If the second measurement does not match the second gold measurement A or B, then method (400) proceeds to block 414. In block 414, method (400) determines that the active storage space contains potentially corrupted data. However, method (400) first determines whether several update retries have been performed. As described above, a counter can be used to control the number of update attempts before a transmission failure. It is worth noting that, although Figure 3 The method described in the diagram ultimately results in either image A or image B being written to the operational storage space, but a malicious user could intercept the update process and write another image to the operational storage space after box 306. Therefore, the decision in box 414 prevents this hijacking.

[0075] In block 416, method (400) reinitializes the system state to force the update sequence to restart. As described herein, a security device includes one or more registers that persistently store the state of the device between restarts. In block 416, method (400) modifies this system state to indicate that the device should restart. Figure 5 The device is restarted in an initialized state at box 502. Method (400) then restarts the device (418) and continues to execute. Figure 5 The restart routine described in (box 420).

[0076] In block 422, method (400) detects a corrupted state and changes the system state accordingly. In one embodiment, method (400) modifies a system register to indicate that a rollback operation should occur. Details regarding the rollback operation are provided in Figure 5 Next, method (400) forces the system to recover (424). Method (400) then forces the security device to restart (box 426) to achieve system recovery. After restarting, method (400) then executes... Figure 5 The restart routine described in (box 420).

[0077] Figure 5 This is a flowchart illustrating a method for performing a software update according to some embodiments of the present disclosure. In the illustrated embodiments, the method (500) can be performed by a licensed user of the device.

[0078] In block 502, method (500) requests additional measurements of the operational storage space of the secure storage device. As described above, these measurements may include encrypted measurements of the operational storage space.

[0079] In box 504, method (500) compares the additional measurement with the gold measurement of both the previous software image and the updated software image. If the additional measurement does not match the desired gold measurement (based on the decision to update or restore), then method (500) proceeds to box 506.

[0080] In box 506, method (500) issues an alert. The specific details of the alert are not intended to be limiting and any techniques may be used to issue an alert in response to a corrupted state. For example, method (500) may notify a third party that the active storage space is in an invalid state. Alternatively, or in combination with the foregoing, method (500) may warn a user that the active storage space is in an invalid state.

[0081] In block 508, method (500) then cleans the device or, in some embodiments, disables it. In one embodiment, method (500) cleans the device by formatting a relevant portion of the secure storage device to prevent device operation. In other embodiments, method (500) may simply power off the device or otherwise gradually disable it. After executing block 508, method (500) terminates.

[0082] In block 510, method (500) locks the active storage space in response to determining that an additional measurement matches the desired gold measurement. In one embodiment, a known encryption key is used to perform the locking of the active storage space.

[0083] In block 512, after locking the active storage space, method (500) requests a second additional measurement of the active storage space of the secure storage device. As described above, this second measurement may include an encrypted measurement of the active storage space. Method (500) then compares the second additional measurement with both the gold measurement of the previous software image and the updated software image. If the additional measurement does not match the desired gold measurement (based on the update or restore decision), then method (500) proceeds to blocks 506 and 508. Blocks 506 and 508 have been previously described and will not be repeated herein.

[0084] In blocks 514 and 516, method (500) restores previously stored data in memory to its original location. In the illustrated embodiment, this previously stored data includes a recovery block image, register contents, and the contents of the first and second portions of the secure storage device. In one embodiment, when restoring the previous contents of the first and second portions of the secure storage device, method (500) configures the first and second portions to be write-enabled.

[0085] In block 518, method (500) transmits a completed update. In some embodiments, a completed update may include launching the device using a new software image. Alternatively or in conjunction with the foregoing, method (500) may generate an external signal indicating that the device has been updated and is ready for operation.

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

[0087] In the illustrated embodiment, the computing device (600) is communicatively coupled to a bus (608) via an interface (606). The bus (608) may include Ethernet, Controller Area Network (CAN), FlexRay, Media-Oriented System Transport (MOST) bus, or a similar type of bus. Correspondingly, the interface (606) may include a similar interface for accessing the specific type of bus used.

[0088] The computing device (600) further includes a microcontroller (602), an R / F subsystem (610), an ASC (612), and a memory system (604). In the illustrated embodiments, the microcontroller (602) may include a processor or a smaller microcontroller configured to control the operation of the computing device (600). In some embodiments, the microcontroller (602) accesses program instructions stored in the memory system (604) and drives the ASC (612) according to those instructions. Examples of ASCs (612) include peripheral devices and other purpose-specific (e.g., automotive) devices. The type of ASC used by the computing device (600) is not limiting and any type of ASC may be used by the computing device (600).

[0089] The computing device (600) further includes an R / F system (610). In the illustrated embodiments, the R / F system (610) may include one or more radio devices or transceivers for communicating with a wireless network. The R / F system (610) may include Bluetooth, Wi-Fi, or cellular radio devices or satellite transceivers. In some embodiments, the R / F system (610) includes a combination of radio devices or transceivers. In some embodiments, the computing device (600) may not include an R / F system (610) and may alternatively utilize a vehicle-range R / F system as previously described.

[0090] The microcontroller (602) manages the memory system (604). In the illustrated embodiment, the memory system (604) may include a secure storage device as previously described. In the illustrated embodiment, the memory system (604) includes SRAM (604a), EEPROM (604b), and flash storage device (604c). In the illustrated embodiment, the SRAM (604a) may be used as an L1 or L2 cache of the microcontroller (602). Similarly, the EEPROM (604b) may be used as a firmware storage device of the computing device (600). Specific details (or the presence) of the SRAM (604a) and EEPROM (604b) are not limiting.

[0091] The memory system (604) further includes a flash memory device (604c). In the illustrated embodiment, the flash memory device (604c) includes components soldered to and connected (via the PCB) to... Figure 6 The other components depicted are NAND flash memory devices. As previously described, the flash memory device (604c) is used to store operation codes and data used by the computing device (600).

[0092] Figure 7 This is a block diagram showing the layout of a storage device according to some embodiments of the present disclosure.

[0093] In the described storage system (700), there are two logical storage spaces: device storage space (702) and authorized user (PU) storage space (710). Generally, space (702) can be accessed by any non-authorized user by default, while space (710) can only be accessed by authorized users.

[0094] The device storage space (702) contains an image of the software in operation (image A, 704). This image (704) may include the software currently executing on the device. Additionally, the device storage space (702) includes a secure storage space (706) containing an encryption key (706a), a set of registers (706b), and a recovery block (706c). In one embodiment, the secure storage space (706) is encrypted so that only a user (e.g., an authorized user) can access the secure storage space (706) using an established key. Finally, the device storage space (702) includes a general space (708) comprising a first portion (708a), a second portion (708b), and a third portion (708c). Generally, the general space (708) is accessible to both authorized and unauthorized users and can be configured to be write-protected as needed. When write protection is enabled, only authorized users can modify the contents of the write-protected portion.

[0095] The PU storage space (710) includes a secure storage area accessible only to authorized users. The PU storage space (710) may contain copies of the original image A (712) and the updated image B (714). Additionally, the PU storage space (710) contains an encryption key (716) for accessing the secure storage space (706) and any write-protected portions (708a, 708b). Furthermore, the PU storage space (710) includes a spare space (718). This spare space (718) includes storage portions that can be used to back up copies of the first portion (718a), the second portion (718b), the registers (718c), and the recovery block (718d), as described in the previous figures.

[0096] This disclosure has been described more fully below with reference to the accompanying drawings, which form part of this disclosure and illustrate certain exemplary embodiments by means of illustration. However, the subject matter may be implemented in many different forms and is therefore intended to be understood as not being limited to any of the exemplary embodiments set forth herein. Exemplary embodiments are provided merely for illustration. Likewise, a reasonably broad scope is intended for the claimed or covered subject matter. Among other things, the subject matter may be embodied as a method, apparatus, component, or system, for example. Therefore, embodiments may take the form of, for example, hardware, software, firmware, or any combination thereof (other than software itself). Thus, the following detailed description is not intended to be restrictive.

[0097] Throughout the specification and claims, terms may have nuanced meanings implied or suggested by the context, beyond their expressly stated meanings. Similarly, the phrase "in one embodiment" as used herein does not necessarily refer to the same embodiment, and the phrase "in another embodiment" as used herein does not necessarily refer to different embodiments. For example, the claimed subject matter is intended to encompass combinations of all or part of the exemplary embodiments.

[0098] Generally, terms can be understood at least partially based on their use in context. For example, terms such as “and,” “or,” or “and / or,” as used above, can have multiple meanings that depend at least in part on the context in which such terms are used. Typically, “or,” if used with an associative list (e.g., A, B, or C), is intended to mean A, B, and C, used here in an inclusive sense; and A, B, or C, used here in an exclusive sense. Additionally, depending at least in part on the context, the term “one or more” as used herein can be used to describe any feature, structure, or characteristic in a singular sense, or to describe a combination of features, structures, or characteristics in a plural sense. Similarly, depending at least in part on the context, terms such as “a (a / an)” or “described” can be understood to convey either singular or plural usage. Furthermore, the term “based on” can be understood to not necessarily be intended to convey a set of exclusive factors, and, conversely, can allow for additional factors that are not necessarily explicitly described, depending at least in part on the context.

[0099] This disclosure has been described with reference to block diagrams and operating instructions of methods and apparatus. It should be understood that each block of the block diagram or operating instruction, and combinations of blocks in the block diagram or operating instruction, can be implemented by means of analog or digital hardware and computer program instructions. These computer program instructions are available to a general-purpose processor, special-purpose computer, ASIC, or other programmable data processing apparatus, causing the instructions, executed via the processor of the computer or other programmable data processing apparatus, to implement the functions / actions specified in the block diagram or one or more operating blocks. In some alternative embodiments, the functions / actions marked in the blocks may occur in a different order than those marked in the operating instructions. For example, depending on the functionality / action involved, two blocks shown consecutively may actually be performed substantially simultaneously, or the blocks may sometimes be performed in reverse order.

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

Claims

1. A method for executing a startup time sequence, the method comprising: The storage space of the secure storage device is initialized into multiple parts; The update program is copied to the first part of the section and the update data is copied to the second part of the section; Generate a first gold measurement value for the first part and a second gold measurement value for the second part; Measure the first part; In response to determining that the measurement of the first part does not match the first gold measurement value of the first part, the update of the secure storage device is updated or rolled back; After determining that the measurement in the first part matches the first gold measurement value in the first part, the second gold measurement value is calculated and the start-up time sequence is completed; as well as Verify the update operation after completing the startup time series. The first gold measurement value and the second gold measurement value are values ​​used to securely identify the software.

2. The method of claim 1, wherein the initialization of the storage space is performed in response to receiving a software update.

3. The method of claim 1, further comprising modifying the recovery block of the storage space to point to a first-level boot loader FSBL, the FSBL being configured to transfer control to the first portion.

4. The method of claim 3, further comprising restarting the secure storage device after generating the first gold measurement value and the second gold measurement value.

5. The method of claim 3, wherein the update or rollback of the update to the secure storage device comprises: The FSBL is executed and control of the secure storage device is transmitted to the update program; Read the contents of one or more status registers, which store the status of the secure storage device; as well as The secure storage device is updated after the status register indicates that an update should be initiated or that an update is currently being performed.

6. The method of claim 5, wherein the update comprises continuously writing data from the second portion into the active storage space.

7. The method of claim 6, wherein the continuous writing of data further includes updating the status register simultaneously after each write.

8. The method according to claim 1, wherein the verification update operation comprises: Measure the second part; and The measurement value of the second part is compared with the measurement value of the second gold.

9. The method of claim 8, further comprising one or more of the following: The sequence update restarts after determining that the measured value of the second part does not match the first gold measurement value or the second gold measurement value and before the retry count has been exceeded; The update sequence is cancelled after it is determined that the measured value of the second part does not match the first gold measurement value or the second gold measurement value and the number of retries has been exceeded; The secure storage device is restored after it is determined that the measured value of the second part does not match the second gold measurement value and does not match the previously stored second gold measurement value; as well as If the measured value of the second part is equal to the second gold measured value, then the update sequence is completed.

10. The method of claim 9, wherein completing the update sequence includes measuring the operational storage space of the secure storage device and confirming that the measured value matches the expected value.

11. A non-transitory computer-readable storage medium for tangibly storing computer program instructions executable by a computer processor, the computer program instructions defining the following steps: The storage space of the secure storage device is initialized into multiple parts; The update program is copied to the first part of the section and the update data is copied to the second part of the section; Generate a first gold measurement value for the first part and a second gold measurement value for the second part; Measure the first part; In response to determining that the measurement of the first part does not match the first gold measurement value of the first part, the update of the secure storage device is updated or rolled back; After determining that the measurement in the first part matches the first gold measurement value in the first part, the second gold measurement value is calculated and the start-up time series is completed; as well as Verify the update operation after completing the startup time series. The first gold measurement value and the second gold measurement value are values ​​used to securely identify the software.

12. The non-transitory computer-readable storage medium of claim 11, wherein the initialization of the storage space is performed in response to receiving a software update.

13. The non-transitory computer-readable storage medium of claim 11, further comprising modifying a recovery block of the storage space to point to a first-level boot loader FSBL, the FSBL being configured to transfer control to the first portion.

14. The non-transitory computer-readable storage medium of claim 13, further comprising restarting the secure storage device after generating the first gold measurement and the second gold measurement.

15. The non-transitory computer-readable storage medium of claim 13, wherein the update or rollback of the secure storage device comprises: The FSBL is executed and control of the secure storage device is transmitted to the update program; Read the contents of one or more status registers, which store the status of the secure storage device; as well as The secure storage device is updated after the status register indicates that an update should be initiated or that an update is currently being performed.

16. The non-transitory computer-readable storage medium of claim 15, wherein the update comprises continuously writing data from the second portion into the active storage space.

17. The non-transitory computer-readable storage medium of claim 16, wherein the continuous write data further includes updating the status register simultaneously after each write.

18. The non-transitory computer-readable storage medium of claim 11, wherein the verification update operation comprises: Measure the second part; and The measurement value of the second part is compared with the measurement value of the second gold.

19. The non-transitory computer-readable storage medium of claim 18, further comprising one or more of the following: The sequence update restarts after determining that the measured value of the second part does not match the first gold measurement value or the second gold measurement value and before the retry count has been exceeded; The update sequence is cancelled after it is determined that the measured value of the second part does not match the first gold measurement value or the second gold measurement value and the number of retries has been exceeded; The secure storage device is restored after it is determined that the measured value of the second part does not match the second gold measurement value and does not match the previously stored second gold measurement value; as well as If the measured value of the second part is equal to the second gold measured value, then the update sequence is completed.

20. An apparatus for executing a startup time sequence, the apparatus comprising: processor; and A storage medium for tangibly storing program logic executable by the processor, the stored program logic including instructions that cause the processor to perform the following operations: The storage space of the secure storage device is initialized into multiple parts; The update program is copied to the first part of the section and the update data is copied to the second part of the section; Generate a first gold measurement value for the first part and a second gold measurement value for the second part; Measure the first part; In response to determining that the measurement of the first part does not match the first gold measurement value of the first part, the update of the secure storage device is updated or rolled back; After determining that the measurement in the first part matches the first gold measurement value in the first part, the second gold measurement value is calculated and the start-up time sequence is completed; as well as Verify the update operation after completing the startup time series. The first gold measurement value and the second gold measurement value are values ​​used to securely identify the software.

Images