Managing repair of write limited memory with hardware security module

Abstract

Embodiments of the present disclosure relate to managing repair of write limited memory with a hardware security module. Managing repair of write-limited memory with a hardware security module (HSM) including a plurality of one-time programmable (OTP) memory blocks, where each OTP memory block is associated with a respective identification value, including: receiving a patch management request from a repair entity, the patch management request comprises a first identification value, an identity token, an encryption key and a signature object, and the first identification value is associated with an OTP memory block of a plurality of OTP memory blocks of the HSM; comparing, by the HSM, the identity token and the encryption key with a corresponding identity token and a corresponding encryption key stored in the HSM; verifying, by the HSM, a signature object of the patch management request; configuring patch codes; and installing the patch code in the write limited memory.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to and the benefit of U.S. Provisional Application Serial No. 63 / 547,836, filed on November 8, 2023, entitled “Hardware Security Module (HSM) Protected Patching,” the entire disclosure of which is incorporated herein by reference. Technical Field

[0003] The present disclosure relates to managing patching of write-restricted memory using a hardware security module. Background Art

[0004] System architectures are increasingly being adopted in a range of applications from automotive systems, smart home automation to industrial production line systems. In some implementations, system architectures can control or enable program execution within a larger system to perform a wide range of functions. Some system architectures can facilitate complex operations such as real-time data processing, sensor integration, and automated decision making. In some implementations, system architectures may include one or more integrated circuits that are combined into system-on-chip (SOC) devices. Some integrated circuits may include components such as transistors, resistors, and capacitors. Some SOCs may include hardware security modules (HSMs). Some HSMs are hardened tamper-resistant hardware devices that protect encryption processes by generating, protecting, and managing keys used to encrypt and decrypt data and create digital signatures and certificates. Summary of the invention

[0005] In one aspect, in general, a method for managing patching of a write-restricted memory using a hardware security module (HSM), the HSM comprising a plurality of one-time programmable (OTP) memory blocks, wherein each OTP memory block is associated with a corresponding identification value, the method comprising: receiving a patch management request from a patching entity, the patch management request comprising a first identification value, an identity token, an encryption key, and a signature object, the first identification value being associated with an OTP memory block among the plurality of OTP memory blocks of the HSM; comparing, by the HSM, the identity token and the encryption key with a corresponding identity token and a corresponding encryption key stored in the HSM; verifying, by the HSM, the signature object of the patch management request; configuring a patch code; and installing the patch code in the write-restricted memory.

[0006] Aspects may include one or more of the following features.

[0007] The method also includes deactivating the OTP memory block associated with the first identification value.

[0008] Configuring the patch code also includes: checking whether the patch code has errors and loading the patch code into a random access memory (RAM) of the HSM.

[0009] The patch code is loaded into the RAM of the HSM from the OTP memory block of the HSM associated with the third identification value.

[0010] The method also includes activating the OTP memory block associated with the second identification value.

[0011] The second identification value is determined based at least in part on a comparison of a size of the patch code and a size of an OTP memory block associated with the second identification value.

[0012] The patch management request also includes the patch code.

[0013] On the other hand, in general, a method for managing patching of a write-restricted memory of a system architecture manufactured by a first entity, wherein the system architecture includes a hardware security module, the method comprising: generating, by a second entity different from the first entity, a cryptographic key associated with the system architecture; storing the cryptographic key associated with the system architecture in the hardware security module of the system architecture; configuring, by the first entity, patch code associated with the write-restricted memory of the system architecture; generating, by the second entity, a patch management request associated with a signature object, wherein the signature object is generated at least in part based on the cryptographic key associated with the system architecture; and providing the patch management request to the system architecture.

[0014] Aspects may include one or more of the following features.

[0015] The write restricted memory of the system architecture includes one or more one-time programmable fuses.

[0016] The method also includes verifying the signed object of the patch management request based at least in part on a comparison of the signed object and a cryptographic key associated with the system architecture.

[0017] Verification of the signature object of the patch management request is performed by the hardware security module.

