[Cryptech Tech] arm

[Leif Johansson]

> 13 jan 2015 kl. 03:10 skrev Rob Austein <sra at hactrn.net>:
> 
> 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.

i was suggesting we take code sandboxing into account actually

> 
> 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.
> _______________________________________________
> Tech mailing list
> Tech at cryptech.is
> https://lists.cryptech.is/listinfo/tech