System and method to secure on-board bus transactions

RELATED APPLICATION

0001This application is related to, and claims the benefit of, U.S. Provisional Patent Application No. 61/875,812, entitled “System and Method to Secure On-Board Bus Transactions”, filed Sep. 10, 2013, the contents of which are incorporated herein by reference in their entirety.

BACKGROUND

0002It can be difficult to secure a computing system against unauthorized access when the attacker has physical access to the system. The reason for this difficulty is that physical access to the computing system allows the attacker to probe the electrical traces used to transmit information between components on the motherboard. Since the transmission protocols used to encode the data transmitted across these traces is generally available (because they are usually a standard), an attacker with physical access to the system can watch for sensitive information or even inject data. For example, by finding the decryption key, the attacker can read data via the electrical signals which is otherwise unavailable to software running on that system (because of various software protections). Alternatively, by injecting data at a specific point, a denial of privilege can be converted into a granting of privilege.

BRIEF SUMMARY

0003Embodiments of the present invention provide a technique for securing on-board bus transactions. In one embodiment, during the manufacturing process, a shared key is generated and then programmed into write-once, read-only non-volatile storage of two on-board components. Once the shared key has been generated and written to storage, all transactions between the two components are encrypted by the components using the shared key without exposing the key on any external bus.

0004In one embodiment, a computing device-implemented method for securing on-board bus transactions includes retrieving a shared key from a write-once non-volatile storage of a first on-board component of a computing device. Data is then encrypted at the first on-board component using the retrieved key and the encrypted data is transmitted across a bus in the computing device to a second on-board component of the computing device. The method also retrieves a shared key from a write-once non-volatile storage of the second on-board component and decrypts the encrypted data using the shared key retrieved from the write-once non-volatile storage of the second on-board component. The first on-board component and the second on-board component each include a crypto-engine capable of performing encryption and decryption operations.

0005In another embodiment, a computing system providing secure on-board bus transactions includes a peripheral controller. The peripheral controller includes a write-once non-volatile storage that holds a shared key. The peripheral controller also includes a peripheral bus host controller that includes a crypto-engine capable of performing encryption and decryption operations encrypting or decrypting data using the shared key held in the write-once non-volatile storage of the peripheral controller. The computing system further includes a peripheral bus and a peripheral in communication over the peripheral bus with the peripheral controller. The peripheral includes a write-once non-volatile storage that holds the shared key. The peripheral also includes a crypto-engine capable of performing encryption and decryption operations encrypting or decrypting data using the shared key held in the write-once non-volatile storage of the peripheral.

BRIEF DESCRIPTION OF THE DRAWINGS

0006The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate one or more embodiments of the invention and, together with the description, help to explain the invention. In the drawings:

0007<figref idref="DRAWINGS">FIG. 1</figref> depicts an exemplary computing system containing hardware components utilized by embodiments of the present invention;

0008<figref idref="DRAWINGS">FIG. 2</figref> depicts an exemplary sequence of steps performed by an embodiment of the present invention to generate and write a shared key;

0009<figref idref="DRAWINGS">FIG. 3</figref> depicts an exemplary key writing sequence of <figref idref="DRAWINGS">FIG. 2</figref> in greater detail;

0010<figref idref="DRAWINGS">FIG. 4</figref> depicts an exemplary sequence of steps performed by an embodiment of the present invention to conduct secure transactions using a shared key to transmit encrypted data from a peripheral controller to a peripheral; and

0011<figref idref="DRAWINGS">FIG. 5</figref> depicts an exemplary sequence of steps performed by an embodiment of the present invention to conduct secure transactions using a shared key to transmit encrypted data from a peripheral to a peripheral controller.

DETAILED DESCRIPTION

0012Embodiments of the present invention use a shared key stored in write-once, non-volatile key storage to perform cryptographic processing inside components communicating over a system's motherboard so as to ensure that no unencrypted data or code is exposed outside of the components. This configuration prevents interception by probing of electrical signals by unauthorized individuals that have gained physical access to the computing system. By making the installation of the key into the write-once key storage of each component a write-once operation, the installation can be done during the manufacturing of the device which is in most circumstances a controlled and secure environment. Further, by making the write-once key storage writable, each unit of a particular product may have a uniquely generated key. As a result of this uniqueness, if somehow the key from one device is compromised, it does not necessarily jeopardize the security of other devices.