[0018] The method also includes deactivating one or more blocks of the write restricted memory based at least in part on the patch management request.

[0019] The hardware security module includes at least a portion of a write restricted memory.

[0020] Patch management requests include patch codes.

[0021] On the other hand, in general, a device includes: a write-restricted memory; a hardware security module (HSM), the HSM including a memory module, the memory module including multiple one-time programmable (OTP) memory blocks, each OTP memory block is associated with a corresponding identification value; and a processor circuit device, the processor circuit device is configured to manage patching of the write-restricted memory, the management including: receiving a patch management request from a patching entity, the patch management request including a first identification value, an identity token, an encryption key, and a signature object, the first identification value is associated with an OTP memory block among the multiple OTP memory blocks of the HSM, the HSM comparing the identity token and the encryption key with a corresponding identity token and a corresponding encryption key stored in the HSM, the HSM verifying the signature object of the patch management request, configuring patch code, and installing the patch code in the write-restricted memory.

[0022] Aspects may include one or more of the following features.

[0023] The write restricted memory includes one or more OTP fuses.

[0024] The hardware security module includes at least a portion of a write restricted memory.

[0025] On the other hand, in general, an apparatus includes: a write-restricted memory; a hardware security module (HSM), the HSM including a memory module, the memory module including multiple one-time programmable (OTP) memory blocks, each OTP memory block being associated with a corresponding identification value; and a component for managing patching of the write-restricted memory, the management including: receiving a patch management request from a patching entity, the patch management request including a first identification value, an identity token, an encryption key, and a signature object, the first identification value being associated with an OTP memory block among multiple OTP memory blocks of the HSM, the HSM comparing the identity token and the encryption key with corresponding identity tokens and corresponding encryption keys stored in the HSM, the HSM verifying the signature object of the patch management request, configuring patch code, and installing the patch code in the write-restricted memory.

[0026] Aspects may include one or more of the following features.

[0027] The write restricted memory includes one or more OTP fuses.

[0028] The hardware security module includes at least a portion of a write restricted memory.

[0029] Aspects may have one or more of the following advantages.

[0030] In some implementations, the methods and systems disclosed herein can be utilized to perform secure patching of write-restricted memory associated with a system architecture. In some implementations, the secure patching can be performed by an authorized user of the SOC.

[0031] Other features and advantages will be apparent from the following description and from the drawings and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] The present disclosure is best understood from the following detailed description when read in conjunction with the accompanying drawings. It should be emphasized that, according to common practice, the various features in the drawings are not drawn to scale. Instead, the sizes of the various features are arbitrarily enlarged or reduced for clarity.

[0033] Figure 1 is a schematic diagram of an example method for patching write-restricted memory.

[0034] Figure 2 is a schematic diagram of an example method for patching write-restricted memory.

[0035] Figure 3 is a schematic diagram of an example implementation for OTP patch control.

[0036] Figure 4 is a schematic diagram of an example method for patching write-restricted memory. DETAILED DESCRIPTION

[0037] Some SOCs may include write-restricted memory that has restrictions on the types of operations that can be used to write into such memory. Some forms of such write-restricted memory are called read-only memory (ROM), which can store firmware that cannot be physically modified by typical memory write operations, which may require special operations to write or erase and rewrite the contents of such memory. In some examples, the ROM may be an electrically erasable programmable read-only memory (EEPROM). Since some forms of ROM have tamper-proof properties, the SOC may use the ROM to store the root of trust initial boot sequence and / or retain critical security code so that the code can remain isolated. In such implementations, the ROM may be called BootROM. If a fault or problem is found after something is physically submitted to the ROM, the cost of repairing the fault or problem may be very high, and traditionally, the chip layer may need to be redesigned. In some implementations, a patch content (such as code) may be used to repair a fault or problem of the ROM. In some implementations, an HSM associated with the SOC may be used to protect and manage the ROM patch content so that the patch content can only be applied by authorized users of the SOC.

