[cap-talk] Implementing a crypto brand: What are the security requirements?

[Tyler Close]

On 3/22/07, Kevin Reid <kpreid at mac.com> wrote:
> > As I discussed above, the E-on-Java implementation does currently
> > implement spoofability, since any object with the E Brand can
> > masquerade as an authentic Box. Your comments above confirm that this
> > fact is subtle and easily missed. In the above E code, "sealer" could
> > refer to an object that creates a SealedBox of a different E Brand,
> > but that claims to be of the "brand" Brand.
>
> No; SealedBox is a Java class, and the SealedBox guard accepts only
> instances of that class. Instances of SealedBox are known to report
> their brands correctly.

Ah, and even though SealedBox is not declared final, it doesn't have a
constructor a subclass could use. I guess this also means the E
implementation does not allow for the implementation of a crypto brand
that is polymorphic with the existing E brand API.

> >>> Integrity
> >>>     The content of a Box A cannot be mutated.
> >>
> >> This is not a property of the sealing system provided by E. The box
> >> cannot be mutated, but its contents do not lose mutability.
> >
> > E-on-Java does implement Integrity as I've defined it. Your second
> > sentence above is the crucial one needed to understand the precise
> > meaning. You can seal a reference to a mutable object in a Box, but
> > you can't change which reference is in the Box once sealed. Using your
> > example below, you can seal a mutable list in a box, but you can't
> > make a box point to a different mutable list.
>
> In the terminology I was using, making the box point to a different
> object is "mutating the box", or "replacing the content of the box".
> "mutating the content of the box" is mutating that mutable list.

So it seems the word 'content' is confusing. We need some word for the
part of the object graph that is actually represented inside the
crypto box, rather than referred to by that part of the object graph.

> >> A crypto-sealed box in E would, however, require that its contents
> >> be Data (immutable and serializable).
> >
> > I don't think so. For mutable box content, I think the E
> > implementation would seal a representation of a live ref.
>
> No such representation can exist; it would have to create a SturdyRef.

Hmmm... Seems like something could be done here to preserve the live
ref semantics, but I don't want to get into it just now.
Joe-E/ref_send doesn't have a corresponding concept for E's live refs.
All refs are both live and sturdy.

Tyler

-- 
The web-calculus is the union of REST and capability-based security:
http://www.waterken.com/dev/Web/

Name your trusted sites to distinguish them from phishing sites.
https://addons.mozilla.org/firefox/957/