System and method for changing a shared encryption key

Embodiments of the present invention relate to changing a shared encryption key.

Many computing systems generally have multiple operating environments, such as an operating system (OS) and a basic input / output system (BIOS). Such operating environments communicate with each other. Unfortunately, in at least some cases, the communication mechanism between operating environments is vulnerable to being snooped by malicious entities such as "viruses".

<p> The present invention provides a system and method for changing a shared encryption key.</p>

<p> One embodiment of the present invention is a system (50) including a first operating environment (56) and a second operating environment (62), the first operating environment and the second operating environment. Exchanges information in an encrypted form using a shared encryption key (K3), and the first operating environment and the second operating environment use another shared encryption key (K4). It is used to coordinate to change the encryption key K3, which is changed when the encryption key K3 is changed.</p><p> In order to illustrate the exemplary embodiments of the invention in detail, reference is made herein to the accompanying drawings.</p>

<figref num="1">A system according to an embodiment of the present invention is shown.</figref><figref num="2">A method of changing a key shared between at least two operating environments according to an embodiment of the present invention is shown.</figref><figref num="3A">Here is another example way to change the shared key.</figref><figref num="3B">Here is another example way to change the shared key.</figref><figref num="4">A method of resetting a key shared between at least two operating environments according to an embodiment of the present invention is shown.</figref>

Notation and term system Certain terms are used to refer to a particular system component throughout the description and claims below. As will be appreciated by those skilled in the art, computer companies may refer to a component by a different name. This document is not intended to distinguish between components that differ in name but not in functionality. In the following statements and claims, the terms "include" and "provide" are used without limitation and thus mean "including, but not limited to,". Should be interpreted as. Also, the term "couple" or "couples" is intended to mean either an indirect electrical connection, a direct electrical connection, an optical electrical connection, or a wireless electrical connection. There is. Therefore, when the first device connects to the second device, the connection may be through a direct electrical connection or through an indirect electrical connection through another device and connection. In some cases, it is through an optical electrical connection, and in other cases, it is through a wireless electrical connection.

Detailed explanation FIG. 1 shows an embodiment of system 50. The system 50 includes a processor 52, a system read-only memory (ROM) 54, and a storage 59. The system ROM 54 stores the basic input / output system (BIOS) 56, which is the code that can be executed by the processor 52. BIOS 56 features Power-on Self-Test (POST), which tests and initializes System 50 during boot-up. BIOS56 also provides a low-level interface to various of System 50's peripheral components (eg, floppy (registered trademark) disk drives, hard drives, keyboards, etc.). The storage 59 includes volatile memory such as random access memory (RAM), non-volatile storage such as ROM and hard disk drive, or a combination thereof. Storage 59 stores operating system (OS) 62. OS62 also contains code executed by processor 52. There may be one or more applications / drivers 64 running under OS 62 and run by processor 52.

BIOS 56 and OS 62 provide two software operating environments that communicate with each other via a secure communication mechanism. The following description is provided in the context of BIOS 56 and OS 62, but can generally be applied to other operating environments. As long as any of the following actions are due to the OS 62, such actions can be performed by the OS itself or one or more of the applications / drivers 64 running under the OS.

The BIOS 56 and OS 62 communicate with each other by encrypting commands and data that are transferred back and forth between them. According to embodiments of the present invention, the encryption protocol includes a symmetric encryption protocol, which means that BIOS 56 and OS 62 each use the same copy of the encryption key. For example, OS62 uses an encryption key to encrypt a request to send to BIOS56, and BIOS56 uses its own copy of the same encryption key to decrypt the encrypted request. The "shared" encryption key is used to encrypt information in either the OS62 to BIOS56 direction and vice versa.

It is theoretically possible for an entity (eg, a virus) to snoop encrypted communication between BIOS 56 and OS 62 to determine the encryption key used. A security mechanism is implemented to update the shared key to reduce the possibility of such malicious entities snooping communication between BIOS 56 and OS 62 to infer the encryption key. This security mechanism causes BIOS56 and OS62 to change their shared keys in a secure way. That is, the way the shared key is updated is itself secure. The shared key update procedure can be scheduled to take place over a predetermined or programmable time period (eg, once an hour, once a day, etc.) or between BIOS 56 and OS 62. It can also be scheduled to occur when communication is performed n times in (for example, each communication packet or every 5 communication packets).