0013<figref idref="DRAWINGS">FIG. 1</figref> depicts an exemplary computing system containing hardware components utilized by embodiments of the present invention. Computer system <b>100</b> includes a CPU and memory controller <b>102</b> which fetches CPU instructions from dynamic random access memory (DRAM) <b>104</b> or flash read only memory (ROM) <b>130</b>. It will be appreciated that other forms of RAM or ROM may be employed by computing system <b>100</b> without departing from the scope of the present invention. CPU <b>102</b> communicates with the flash ROM <b>130</b> and peripherals via a PCI bus <b>106</b> and peripheral controller <b>110</b>. Peripheral controller <b>110</b> translates CPU I/O and memory reads and writes into cycles appropriate for flash ROM <b>130</b> using a flash host controller (not shown) or peripheral <b>160</b> via a peripheral bus host controller <b>120</b> and peripheral bus <b>150</b>. Examples of a peripheral controller suitable for use with an embodiment of the present invention include INTEL's ICH and PCH chips. Examples of a peripheral bus host controller suitable for use with an embodiment of the present invention include the USB OCHI, UHCI or XHCI host controller which sends and receives data over peripheral bus <b>150</b> to peripheral <b>160</b>. Examples of a peripheral suitable for use with an embodiment of the present invention include a USB keyboard, USB mass storage device, PCI peripheral, a touch panel, PS/2 style keyboard or display controller although it will be appreciated that many other types of peripherals are also within the scope of the present invention. It will be further appreciated that the exact bus configuration or the way in which functions are divided between the CPU, memory controller and peripheral controller can be rearranged without departing from the scope of the present invention.

0014In one embodiment, both the peripheral bus host controller <b>120</b> and the peripheral <b>160</b> contain a crypto-engine <b>122</b>, <b>164</b> and a quantity of non-volatile, write-once key storage <b>112</b>, <b>162</b>. The write-once storage may be on-chip EEPROM, but could take other form. Other examples of write-once storage include forms of battery-backed SRAM, fuses or CPLDs. The crypto-engine <b>122</b>, <b>164</b> is capable of performing encryption and decryption operations using shared keys stored in the write-once key storage <b>112</b>, <b>162</b> without exposing any of the processing or key data to any external chip signals including DRAM, debug signals. In one embodiment, symmetric algorithms (and symmetric keys) are used for encryption and decryption due to being faster and requiring a smaller key size, although it will be appreciated that other types of non-symmetric keys and non-symmetric algorithms are also considered to be within the scope of the present invention.

0015In an alternate embodiment, asymmetric algorithms may be employed using public-private key pairs. In one embodiment, a first component uses the public half of a public-private key pair and the second component that is communicating with the first component uses the private half of the public-private key pair Alternatively, two separate public-private key pairs may be shared. The first on-board component may hold a first private key and a first public key and the write-once non-volatile storage of a second on-board component may hold a corresponding second public key associated with the first private key and a second private key associated with the first public key (as used herein the term “on-board” refers to a motherboard of the computing system).

0016In an embodiment, the write-once key storage <b>112</b>, <b>162</b> for both devices is not readable on any external data signals. As an additional aspect of the present invention, the write-once key storage <b>112</b>, <b>162</b> is writable exactly once from a program executed by the CPU <b>102</b> . After being written, the write-once key storage <b>112</b>, <b>162</b> can no longer be updated. Once the write-once key storage <b>112</b>, <b>162</b> is written, its status as having been written is detectable without actually reading the contents of the write-once key storage. For example, a detection of write-once key storage status may be done by keeping a separate read-only status flag or by attempting to perform a subsequent write to the write-once storage (which would fail and be interpreted as an indicator that the storage was already written). A hardware random number generator <b>140</b> utilized by embodiments of the present invention provides a unique random number that meets normal criteria for randomness and period.

0017In another embodiment, the key storage may be made non-volatile using a separate step. This allows for a case when the key fails to be written to the peripheral's key storage, allowing for repair. Once the key is written successfully to the peripheral's key storage, the key is written to the peripheral controller's key storage and the write-once lock is set. Once locked, the key storage cannot be unlocked.

