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

[Kevin Reid]

On Mar 22, 2007, at 17:57, Tyler Close wrote:
> On 3/22/07, Kevin Reid <kpreid at mac.com> wrote:
>> 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.
>
> 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.

I have no objection to this renaming if MarkM agrees. However, if I  
were renaming things I would rename the constructor rather than the  
"label".

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

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.

To expand on my example:

    ? def verified :SealedBox := something
    # value: <sealed by A>

    ? verified.getBrand() == brand
    # value: true

It is now known that 'verified' is a genuine box sealed by A.

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

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

I think it would be reasonable to allow SturdyRefs in a crypto-sealed  
box; creating SturdyRefs to represent live refs would not be, as the  
lifetime of the SturdyRef could not be correctly managed.

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