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

[Tyler Close]

Hi Kevin,

Thanks for looking at this.

On 3/22/07, Kevin Reid <kpreid at mac.com> wrote:
> On Mar 22, 2007, at 16:16, Tyler Close wrote:
>
> > I'm looking at implementing a sealer / unsealer pair for
> > Joe-E/ref_send using cryptography, instead of object references. The
> > result would be the crypto brand we've discussed in the past.
> >
> > I'm currently at the requirements gathering stage of development and
> > have found even this step to be pretty challenging and worthy of
> > discussion.
> >
> > I think the first step is enumeration of all the security properties
> > of a brand implemented using object references. This list provides the
> > minimum requirements for the crypto implementation. In building this
> > list of security properties, I am using the brand API defined at:
> >
> > http://waterken.sourceforge.net/javadoc/org/ref_send/brand/package-
> > summary.html
>
> Looking at this page, I note that it uses the term "Brand" in the
> opposite sense that E does. The "brand" of E's built-in sealing
> system is the facet of minimal authority; yours is the maximal.
>
> Most Authority <-----------> Least Authority
>                    Sealer
>                      /\
>                     /  \
> [Sealer,Unsealer] /    \  elib.sealing.Brand
>     (your Brand)   \    /
>                     \  /
>                      \/
>                    Unsealer

In my opinion, the term "brand" in E is overloaded. I think it could
be interpreted as describing the return of the getBrand() method, or
the return of the makeBrand() method. For clarity, I chose to give it
a single meaning, the return of the makeBrand() method and use the
term "label" for the other meaning.

> The elib.sealing.Brand (from a client's perspective) reliably
> identifies the group without giving any other authority;

It depends on what you mean by "reliably". Any object possessing the E
Brand can masquerade as a member of the group. I think this fact is
easily missed since E's Brand supports identity comparison and so
seems to provide authority.

> it is available everywhere your protocol offers its "label".

Correct. I renamed this attribute to label and changed its type to
String to better communicate that this attribute does not offer any
guarantees that can be relied upon. To find out if a Box is an
authentic Box, you must unseal() it, not just check its label.

> > I've composed an initial list of security properties. I'd like us to
> > criticize: the completeness of the list, the terminology used in the
> > list and the definitions used in the list.
> >
> > For a brand A, the following security properties must hold:
>
>    ? def [sealer, unsealer] := <elib:sealing.makeBrand>("A")
>    # value: [<A sealer>, <A unsealer>]
>
>    ? def brand := sealer.getBrand()
>    # value: A
>
> > Spoofability
> >     Without possession of Unsealer A , it is not possible to determine
> > if a Box is an authentic Box A.
>
> In E-on-Java, possession of the brand is sufficient:
>
>    ? def SealedBox := <type:org.erights.e.elib.sealing.SealedBox>
>    # value: SealedBox
>
>    ? (sealer.seal("foo") :SealedBox).getBrand() == brand
>    # value: true
>
> I do not know whether this or its lack is a desirable property, nor
> whether it is possible to implement in a cryptographic system. This
> property could be removed from E by hiding the SealedBox guard.

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.

> > 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.

> 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.

>
>    ? def box := sealer.seal([].diverge())
>    # value: <sealed by A>
>
>    ? unsealer.unseal(box).push(1)
>    ? unsealer.unseal(box)
>    # value: [1].diverge()

Thanks,
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/