0018<figref idref="DRAWINGS">FIG. 2</figref> depicts an exemplary sequence of steps performed by an embodiment of the present invention to generate and write a shared key. More particularly the sequence describes how the write-once key storage <b>112</b> of the peripheral controller <b>110</b> and the write-once key storage <b>162</b> of the peripheral <b>160</b> may be filled with the shared key on the first boot of the system. The sequence begins after reset (step <b>200</b>) when the computer system begins execution of code stored within the platform firmware in order to perform hardware initialization (step <b>202</b>). Once the system is able to communicate with the peripheral controller <b>110</b>, a check is performed (step <b>203</b>) to detect whether the peripheral controller write-once key storage <b>112</b> is full. If the write-once key storage <b>112</b> is full, then the next steps of generating and writing a shared key are not required and the sequence exits (step <b>208</b>). In one embodiment, the check of only the write-once key storage <b>112</b> of the peripheral controller <b>110</b> is adequate since the peripheral controller's write-once key storage will only be populated after the peripheral's write-once key storage <b>162</b>. In other embodiments, both write-once key storages may be checked.

0019If the peripheral controller key write-once key storage is not full (step <b>203</b>), then once the system is able to communicate with the peripheral controller <b>110</b>, peripheral <b>160</b> , and the crypto-engines <b>122</b>, <b>164</b> and write-once key storage <b>112</b>, <b>162</b> of both the peripheral and peripheral controller, the shared key(s) are generated (step <b>204</b>). In a preferred embodiment, the PBKDF2 algorithm described in RFC 2898 (and PKCS #5, version 2.0) is used, using a random number generated from the hardware random number generator as the password and the platforms UUID as the salt. A salt is random data used as additional input to a one-way hash function. Other algorithms, passwords and salts can be used, including those read from an external storage device or which use a software random number algorithm with a seed derived from a suitable random source. The generated shared key is fitted to the size required by the cryptographic algorithm(s) supported by the crypto-engines.

0020After the key is generated, it must be programmed into the peripheral's and peripheral controller's write-once key storage <b>112</b> and <b>162</b>. The exact method of programming the key into the peripheral's write-once key storage is not specific to this invention, as many methods are well-known, and may involve commands specific to the type of peripheral bus and possibly peripheral. Notwithstanding the above, <figref idref="DRAWINGS">FIG. 3</figref> depicts an exemplary key writing sequence of <figref idref="DRAWINGS">FIG. 2</figref> in greater detail. The sequence begins by attempting to write the shared key to peripheral key storage (step <b>300</b>). If the key is not written successfully (step <b>301</b>), this may be a recoverable error. In the case of a fatal error (step <b>306</b>), the system may report an error to the user, reset the system, log the condition and continue or halt or other behaviors. If the key is written successfully to the write-once storage <b>162</b> of the peripheral (step <b>301</b>), then an attempt is made to write the shared key to the peripheral controller's write-once key storage <b>112</b> (step <b>302</b>). If the shared key is not successfully written to write-once key storage <b>112</b> (step <b>303</b>), then this is a fatal error (step <b>306</b>) since the shared key was generated and already written to the write-once storage <b>162</b> of the peripheral <b>160</b>. As noted above, the system may take a number of different actions following the failure including reporting the error and resetting the system. If the write of the shared key to the write-once storage <b>112</b> of the peripheral controller <b>110</b> is successful (step <b>303</b>), the key writing procedure is successful and exits (step <b>304</b>) and system execution continues normally.

0021<figref idref="DRAWINGS">FIG. 4</figref> depicts an exemplary sequence of steps performed by an embodiment of the present invention to conduct secure transactions using a shared key to transmit encrypted data from a peripheral controller to a peripheral. When the peripheral controller prepares to send data to the peripheral (step <b>400</b>), it first retrieves the shared key from its write-once storage <b>112</b> (step <b>402</b>) and its crypto-engine <b>122</b> uses the retrieved key to encrypt the data portion of the transaction (step <b>404</b>) . In general, the encryption does not operate on the control or encapsulation portions of the peripheral bus transactions, only the data contents. Following encryption, the encrypted data is sent from the peripheral controller <b>110</b> across the peripheral bus <b>150</b> where it is received by the peripheral <b>160</b> (step <b>406</b>). The peripheral <b>160</b> then proceeds to retrieve the shared key from its once-write storage <b>162</b> (step <b>408</b>) and its crypto-engine <b>164</b> uses the shared key to decrypt the data (step <b>410</b>) using the crypto logic and the key stored in the peripheral write-once key storage. Once the data is decrypted, it may be used normally (step <b>412</b>). In this way, the unencrypted data is never exposed on the peripheral bus.

0022It will be appreciated that transactions originating at the peripheral may be similarly secured. For example, <figref idref="DRAWINGS">FIG. 5</figref> depicts an exemplary sequence of steps performed by an embodiment of the present invention to conduct secure transactions using a shared key to transmit encrypted data from a peripheral to a peripheral controller. When the peripheral <b>160</b> prepares to send data to the peripheral controller <b>110</b> (step <b>500</b>), it first retrieves the shared key from write-once storage <b>162</b> (step <b>502</b>) and encrypts the data portion of the transaction (step <b>504</b>) using the crypto-logic and the retrieved key. In general, the encryption does not operate on the control or encapsulation portions of the peripheral bus transactions, only the data contents. Then the encrypted data is sent normally across the peripheral bus (step <b>506</b>), where it is received by the peripheral controller <b>110</b>. The peripheral controller <b>110</b> then proceeds to retrieve the shared key from its write-once storage (step <b>508</b>) and decrypt the data (step <b>510</b>) using the crypto logic and the retrieved shared key. Once the data is decrypted, it may be used normally (step <b>512</b>). In this way, the actual unencrypted data is never exposed on the peripheral bus <b>150</b>. If the shared keys are not programmed into write-once key storage, no encryption or decryption is done.

0023In the case when data transactions are too small to hold the entire encrypted form of the data, additional data transactions may be necessary to complete the transmission of all the data. For example, a USB key press might only require two bytes while the minimum encryption size for a symmetric encryption algorithm might be 128 bits (8 bytes). Since the size of transmission across the USB bus may be fixed as 2 bytes, an alternate command may be necessary or 3 more 2-byte “dummy” transactions may be performed. These so-called dummy transactions would contain the additional <b>6</b> bytes of encrypted data. In another example, on the PCI device some transactions are sent using a single 32-bit transaction so an additional transaction would be necessary between the PCI host controller and the PCI device to obtain the additional 32-bits.

0024In one embodiment, to enhance the security of data transactions, additional security steps may be taken. To prevent replay injection attacks, each communicating component may maintain a monotonic counter <b>116</b>, <b>166</b> whose value is encrypted with the data. The receiving side checks the decoded data to verify that the decrypted monotonic counter value matches the expected value. After each successful transaction, the counter is incremented. In another embodiment, to prevent dictionary attacks, small data transactions may be salted with random values. For example, all possible key values from a peripheral keyboard would normally only translate to a few different encrypted values, since the key is static and the encryption algorithm produces the same encrypted value each time. It is possible therefore to relatively quickly construct a dictionary for a single device by pressing keys and then watching the resulting relatively small set of encrypted keys. However, by having the sender add a random number into the encrypted data as described above, no reliable pattern may be discovered by unauthorized individuals. After decryption, the random number portion of the data is simply ignored.

0025Portions or all of the embodiments of the present invention may be provided as one or more computer-readable programs or code embodied on or in one or more non-transitory mediums. The mediums may be, but are not limited to a hard disk, a compact disc, a digital versatile disc, ROM, PROM, EPROM, EEPROM, Flash memory, a RAM, or a magnetic tape. In general, the computer-readable programs or code may be implemented in any computing language.

0026Since certain changes may be made without departing from the scope of the present invention, it is intended that all matter contained in the above description or shown in the accompanying drawings be interpreted as illustrative and not in a literal sense. Practitioners of the art will realize that the sequence of steps and architectures depicted in the figures may be altered without departing from the scope of the present invention and that the illustrations contained herein are singular examples of a multitude of possible depictions of the present invention.

0027The foregoing description of example embodiments of the invention provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. For example, while a series of acts has been described, the order of the acts may be modified in other implementations consistent with the principles of the invention. Further, non-dependent acts may be performed in parallel.