[Cryptech Tech] arm

[Rob Austein]

At Tue, 13 Jan 2015 03:52:26 +0300, Basil Dolmatov wrote:
> 
> That means presence inside the secure perimeter some code which can
> perform "some" inspection and relevant data for it to do this. Due
> to the fact that validity of "every bit of what is to be hashed and
> signed" can be determined with entirely different checks for
> different use cases that effectively means presence of possibility
> to load (and reload, update, add or change) _arbitrary_ code and
> data inside the secure perimeter.
> 
> Did I got the point correctly? 

Not quite.  You've described Leif's version of this concept, and have
correctly identified why I objected to Leif's version. :)

There's a spectrum of such checks, ranging from hard-coded (all checks
frozen at compile time, can't be changed without breaking tamper seal
and destroying keys) to fully dynamic (run a Turing complete language
interpreter within the tamper boundary).

Leif and I ended up at opposite ends of this spectrum: I was
advocating the hard-coded approach, Leif was suggesting (not sure
whether he was really advocating) an interpreter.

The compromise Jakob suggested was hard-coded with the possibility of
a configuration file, with an implication that said configuration file
is to be as simple as possible for the job at hand.  So the set of
checks to be performed would be frozen before sealing the tamper
boundary, but some of the parameters against which the checks are
performed would be configurable, perhaps only at device
initialization, or perhaps only by a user with "security officer"
credentials.