[0038] Some HSMs may include multiple one-time programmable (OTP) bits. Some OTP bits include fuses that are configured to be programmed once by shorting the gate and source of a transistor to create a permanent data state associated with the OTP bit. In some implementations, placing the OTP content within the HSM can provide additional protection and straightforward management, as the same concepts as managing keys in the OTP can be applied. In some implementations, an OTP patch block or OTP memory block can be created by partitioning multiple OTP bits.

[0039] Figure 1 An example implementation 100 for managing patching of a ROM 106 of an example SOC 102 is depicted. The SOC 102 includes an HSM 104 and a ROM 106. The HSM 104 includes a plurality of OTP memory blocks 108A-108N, wherein each OTP memory block 108A-108N is associated with a corresponding identification value (not shown). The HSM 104 also includes a RAM 110 and a memory 112. The SOC 102 receives a patch management request 116 from a patching entity 114. The patch management request 116 includes a first identification value, an identity token, an encryption key, and a signature object associated with the OTP memory blocks 108A-108N. The HSM 104 compares the identity token and the encryption key with a corresponding identity token and a corresponding encryption key stored in the memory 112. The HSM 104 also verifies the signature object of the patch management request. Then, the patch code is configured and installed on the ROM 106. In some implementations, the patch code may be installed in the OTP memory bank 108A and loaded 118 into the RAM 110 for testing. The patch code may then be installed 120 into the ROM 106.

[0040] In some implementations, the SOC may include a processor circuit device including a processor core configured to manage patching of the ROM. In some examples, the HSM may include one or more processor cores. In some implementations, one or more processor cores may be located outside the HSM. Some SOCs may be configured to have one or more processor cores in the HSM and one or more processor cores outside the HSM.

[0041] In some implementations, the HSM may include an instruction ROM (iROM) that can be used with Figure 1 In some implementations, the HSM may include an OTP memory block for patching an iROM or BootROM associated with the SOC.

[0042] In some implementations, each OTP memory block may be protected by an error correction code (ECC). In some implementations, each OTP memory block may have an associated partition management control signal. Some partition management control signals may include a deactivation control to allow individual enabling or disabling of patch blocks. Some partition management control signals may include a patch buffer assignment to allow the HSM to direct the memory access (DMA) patch content of the enabled block to a specified SOC buffer address in a continuous order. In some implementations, managing ROM patching may include pre-assigning a system memory buffer to allow the HSM to output all OTP-deployed ROM patch code images to the system memory buffer via the HSM direct memory access (DMA) controller at each SoC reset. The SoC BootROM may apply the ROM patch code image from the system memory buffer to the ROM code image, and then the patched ROM code may be executed.

[0043] In some implementations, HSM primitives can be provided to facilitate the loading of patches. By setting the patch buffer address for the BootROM, patches can be installed or revoked at any time, including in the field. In some implementations, patches can be managed while the device is in the provisioning lifecycle. The following are some examples of HSM primitives:

[0044] HSM_BootROM_Patch_Address - Specifies a 64-bit system physical address that will be used to move all BootROM related OTP patch blocks by using HSM DMA. The BootROM can then copy itself to local RAM, fetch the patch contents from the buffer address and overwrite the applicable area in local RAM. The patch contents can then be executed from local RAM. In some implementations, this primitive can only be satisfied when the HSM lifecycle is in the PROVISION state.

[0045] HSM_BootROM_Patch_Provision - This primitive can be used to program the next available BootROM OTP block(s) in sequence with the specified patch material. Once programmed, the HSM can generate the ECC for the programmed block, program the ECC into the OTP and set the active control bits for the programmed block. In some implementations, this primitive can only be used for OTP blocks that have not been previously programmed.

[0046] HSM_IROM_Patch_Provision - This primitive can be used to program the next available iROM OTP block(s) in sequence with the specified patch material. Once programmed, the HSM can generate the ECC for the programmed block, program the ECC into the OTP, and set the active control bits for the programmed block. In some implementations, this primitive can only be used for OTP blocks that have not been previously programmed.

