[DGD] capability based security?

[bart at wotf.org]

On Thu, 24 Mar 2016 04:56:44 +0800, Carter Cheng wrote
> I agree I think cryptographic approaches are not useful in nondistributed
> situations. The main concern however with capabilities is still that
> pathological key transfers can occur and managing and designing a easily
> comprehensible system where you can easily revoke something and
> differentiate between legitimate transfers and ones you dislike. 
> There might be ways around this but it's a known standard problem 
> with canonical capabilities.

The legitimate transfer versus accidental leaking was indeed the thing I was
commenting on to Shentino, it is a known, and in an LPC context an easily
solvable problem, provided the 'within a single VM' constraint.

Revoking a capability is not difficult in LPC (Shentino offered a working
solution, which I use myself in a slightly different setting). However,
selectively revoking it is much more difficult. Again this is within the
single VM constraint, but even without that restriction, invalidating a
capability is usually a possible way to revoke it in general, but selective
revokation can't be solved that easily.

> 
> As for design based proofs- I always find reading papers with these 
> not so interesting since they yield limited insight into general 
> principles 

I'd rather think you need to have that insight already, but for a practical
use, they can provide valuable information about the assumptions and
restrictions of the concept they demonstrate.

> and more importantly are often either contrived to make 
> the proofs easy (and the system somewhat of a academic special case) 

Or a good demonstration of how a concept works without too much polution from
other (possible real-world) issues.

> or prove very weak properties.
> Also a lot of papers in the top 
> conferences in security are somewhat lacking in the proof department 
> and more introduce heuristically motivated ideas and demonstrate 
> their implementations.

Nothing wrong with that, especially for academic research, and a valuable
source for concepts and ideas. I use that myself a lot when looking for ideas,
right now in the area of processing of 'big data'. Turns out lpc can do this
very well for very large sets of relatively small pieces of data.

In general, when building a practical system in lpc I often find concepts
translate quite well, but actual implementations often far less so, and it
often pays to come up with an implementation specifically thought up for the
lpc environment, both for how well it will work, and how much it deepens your
understanding of the concept.

Doing this means having to demonstrate at the design level how the mechanics
are supposed to maintain a safe state. As this concerns a rather restricted
environment over which you have a lot of control, you can assume and enforce
almost any restriction you might need. In this it seems to compare fairly well
to the limited academic systems you mentioned.

Bart.
--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/