With reference to FIG. 1 again, the system ROM 54 includes storage for various encryption keys 58 labeled K1, K2, K3, and K4. A copy of keys K1 and K2 is loaded into the system ROM 54 and is not erasable, overwriteable, or otherwise erasable, according to some embodiments of the invention. Keys K3 and K4 can be erased and overwritten as described below. The K1 to K4 keys 58 on the system ROM can be part of BIOS 56 or separate from BIOS 56. OS62 also accesses the set of keys K1 to K4 66. According to an exemplary embodiment, the OS keys K1 to K4 66 are the same as the BIOS 56 keys K1 to K4 58. With respect to the BIOS key 58, in some embodiments, copies of keys K1 and K2 of OS62 are protected from overwriting or otherwise erasure. OS keys K3 and K4 can be erased and overwritten.

As used herein, the term "key" (eg, K3) refers to the value of that key. Therefore, you can change the value of K3 to a new value, but the new value is still referred to as K3.

As shown in FIG. 1, each of BIOS 56 and OS 62 accesses a shared encryption key to encrypt the information exchanged between BIOS 56 and OS 62. According to an embodiment of the invention, the encryption process is symmetric encryption, which means that the same key value used to encrypt the information is used during the decryption process. For example, OS62 uses its own copy of shared key K1 to encrypt information (eg commands, data) sent to BIOS56. The BIOS 56 uses its own copy of the shared key K1 to decrypt the received communication and recover the underlying information. The BIOS56 can also send encrypted information to the OS62, so the BIOS56 uses the key K1 to encrypt such information, and the OS62 uses the key K1 to decrypt it. .. OS62 and BIOS56 thus use a shared encryption key (eg, K1) to exchange information in an encrypted form. The shared key K2 is used during the key update procedure shown in the example in Figure 2.

