Secure Upgrade of Firmware Update in Constrained Memory

• US 20090064125A1
• Filed: 09/05/2007
• Published: 03/05/2009
• Est. Priority Date: 09/05/2007
• Status: Active Grant

• Current Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Original Assignee: Microsoft Corporation
• Inventors: Venkatachalam, Rajagopal, Xu, Zhangwei
• Granted Patent: US 8,429,643 B2
• Time in Patent Office: Days
• US Class Current: 717/170
• CPC Class Codes: G06F 21/572 Secure firmware programming, e.g. of basic input output system [BIOS]
• CPC Class Codes: G06F 21/72 in cryptographic circuits
• CPC Class Codes: G06F 21/85 interconnection devices, e.g. bus-connected or in-line devices
• CPC Class Codes: G06F 8/65 Updates security arrangements therefor G06F21/57

Abstract

A hardware-based security module may contain executable code used to manage the electronic device in which the security module resides. Because the security module may have limited memory, a memory update process is used that allows individual blocks to be separately downloaded and verified. Verification data is sent in a header block prior to sending the individual data blocks.

Claims

1. A method of securely downloading an update to a constrained memory, the update including one header block and one or more body blocks, the method comprising:

a) receiving a header block of the update;

b) parsing the header block;

c) receiving a body block of the update;

d) confirming a digital signature of the body block;

e) storing the body block when the act of confirming is successful;

f) repeating steps c-e until each body block has been received;

g) committing the update when each body block has been received.

2. The method of claim 1, further comprising downloading the update when the act of confirming the digital signature fails for the body block.

3. The method of claim 1, further comprising operating from the update after all the body blocks have been received.

4. The method of claim 1, wherein parsing the header block comprises

decoding an encrypted portion of the header block;

and

confirming at least a portion of the header block.

5. The method of claim 1, further comprising confirming a signature of the header block.

6. The method of claim 1, wherein parsing the header block comprises parsing the header block into:

an update data header having a format version, an identifier, a signature size, a signature offset, an update size, and a body block size;

an update metadata record including an update type, an update version, a hardware identifier, a universal product identifier, and a target type;

a signature metadata record including a total count of body blocks, and a size of each body block; and

an update signature record having signature data for each body block.

7. The method of claim 1, wherein parsing the header block comprises parsing the header block into a signature block that contains a header digital signature for confirmation of the header block.

8. The method of claim 1, wherein committing the update comprises committing the update to a memory of a secure module of an electronic device.

9. The method of claim 1, wherein the update is one of a basic input/output system (BIOS) update and a firmware image of a security module.

10. A computer-readable medium having computer-executable instructions for implementing a method of securely downloading a memory update to a target device comprising:

dividing the memory update into blocks;

creating a respective hash corresponding to each of the blocks;

creating a header including each respective hash;

adding a target device identifying information to the header;

creating a digital signature of the header and attaching the digital signature to the header; and

sending the header to the target device.

11. The computer-readable medium of claim 10, further comprising:

receiving a confirmation verifying that the target device identifying information and the digital signature were accepted by the target device.

12. The computer-readable medium of claim 11, further comprising:

sending a first block to the target device responsive to the confirmation; and

sending a second block to the target device responsive to a second confirmation verifying that the first block was confirmed by the target device using the respective hash corresponding to the first block.

13. The computer-readable medium of claim 11, further comprising:

abandoning the method responsive to a negative confirmation.

14. The computer-readable medium of claim 11, wherein creating the header further comprises creating fields for an update data header record having a memory update format version field, a signature size field, a total header size field, a memory update size field, and a size field for each of the blocks.

15. The computer-readable medium of claim 11, wherein creating the header including each respective hash comprises creating an update hash record with a hash block field for each respective hash.

16. A computer with a security module adapted to receive and verify a memory update, the security module comprising:

a processor;

a port for receiving the memory update;

a bus connecting the processor to the port;

the security module coupled to the bus and having a second processor, a cryptographic module, and a secure memory storing computer-executable instructions for executing a program, the program comprising;

a download module for receiving update blocks from the port via the bus;

a header verification module for authenticating a header portion of the memory update;

a storage module for storing hash values embedded in the header portion;

a body block module for receiving one or more body block portions of the memory update and for comparing a hash of the body block portions with the hash values embedded in the header portion for corresponding body block portions; and

an activation module for operating from the memory update when all the update blocks have been received and verified by the body block module.

17. The computer of claim 16, wherein the header verification module parses the header portion into records comprising an update data header record, an update metadata record, an update signature metadata record, a hash data record, and a signature record.

18. The computer of claim 17, wherein the update metadata record comprises an update type field, an update version field, a hardware identifier, a product identifier, a platform type, and a platform version.

19. The computer of claim 17, wherein the update signature metadata record comprises a block count field, a hash algorithm identifier field, and a hash size field and wherein the hash data record includes a hash field for each update block.

20. The computer of claim 17, wherein the activation module retains an original memory update for operation when the body block module fails to verify all the update blocks.