TCG inside?: a note on TPM specification compliance
Proceedings of the first ACM workshop on Scalable trusted computing
High Time for Trusted Computing
IEEE Security and Privacy
SegSlice: towards a new class of secure programming primitives for trustworthy platforms
TRUST'10 Proceedings of the 3rd international conference on Trust and trustworthy computing
Plug-n-trust: practical trusted sensing for mhealth
Proceedings of the 10th international conference on Mobile systems, applications, and services
Mutual remote attestation: enabling system cloning for TPM based platforms
STM'11 Proceedings of the 7th international conference on Security and Trust Management
| Hi-index | 0.00 |
Broad adoption of secure programming primitives such as the TPM can be hurt by programmer confusion regarding the nature and representation of failures when using a primitive. Conversely, a clear understanding of the primitive's failure modes is essential for both debugging and reducing the attack surface in the mechanisms built on it. In particular, differences in error processing and reporting logic significantly detract from such understanding. We present a case study of diversity in TPM behaviors and its effects on a TSS implementation, which emerged from the Sun/Dartmouth TCG/OpenSolaris project, one of the goals of which was instrumenting TPM support on Solaris. At the start of the project, both parties believed the instrumentation to be well-defined and, although time-consuming, relatively straightforward. In the course of the project we had to reexamine our assumptions concerning the state of the hardware and the software involved and the view of the system as presented to someone unfamiliar with its internals. We describe some failure modes we encountered and suggest directions for remediation.