[0047] In some implementations, existing HSM authentication principles can be used to protect patch installation before allowing the patch to proceed. In some implementations, the device can be configured to have one or more boot states, each of which is associated with different security permissions. In some implementations, authentication can include one or more of the following steps. (1) The device can be in at least a PRIVISION state and can lock secure boot / encrypted boot / measured boot. (2) Verify the input token and public key based on the unrevoked key authentication key (KAK) currently deployed in the HSM. (3) Verify the digital signature using the selected unrevoked KAK public key of the request group that includes the primitive type. (4) Check the available free OTP blocks for the BootROM or iROM based on the size of the input patch content.

[0048] In some implementations, managing patches can be associated with resetting the SOC to boot the device into a different boot state. In some implementations, after the SOC is reset, the HSM can provide two status bits through a shadow register configured to save data to be used later. These status bits can indicate the readiness status of the patch code for the BootROM, which can be "loading", "ready", and "no patch". If patch code exists, the HSM can perform ECC on the programmed block and DMA the content to the address programmed in the patch buffer address. The HSM can then set the ready status bit. In some implementations, when the "loading" bit is set, the target SOC BootROM can wait for the "ready" bit to be set before continuing to apply the patch. In some examples, if the BootROM patch block is not programmed, the target BootROM will not wait for the patch because the status bit will indicate "no patch".

[0049] In some implementations, one or more OTP memory blocks of the HSM may be pre-programmed with patch code. In some examples, if any dedicated OTP patch blocks of the eHSM have been programmed, the HSM may perform ECC on the activated patch blocks, and if no uncorrectable errors are found, the HSM may copy the patch blocks to private dedicated static random access memory (SRAM). The patch material may then selectively overwrite functions or variables by modifying the corresponding function pointers or variable pointers in the function or variable descriptors.

[0050] Without using the methods disclosed herein, some examples of conventional ROM patching may be managed by an entity such as a silicon company that manufactures the SoC. In such examples, the authentication key may be hard-coded in the silicon resistor transistor logic (RTL) circuitry. Thus, all OEMs / ODMs may have the same ROM code patching authentication key. This key similarity may be problematic in terms of liability management once the device has been deployed to the end market.

[0051] In contrast, when utilizing the methods disclosed herein, an original equipment manufacturer (OEM), an original device manufacturer (ODM), or an owner of a SoC-powered device manufactured by a different entity can deploy their own authentication keys. This deployment can allow the device owner to have an authentication key and assume the responsibility of managing ROM code patching by allowing the device owner to deploy the device as ROM patchable or ROM schedulable. In some examples, the deployment of the device owner's authentication key can occur when the device is in a PROVISION state. In some examples, the PROVISION state can be associated with a device manufacturing process. After the manufacturing process, the device can proceed to a DEPLOY state. In some implementations, for security and reliability, some devices may not allow the deployment of the device owner's authentication key.

[0052] In some examples, for ROM patchable devices, each ROM patch code can be digitally signed using the device owner's signing key. In some examples, the device owner can also be responsible for managing the revocation of certain deployed ROM patch codes with security vulnerabilities. In some implementations, the use of an HSM can support the revocation of privileges associated with ROM patch codes with security vulnerabilities through authentication.

[0053] Figure 2An example implementation 200 for managing patching of a read-only memory 202 of a system architecture 204 manufactured by a first entity 206 is depicted. The system architecture 204 includes an HSM 208. A second entity 210 generates 212 an encryption key associated with the system architecture 204 and stores the encryption key in a key slot 214 in the HSM 208. The first entity 206 configures the read-only memory 202 with patch code 216. The second entity 210 generates a patch management request (not shown) associated with a signature object, wherein the signature object is generated based at least in part on the encryption key. The patch management request is then provided 218 to the system architecture. In some examples, the HSM 208 may also include a RAM 220 and a plurality of OTP memory blocks 222A-222N.

[0054] In some implementations, using an HSM for patching can allow OTP patch blocks to be securely enabled / disabled when the device is deployed in the field. In some examples, the HSM can leverage existing authentication commands based on challenge and response to verify the requester. Examples of authentication commands can be found below:

