From Trusted Computing to Trustworthy Execution

点击翻译按钮获取中文摘要

When a computer user accesses a remote service involving sensitive information, ensuring that the service program has executed with integrity and confidentiality is important before the service outcome can be trusted. For this purpose, trusted computing (TC) is introduced, which performs certain cryptographic measurements for inital integrity and isolates the program from outside for integrity and confidentiality. To eventually provide evidence of such protection to the user, a mechanism called attestation signs the measurements with a long-term secret that never gets exposed elsewhere and sends them to the user. The user chooses to trust the execution, seeing the measurements come from the long-term secret (verified with the public part of that secret) and cryptographically match the intended program. Nonetheless, current TC is still sub-ideal to be considered trustworthy. Things can go wrong in the following ways (examples): 1) the long-term secret can be learned by an adversary from intrinsic side channels, i.e., even when hardware never exposes the secret as the computer architecture specifies, the unspecified (mostly timing) behavior still leaks the secret. 2) with guaranteed initial integrity, a program's execution dynamics can largely be affected by data exchange with the outside, even if the program itself is isolated. Such dynamics include control/data flow and memory access safety. Therefore, the execution can deviate from what was originally measured. 3) the attestation request can be relayed to and fulfilled by a computer possessing the correct long-term secret, but different from where the program has actually run. I propose to advance TC to be closer to trustworthiness, embodied mainly by architectural discretization of secure elements and execution binding. The secure element (SE) is a hardware component where the long-term secrets are stored and protected. Compared to merely physical discreteness, the proposed architectural discretization makes sure that secrets in the SE never get exposed to the rich processor environment (never leaving the SE), and the involved operations are not visible to any system software and firmware. The discrete SE is designed with minimal complexity. This way, the aforementioned side channels are no longer applicable, due to no resource sharing. Execution binding (as opposed to platform binding to avoid attestation relay) is to include the execution dynamics into attestation so that correct attestation result can reflect (to a larger extent) correct execution. Such an SE design also allows the trust to be user-oriented, e.g., open provisioning and multi-purpose/multi-user SE.