Status of SRP

[Anne & Lynn Wheeler]

Florian Weimer wrote:
> You mean something like remote attestation?  I find it hard to believe
> that this capability is available today in a relatively open
> environment, on a platform supporting multiple applications developed
> by different applications.

re:
http://www.garlic.com/~lynn/aadsm23.htm#49 Status of SRP
http://www.garlic.com/~lynn/aadsm23.htm#50 Status of SRP

i got involved in tracking down a virus/trojan like problem in the 70s 
on the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

basically if you are going to allow loading of stuff that can do its own 
execution w/o many safeguards ... you are going to be extremely 
vulnerable to numerous kinds of attacks.

either you have to very tightly control what applications are loaded 
.... or possibly do a fixed function deployment that can support 
multiple different applications ... possibly based on some form of data 
driven architecture (i.e. the data specification possibly adapts the 
functional operation to different applications w/o requiring loading of 
executable code).

we had done the AADS chip strawman was done this way ... basically 
single function operation w/o any ability to load executable code ... 
that was adaptable to a large number of different applications
http://www.garlic.com/~lynn/x959.html#aads

another possible solution is very strong partitioning of any loadable 
executable content that is allowed extremely limited/controlled capability.

in the 60s as an undergraduate, i had done a lot with extremely 
controlled partitioning ... which i learned much later got used in 
various environments that had extremely high integrity requirements ... 
random drift
http://www.nsa.gov/selinux/list-archive/0409/8362.cfm

i had this discussion with the general manager of the business unit that 
included java and java virtual machine (when it was in its very early 
infancy) ... turns out that I had done some work with the person 
(general manager) nearly 20 years earlier in a different life.

many of the modern generation of POS terminals are trying to cope with 
this problem ... getting all sorts of frequent application downloads of 
various kinds ... and still attempting to operate within constraints of 
their trusted security module implementation.

basically if finread
http://www.garlic.com/~lynn/subpubkey.html#finread

is countermeasure to widely acceptable PC vulnerabilities (many that 
arise because of the ease and common practice of loading executable 
content) ... then if you deploy such a finread terminal that is operated 
using similar conventions ... then it will acquire similar vulnerability 
characteristics (as the environment that it is suppose to be a 
countermeasure for).

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com