[0055] HSM_BootROM_Patch_Revocate - This authentication command can be used to deactivate a patch based on a specified OTP block number. In some examples, the OTP block can be in an active state. After a successful authentication request, the corresponding block number in the BootROM portion of the patch management area can be marked as deactivated, and the block is no longer used for patching during the useful life of the SOC.

[0056] HSM_iROM_Patch_Revocate - This authentication command can be used to deactivate a patch based on a specified OTP block number. In some examples, the OTP block can be in an active state. After a successful authentication request, the corresponding block number in the IROM portion of the patch management area can be marked as deactivated and the block is no longer used for patching during the useful life of the SOC.

[0057] In some examples, the authentication command can be configured to formulate a challenge response in one or more of the following ways: (1) Global challenge: This value can be configured across a subset of devices. (2) Universally unique identifier (UUID): A unique ID specific to the chip. (3) Random number generated by a deterministic random bit generator (DRBG) intellectual property (IP) module.

[0058] In some implementations, the patch management request may include one or more of the following data:

[0059] (1) HSM_BootROM_Patch_Revocate / HSM_iROM_Patch_Revocate command ID. (2) Challenge: global / UUID / random number. (3) Starting OTP block number to be deactivated. (4) Ending OTP block number to be deactivated (can be the same). (5) Token. (6) Public key. (7) Digital signature.

[0060] In some examples, the HSM can verify the input token and public key against an unrevoked key authentication key (KAK) currently provisioned in the HSM. The HSM can then verify the digital signature using the selected unrevoked KAK public key found in the command packet. In some examples, if these checks pass and the specified OTP blocks are active, the HSM can proceed to deactivate them.

[0061] In some implementations, a token may be implemented to establish an enhanced multi-factor authentication mechanism to manage ROM patch binary images within an HSM electronic fuse (eFUSE) macro. In some implementations, a public key may be generated by implementing an algorithm or technique such as Rivest-Shamir-Adleman (RSA) or elliptic curve encryption. Public key encryption may also be referred to as asymmetric encryption because anyone can use a public key to encrypt data, but only the holder of a paired private key can decrypt the data. In some implementations, a public key may be deployed in an HSM eFUSE macro to be used to verify the digital signature of a ROM patch binary image and to authorize the revocation or invalidation of some deployed ROM patch code binary files. In some implementations, a digital signature may be generated using an algorithm such as a digital signature standard. Some digital signatures may provide authentication of the identity of the sender of the data and / or ensure that the content has not been modified since the signature. In some examples, a hash function may also be used.

[0062] In some implementations, other features may be included to enhance the robustness associated with ROM patching. For example, the HSM may provide a soft OTP burn mechanism and / or a cyclic redundancy code (CRC) protection mechanism. Some examples of soft OTP memory can only retain content at reset, but not at cold boot. The device owner can use the soft OTP burn mechanism to deploy candidates for ROM patch code, and after soft resetting the SOC, the ROM code will apply the ROM patch code and test whether the newly patched code works. Some examples of soft OTP can simulate real OTP, except that the patch content is not submitted to the device, so the reset can discard the data in the soft OTP. Some examples of soft OTP can work like real OTP when initially programmed, allowing the validity and application of the patch to be tested before programming or submitting to the real OTP. If the patched code does not fully work, the device owner can discard the ROM patch code. Only after the tested ROM path is established, the device owner can call the HSM primitive to commit the deployed content in the soft OTP to the OTP macro, which programs the OTP bits and makes the patch code permanent.

[0063] In some implementations, a CRC check mechanism can allow for process-free ROM patching prior to commencing platform boot with ROM patches. In some examples, if the CRC check fails, the HSM can be placed in a secure state by code from the BootROM or iROM. Some implementations of the secure state enable secure booting to the device owner's bootloader firmware (FW). The bootloader FW can then implement a ROM patch decertification protocol for managing ROM patch code deployed within the eHSM eFUSE OTP macro. In some implementations, this protocol can avoid device hang states associated with corruption or violations caused by incorrect patches.

