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

[Kevin Reid]

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

The elib.sealing.Brand (from a client's perspective) reliably  
identifies the group without giving any other authority; it is  
available everywhere your protocol offers 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.

> 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. A crypto- 
sealed box in E would, however, require that its contents be Data  
(immutable and serializable).

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

   ? unsealer.unseal(box).push(1)
   ? unsealer.unseal(box)
   # value: [1].diverge()

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>