As discussed above, it is possible to estimate the value of the symmetric encryption key by monitoring the encrypted packets that are passed back and forth. Therefore, the encryption key K1 can be inferred by monitoring the encrypted information exchanged between BIOS 56 and OS 62. Embodiments of the present invention provide a mechanism for changing the encryption key used to encrypt information between two operating environments (eg, BIOS 56 and OS 62). In addition, the encryption key change is done in a way that is itself secure so that the new value of the encryption key is not compromised. The shared symmetric encryption key K2 is used to modify the encryption key K1 in a way that helps verify that only authorized entities are attempting to modify K1. When the key K1 is changed, the key K2 is also changed. Moreover, according to various embodiments of the present invention, the current value of key K2 is used only during the process of changing key K1, and during this period K2 is also changed. That is, during the process of changing K1, key K2 is also set to the new value. This new value will then be used the next time key K1 is changed. The current value of K2 is used once to help change K1 (although K2 may be used more than once each time K1 is changed), so its value is BIOS56. It cannot be reasonably estimated by a rogue entity that monitors traffic to and from OS62. In some embodiments, K1 and K2 are modified. In other embodiments, keys K1 and K2 remain unchanged to ensure that BIOS 56 and OS 62 can communicate with each other in the event of certain errors, instead a copy of keys K1 and K2 ( (Discussed herein as keys K3 and K4, respectively) are used to perform message encryption / decryption and key update processes. In case of an error, the system can revert to the original K1 and K2.

According to embodiments of the present invention, one of the BIOS 56 and OS 62 requires the other of the BIOS and the OS to calculate new encryption key values for K1 and K2. In one embodiment, OS62 requires BIOS56 to calculate new values for K1 and K2. During this process, key K2 is used by BIOS56 to validate the OS's request to change encryption key K1. In addition, key K2 is also used by OS62 to verify return communication from the BIOS to the OS with new values for K1 and K2. Using K2 to verify communication between OS 62 and BIOS 56 helps prevent rogue entities from exchanging new key pairs with OS and / or BIOS. In the embodiments described herein, only the computing environment (eg, BIOS 56 and OS 62) accessing the shared key K2 can make changes to the keys K1 and K2.

According to at least some embodiments of the present invention, a system 50 is provided to the user of the system in which the values of K3 and K4 are set to the values of K1 and K2, respectively, for both BIOS 56 and OS 62. That is, initially, for both BIOS 56 and OS 62, K3 is equal to K1 and K4 is equal to K2. During the system 50 installation process, keys K3 and K4 are modified for both BIOS 56 and OS 62 as described below. From that point on, the encryption between BIOS 56 and OS 62 uses key K3, which is used to change key K3, and as a result, K4 is changed as well.

In some embodiments, the keys K1 and K2 of both BIOS 56 and OS 62 are not erasable, thereby allowing the system 50 to have a known feature set of keys (K1 and K2), if desired or as needed. The ability to return to is provided. For example, if storage 59 does not function properly and is replaced, the replacement hard drive will have the original values of K1 and K2, and keys K3 and K4 will mirror keys K1 and K2. The keys K3 and K4 on the system ROM 54 can also be set back to the initial values of K1 and K2.

Referring to FIG. 2, an example of the key change process 80 including operations 82 to 90 is shown. Process 80 in Figure 2 illustrates that BIOS 56 calculates new values for K1 and K2 at the request of OS62. In other embodiments, the roles of BIOS 56 and OS 62 are reversed, BIOS 56 requests a key update, and OS 62 calculates a new key value.

At 82, OS62 requires BIOS56 to generate a replacement set of key values for shared keys K3 and K4. At 84, BIOS 56 validates OS requirements through the use of K4. If the BIOS 56 successfully validates the OS requirements, at 86, the BIOS calculates a new set of encryption key values (K5 and K6) and provides those new key values K5 and K6 to the OS 62. The key values K5 and K6 are temporary in nature, which in at least some embodiments the key values K5 and K6 are used only to change the values of K3 and K4. Means that. If BIOS56 fails to validate the OS requirements, this process either stops or takes another appropriate action (for example, alerts).

Further referring to Figure 2, at 88, through the use of K4 again, OS62 verifies communication from BIOS 56, including a new set of encryption keys (K5, K6). If the OS 62 successfully verifies the BIOS communication, at 90 the OS replaces the OS copy of the K3 and K4 keys with the new keys K5 and K6. That is, K5 is used to overwrite K3 and K6 is used to overwrite K4. A message that the OS has accepted the new key is sent by the OS to the BIOS, which also then replaces its own copy of the K3 and K4 keys with the values of the new keys K5 and K6.

The key change process 100 of FIGS. 3A and 3b describes some of the operations of FIG. 2 in more detail. At 102, OS62 requires BIOS56 to provide a random number to the OS. The term "random number" (RN) includes a number that is sufficiently random to be used with the embodiments described herein. Therefore, the random numbers do not have to be mathematically true random numbers. At 104, BIOS56 generates a random number, modifies the random number using key K3, and provides the modified random number to OS62. Random numbers can be generated via any suitable technique, such as sampling analog parameters (eg, temperature, noise, etc.) and using the samples to generate random numbers. In at least one embodiment, the modification to the random number comprises performing an exclusive OR operation in which the random number is exclusively ORed with K3. At 106, OS62 receives the modified random number and recovers the original random number. In the example where the random number is exclusively ORed with K3 by BIOS56, OS62 recovers the random number by exclusive ORing the modified random number with the OS copy of K3.

At 108, OS62 uses the random numbers recovered in K4 and 106 to calculate the hash function-based message authentication code (HMAC) and generate the output value HMAC_OS1. HMAC can be used to verify that the source entity that sends the communication to the destination entity is authentic. Other mechanisms besides HMAC are possible and are within the scope of this disclosure. At 110, OS62 provides the HMAC_OS1 value to BIOS 56, requiring the BIOS to generate a new set of keys to replace the shared keys K3 and K4. Before BIOS56 generates a new key value, the BIOS verifies that the request comes from an authorized source (ie, OS62). The BIOS performs this verification at 112 by calculating its own HMAC (called HMAC_BIOS1), using the BIOS random numbers generated in 104 and also using a copy of the K4's BIOS. These random numbers and a copy of the K4's BIOS are the same values used by OS62 to generate the HMAC_OS1 value. Therefore, the HMAC value calculated by OS62 should match the HMAC value calculated by BIOS56. On the other hand, if a rogue entity provided an HMAC value to the BIOS, then such a rogue entity would not have access to the correct value for K4 and / or random numbers and would therefore be calculating a mismatched HMAC value. Therefore, the HMAC values will not match.

At 114, the BIOS 56 compares the values of HMAC_OS1 with the values of HMAC_BIOS1 to determine if those values match. If their values do not match, the process fails and stops at 116. If desired, an alert or other appropriate response can be made in this situation. On the other hand, for HMAC_OS1 and HMAC_BIOS1 values, this method continues at 118, where the BIOS generates new key pairs K5 and K6. Such keys can be calculated according to any suitable technique.

At 120, the BIOS now calculates another HMAC value using a copy of the K4's BIOS and another value that is a combination of the random numbers generated at K5, K6, and 104. The resulting HMAC value at 120 is called HMAC_BIOS2 and verifies that the OS62 sent the new key values K5 and K6 to the OS by an authorized source (ie, BIOS56), as described below. Used for. The values of K5, K6, and random numbers are combined with each other by concatenating such values with each other in at least one embodiment. Other techniques for combining K5, K6, and random numbers are possible as well and are within the scope of this disclosure.

Further referring to FIG. 3A, at 122, the BIOS computes the hash of the random numbers generated at K4 and 104 to generate a value called Hash_BIOS. Any suitable hash function can be used in this regard. At 124, BIOS 56 uses the Hash_BIOS value to modify the newly calculated keys K5 and K6 to generate modified versions of K5 and K6. Therefore, K5 is modified using Hash_BIOS, and K6 is also modified using Hash_BIOS. In at least some embodiments, changes to the K5 and K6 values include exclusive ORing each of the K5 and K6 values with the Hash_BIOS value. At 126, BIOS 56 provides the modified K5 value, the modified K6 value, and the HMAC_BIOS2 value to OS 62.

At 128 (Figure 3B), OS62 receives the modified K5 and K6 values as well as the HMAC_BIOS2 value. At 130, OS 62 calculates a copy of the OS for K4 and a hash of random numbers provided to the OS by the BIOS at 104 (using the same hash function used by the BIOS at 122). The hash calculated at 130 is called Hash_OS. At 132, OS 62 recovers the original version of K5 and K6 from the modified version of K5 and K6 by using the hash calculated at 130. In an embodiment where K5 and K6 are modified by exclusive-ORing K5 and K6 with the value of Hash_BIOS, this recovery operation is performed by exclusive-ORing the modified version of K5 and K6 with Hash_OS.

At 134, the OS uses K4 combined with random numbers from K5, K6, and 104 (recovered at 132) to calculate the value of HMAC. In at least some embodiments, the values of K5, K6, and random numbers are combined at 134 in the same way that such values are combined at 120 (eg, concatenation). The resulting HMAC value from 134 is called HMAC_OS2. OS62 compares HMAC_OS2 with HMAC_BIOS2 in 136 to verify that the source of the new keys K5 and K6 is an authorized entity (eg, BIOS56). If the HMAC values do not match at 136, the key update process fails at 138. If there is a match, at 140, the OS accepts the new keys K5 and K6 from BIOS 56 by overwriting K3 and K4 with the new keys K5 and K6, respectively. At 142, the OS 62 notifies the BIOS 56 that the OS has received and accepted the new key values K5 and K6. With this acknowledgment, BIOS56 uses its own copy of K5 and K6 to overwrite its own copy of K3 and K4, thereby replacing the previous values of K3 and K4 with the values of K5 and K6.

In addition to being able to update the shared keys K3 and K4 used between BIOS 56 and OS 62, the security mechanism of the disclosed embodiments allows keys K1 and K2 to be used for encryption / decryption and key update purposes. It also allows the occurrence of resets, where BIOS 56 and OS 62 reset their shared keys to the previous known key sets K1 and K2. FIG. 4 provides an exemplary method 150 demonstrating this process. At 152, OS 62 prompts the user to enter the admin password. The user inputs this management password at 154. At 156, the admin password is verified and then encrypted with key K1. At 158, the OS sends an encrypted admin password to BIOS56, which then decrypts the encrypted password and verifies its validity (160). Next, BIOS56 resets to keys K1 and K2. In some embodiments, this reset operation is performed by using the values of K1 and K2 and overwriting the values of K3 and K4 of the storage 66. Similarly, the OS also resets to keys K1 and K2 by overwriting the OS values of K3 and K4 in storage 58, for example, using the OS values of K1 and K2.

According to at least some of the embodiments of the present invention, the two systems do not have the same Kodd and Keven. Therefore, even if an attacker has access to a pair of keys on one system, such knowledge is not useful in attacking another system, thereby providing protection against an overall attack.

The above discussion is intended to illustrate the principles and various embodiments of the present invention. Once the above disclosure is fully understood, a number of modifications and changes will be apparent to those skilled in the art. The following claims are intended to be construed to include all such modifications and modifications.

50 System 52 Processor 54 System ROM 56 Basic input / output system (BIOS) 58 Encryption key 59 Storage 62 Operating system (OS) 64 Application / Driver