History and future of Owner Override
I invented Owner Override one year ago today. The original formulation was very different -- it involved dumping the contents of RAM onto removable media -- and it's interesting to compare that description with the description in "Trusted Computing: Promise and Risk".
In several senses, Owner Override remains a thought experiment. Before it can be implemented, trusted computing vendors would need to make a conscious decision explicitly not to support "DRM-like" application security models, including lock-in, adware, spyware, forced upgrade, and forced downgrade behaviors. After making this decision, trusted computing developers would have to devise a particular mechanism and user interface for an Owner Override-like function.
Since a year ago, I have not proposed a specific user interface for Owner Override.
I think the insight that "as a technological matter, the functionality which unambiguously protects an end-user can be separated from the functionality which ambiguously protects the end-user" remains true. And this is a central point. The mechanism of making this separation is really less significant at this stage than the possibility of doing so.
I have an article on Owner Override in the December Linux Journal. It also doesn't describe a mechanism beyond the requirement that the computer owner be entitled to select the PCR values provided in an attestation if there is some reason that attesting to the actual PCR values would be against the computer owner's interest.
Stefan Bechtold has posted some informed criticism of Owner Override.
Happy birthday, Owner Override!
- Links from other weblogs:
Sat Feb 24 11:35:21: XQhaYJuxJmVf from OjZiDBhFg
dqVmaWLmLuv MYJVkT [URL=http://xindnsy.com/]sjEhjmkM[/URL]
