[Cryptography] ORWL - The First Open Source, Physically Secure Computer

[Bill Frantz]

On 8/29/16 at 2:42 PM, perry at piermont.com (Perry E. Metzger) wrote:

>Of course, BERI and CHERI are secure in a distinct sense -- they are
>implementations of a capability architecture on top of the more
>ordinary MIPS instruction set. They are not, however, formally
>verified designs, and in that sense, are no more or less likely to
>have bugs or back doors than any other soft core design.
>
>However, taking it as an entirely distinct topic from being able to
>trust that one's hardware isn't malicious, I will note that the
>BERI/CHERI design is a very interesting one, and I'm hoping this
>research helps capability architectures make a comeback.

As a long time capability bigot, I can't resist this opening.

Capability systems are a nearly perfect match for what the 
Orange Book calls  "discretionary security". The authority 
passed through a capability can be very tightly matched to the 
needs of the operation. The, "Why does this cellphone flashlight 
application need my address book and access to the net?" 
situations can easily be avoided. For those not familiar with 
capabilities, object invocations in languages such as Java and 
Javascript are examples. In fact, there are capability 
implementations in both languages.

Discretionary security is sufficient to enforce the principle of 
least authority (POLA). We need POLA because, as Alan Karp 
recently said (not a direct quote), "I'm not smart enough to 
keep the bad guys out. So I want to limit the damage they can do 
when they get in." It helps to limit that damage if objects in 
the system are protected at a fine grain. Individual objects or 
files are good. Individual file systems less so. Capabilities 
are excellent at supporting fine grain authority because with 
one object, the capability, you both name the specific object to 
use and demonstrate the authority to use it. If we were to try 
object-level fine grain authority with access control lists, 
administration would become a nightmere.

An orthogonal issue is assurance. Assurance is what Perry is 
looking for when he wants to have the processor design formally 
verified. The best systems will have both capabilities and 
assurance, but either can be valuable with some level of 
weakness in the other. Generally for assurance, the smaller the 
system the better. Even without proof, an OS seems more likely 
to be correct than a language based system, and hardware should 
be better than an OS. However we can get a lot of useful 
protection from language based capabilities even without the 
level of assurance we would really like.

When people talk about "security" they generally mean "mandatory 
security". Mandatory security can keep you from passing certain 
things (data/objects/files etc.) to other objects in the system 
even when you have access to both those things and those 
objects. There have been a number of papers saying the 
capability systems can not implement mandatory security and 
therefor they can be secure. The problem with these papers is 
that there are a number of published techniques for implementing 
mandatory security in capability systems. These techniques use 
the objects in the system, rather than low level system 
primitives, so assurance for them is a form of program assurance.

One advantage of building mandatory security on top of 
capabilities is that there is a first class story for how the 
privilege of changing the mandatory controls is controlled, It 
can even be made fine grain if necessary, which might make 
administration easier.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"We used to quip that "password" is the most common
408-356-8506       | password. Now it's 'password1.' Who said 
users haven't
www.pwpconsult.com | learned anything about security?" -- Bruce Schneier