[cap-talk] A problem in EQ-free grant matcher?

[Dean Tribble]

That sounds right, and applies generally to such problems.

I vaguely recall that in Joule, we made a Nonce class (they were
called something else) to package that pattern up efficiently. Nonce
provided a comparison operation that *could* be implemented using
sealer/unsealers as described, but in typical cases, was provided
primitively. It was used by sealers and unsealers in their exposed
interaction to prevent the MITM attacks you pointed at. Thus, the
semantics were entirely in terms of message passing and closed-over
state, but the implementation could use "eq".

BTW I should clarify that having objects that *choose* to participate
in an "EQ" protocol is still different than having a system in which
"EQ" is provided primitively as a meta-operation. Indeed, many of the
techniques for avoiding a primitive EQ rely on the fact that
components can "opt-in" where necessary or appropriate.

On Feb 19, 2008 4:26 AM, Toby Murray <toby.murray at comlab.ox.ac.uk> wrote:
> Hi Dean,
>
> thanks for commenting. Just to unpack that a bit, and after thinking
> about what you've said, I think what has to happen is:
>
> - The GrantMatcher should ensure that all of his unsealers have synergy
> with each other, in some way, such that they (or some forwarder for
> them) can be "coerced" to a reference to a true authenticated unsealer.
>
> - This sort of synergy+coercion primitive can certainly be built from
> plain  object-caps, as has been demonstrated before on this list, so
> this certainly doesn't necessitate EQ.
>
> [ see e.g.
> http://www.eros-os.org/pipermail/cap-talk/2006-December/006573.html ]
>
>
> - Each Charity then holds a coercer capability (given by the
> GrantMatcher by prior arrangement) that can be used to coerce
> potentially untrustworthy unsealers into authenticated sealers.
>
> - Only if the coercion is successful, should a charity invoke an
> unsealer.
>
> This would appear to defeat the attack.
>
> Does that sound about right?
>
>
>
>
> On Mon, 2008-02-18 at 11:52 -0800, Dean Tribble wrote:
> > I'm heads-down on a deadline at the moment, but will surface later
> > this week.  The basic approach is to recursively apply the
> > sealer/unsealer techniques to the establishment of synergy in the
> > sealers. That may be roughly equivalent to "some sort of synergy
> > between the GrantMatcher and every possible charity", though....
> >
> > On Feb 18, 2008 4:11 AM, Toby Murray <toby.murray at comlab.ox.ac.uk>
> > wrote:
> >         Very cool.
> >
> >         I modelled this same example in CSP to see whether I could
> >         detect this
> >         attack. I could, but I also found a simpler one, which is
> >         described at
> >         the end of this message.
> >
> >         The upshot of both attacks is that in order to do Grant
> >         Matching without
> >         EQ, we need some sort of synergy between the GrantMatcher and
> >         every
> >         possible charity so that every possible charity can
> >         distinguish when it
> >         has been passed an unsealer from GrantMatcher or not. Without
> >         this, both
> >         attacks seem possible.
> >
>
>
>
> > _______________________________________________
> > cap-talk mailing list
> > cap-talk at mail.eros-os.org
> > http://www.eros-os.org/mailman/listinfo/cap-talk
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>