Does New Research on "Instant On" Computing Pose a Challenge on Trusted Computing?

Trusted Computing in general, and in particular the TCG model, relies on a trusted bootstrap mechanism, i.e., authenticated or secure boot. Based on this mechanism, all other functions are built, e.g., attestation and sealing. Attestation allows a local or remote party to verify the booted configuration of system components (e.g., BIOS, bootloader, operating system, etc.). Sealing enables to encrypt data in such a way that it can only be decrypted when the system has booted in the same constellation as at the time of encryption of the data.

Now, recent research in transistor technology paved the way for computer systems that would be "instant on", meaning, they would not need to boot, they would be available instantly on power-on. This research has added so-called ferroelectric capabilities to standard computer transistors. Materials with such capabilities can be found, e.g., in smart-cards.

But if we have computers that do not need to boot at startup, a trusted bootstrap mechanism will be meaningless. If a computer system is instantly on, maybe exactly in the same state as left at last usage (similar to suspend and resume functionality), we cannot verify the current state via attestation. What should be attested? The configuration the system was originally bootstrapped, possibly months ago? No, that would not help to make any judgement about the trustworthiness of a computer's state.

Fortunately, there are already some techniques available to handle such situations. For example, Intel's Trusted Execution Technology (TXT) includes a so-called Dynamic Root of Trust for Measurement (DRTM). This DRTM allows to "boot" small pieces of code or entire new operating systems during runtime, and takes the measurement of the loaded code to store it in a protected place of a TPM chip. With that mechanism one can reliably check the state of that loaded code. After execution of that code, the system returns to the original state before calling the DRTM.

However, it would not be of practical use to always start a new OS because that would introduce new time to wait for startup, which we just wanted to reduce with "instant on" systems. Instead, it would be better to just start small pieces of application code directly with that method, as was demonstrated by the Flicker project on newer AMD64 processors. One drawback of this method is, though, that the original system is "halted" while the specific application code is executed that was started via DRTM. Thus, in order to use, e.g., operating system services, the system has to "switch back" to the original state, and then restart the application via DRTM again, and so on. This introduces new costs of "context switches", which are much higher than normal process context switches.

To conclude, it is important to think about alternative ways of realizing attestation and sealing without relying on authenticated boot methods. I think runtime integrity monitoring seems to be the answer to that question. But, although there are some promising approaches, this is an unsolved problem yet.