[0064] Figure 3 An example implementation 300 for OTP patch control that can be included in an HSM module is depicted. The implementation 300 includes patch management 302, an ECC region 304, and a patch code region 306. In some implementations, the patch management 302 can include deactivation control and patch buffer addresses. Some examples of patch management 302 can support deployment or decertification. The ECC region 304 includes a plurality of ECC blocks 308A-308N. The patch code region 306 includes a plurality of OTP memory blocks 310A-310N. Each OTP memory block 310A-310N is associated with a different corresponding ECC block 308A-308N.

[0065] Figure 4An example method including steps 400A-400E associated with patching a device is depicted. The method includes a cold boot step 400A, a patch deployment step 400B, a reset and test phase step 400C, a patch submission step 400D, and a reset and boot step 400E. The device includes a boot medium 402, a boot CPU core 404, an HSM 406, a RAM 408, and an OTP fuse 410. The cold boot step 400A includes providing 412 a patched deployment image (PPI) from the boot medium 402 to the boot CPU core 404 on which the bootROM is running. In some examples, the HSM 406 can be used to verify the patch deployment image based on a digital signature within a trusted image module (TIM). The HSM performs 414 secure boot authentication. The patch deployment step 400B includes providing 416 a signed patch file from the boot medium 402 to the boot CPU core 404 on which the PPI is running. The HSM loads and deploys 418 the signed patch file from the boot CPU core 404 to the RAM 408. The reset and test phase step 400C includes providing 420 the PPI from the boot medium 402 to the boot CPU core 404 on which the bootROM is running. The HSM 406 can send (422 or 424) the patch from the RAM 408 to the HSM 406 (if the patch is for the HSM iROM) or the boot CPU core 404 (if the patch is for the bootROM). The HSM 406 performs 421 secure boot authentication. The patch submission step 400D includes providing the signed patch file 426 from the boot medium to the boot CPU core 404 on which the PPI is running. The HSM 406 obtains 428 the patch from the boot CPU core 404 and submits 430 the patch from the RAM 408 to the OTP fuse 410. The reset and boot step 400E includes providing 432 the boot loader from the boot medium 402 to the boot CPU core 404. The HSM 406 applies 434 the patch from the OTP fuse 410 to the HSM 406 (if the patch is for the HSM iROM) or to the boot CPU core 404 (if the patch is for the bootROM). The HSM 406 performs 438 secure boot authentication.

[0066] In some implementations, the PPI may be a binary file that executes on the SOC core and communicates with the HSM to properly push the patch.

[0067] In some implementations, the TIM is a binary header that contains information about how to boot. Some TIMs are not executable files and do not contain machine instructions. The TIM may also contain public components of keys used for secure boot and patching. In some examples, the body of the TIM may be covered by a digital signature. In some examples, the TIM may also contain hash values ​​of other images used in the secure boot process.

[0068] In some implementations, the HSM may allow two 8K of OTP bits to be dedicated to patching the HSM iROM and SoCBootROM. In some examples, the blocks of OTP bits may also be divided into 256-bit OTP patch blocks, each of which is protected by 18-bit ECC.

[0069] Although the present disclosure has been described in conjunction with certain embodiments, it should be understood that the present disclosure is not limited to the disclosed embodiments. Instead, the present disclosure is intended to cover various modifications and equivalent arrangements included within the scope of the appended claims, which scope should be given the broadest interpretation so as to cover all such modifications and equivalent structures permitted by law.

Claims

1. A method for managing patching of a write restricted memory using a hardware security module (HSM), the HSM comprising a plurality of one-time programmable (OTP) memory blocks, wherein each OTP memory block is associated with a corresponding identification value, the method comprising: receiving a patch management request from a patching entity, the patch management request comprising a first identification value, an identity token, a cryptographic key, and a signature object, the first identification value being associated with an OTP memory block of the plurality of OTP memory blocks of the HSM; comparing, by the HSM, the identity token and the encryption key with a corresponding identity token and a corresponding encryption key stored in the HSM; Verifying, by the HSM, the signature object of the patch management request; Configure patch code; as well as The patch code is installed in the write restricted memory. 2 . The method of claim 1 , further comprising deactivating the OTP memory block associated with the first identification value.

