|
|
|
|
|
|
by pipo234
1011 days ago
|
|
|
Lamenting. The idea with TPM was KISS/separation of concern/"do one thing only and do it well". That is: guard a secret and use it as a trust root. For some reasons — unrelated to this mission — that simple concept led to an explosion of API entry points covering more an more weird corner cases that ought never to have been included in the trusted platform module. Adding insult to injury, the implementations were developed as closed source in a fashion not unfamiliar to printer firmware — huge code bases full of bugs at any level. At the core, a trust root can only be trusted when its validity is unquestionable. That is usually a Herculean effort. Think medical/space/aviation embedded devices, open unambiguous spec and implementation, formal verification, lots of eyes, paperwork blablah. That's a lot of money spent on a ridiculously simple component with little to no ways to monetize. No surprise that Intel, AMI, Apple went their own ways yielding mostly opaque, buggy trust anchors that subvert progress of downstream OS development while adding almost no practical security at all. |
|
|
I mean, the architecture of the TPM has more holes than swiss cheese, and a competent user can achieve higher security without using it.
There are clear benefits of the TPM for e.g. organisations so big that users forgetting their disk encryption password is a substantial support issue; corporations making TiVo-ized products that want to lock out the device owner; and corporations that need to comply with security requirements imposed by the technically clueless. Organisations who have bottomless pockets.
This seems like exactly the sort of features that belong in the Enterprise Edition of your product, like FIPS certification and SAML support.