3. The method according to claim 1, wherein configuring the patch code further comprises: Check whether the patch code has any error, and load the patch code into a random access memory RAM of the HSM.

4. The method of claim 3, wherein the patch code is loaded into the RAM of the HSM from an OTP memory block of the HSM associated with a third identification value. 5 . The method of claim 1 , further comprising activating the OTP memory block associated with a second identification value.

6. The method of claim 1, wherein the second identification value is determined based at least in part on a comparison of a size of the patch code and a size of the OTP memory block associated with a second identification value. The method of claim 1 , wherein the patch management request further includes the patch code.

8. A method for managing patching of a write-restricted memory of a system architecture manufactured by a first entity, wherein the system architecture includes a hardware security module, the method comprising: generating, by a second entity different from the first entity, a cryptographic key associated with the system architecture; storing the cryptographic key associated with the system architecture in the hardware security module of the system architecture; configuring, by the first entity, patch code associated with the write restricted memory of the system architecture; generating, by the second entity, a patch management request associated with a signed object, wherein the signed object is generated based at least in part on the cryptographic key associated with the system architecture; and The patch management request is provided to the system architecture.

9. The method of claim 8, wherein the write restricted memory of the system architecture comprises one or more one-time programmable fuses.

10. The method of claim 8, further comprising verifying the signed object of the patch management request based at least in part on a comparison of the signed object and the cryptographic key associated with the system architecture.

11. The method of claim 10, wherein verifying the signed object of the patch management request is performed by the hardware security module.

12. The method of claim 8, further comprising deactivating one or more blocks of the write restricted memory based at least in part on the patch management request.

13. The method of claim 8, wherein the hardware security module comprises at least a portion of the write-restricted memory. The method of claim 8 , wherein the patch management request includes the patch code.

15. An apparatus comprising: Writing to restricted memory; Hardware Security Module HSM, including: a memory module comprising a plurality of one-time programmable (OTP) memory blocks, wherein each OTP memory block is associated with a corresponding identification value; and A processor circuit arrangement is configured to manage patching of the write restricted memory, the management comprising: receiving a patch management request from a patching entity, the patch management request comprising a first identification value, an identity token, a cryptographic key, and a signature object, the first identification value being associated with an OTP memory block of the plurality of OTP memory blocks of the HSM, comparing, by the HSM, the identity token and the encryption key with a corresponding identity token and a corresponding encryption key stored in the HSM, verifying, by the HSM, the signed object of the patch management request, Configure the patch code, and The patch code is installed in the write restricted memory.

16. The apparatus of claim 15, wherein the write restricted memory comprises one or more OTP fuses.

17. The apparatus of claim 15, wherein the hardware security module comprises at least a portion of the write-restricted memory.

18. An apparatus comprising: Writing to restricted memory; Hardware Security Module HSM, including: A memory module comprising a plurality of one-time programmable (OTP) memory blocks, wherein each OTP memory block is associated with a corresponding identification value; and means for managing patching of the write restricted memory, the managing comprising: receiving a patch management request from a patching entity, the patch management request comprising a first identification value, an identity token, a cryptographic key, and a signature object, the first identification value being associated with an OTP memory block of the plurality of OTP memory blocks of the HSM, comparing, by the HSM, the identity token and the encryption key with a corresponding identity token and a corresponding encryption key stored in the HSM, verifying, by the HSM, the signed object of the patch management request, Configure the patch code, and The patch code is installed in the write restricted memory.

19. The apparatus of claim 18, wherein the write restricted memory comprises one or more OTP fuses.

20. The apparatus of claim 18, wherein the hardware security module comprises at least a portion of the write restricted memory.

Images