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

[Toby Murray]

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.

Now we rely not only on the GrantMatcher but also on all charities to
invoke only unsealers make by GrantMatcher.

I'm hoping that someone more familiar with the Grant Matcher puzzle will
step in here and tell us what assumptions are being violated by these
attacks. Dean? MarkM? anyone?

In order to tease out the assumptions I'm choosing to, and to not, make,
here's what I modelled roughly translated to E.

def makeGrantMatcher() {
   # allow each party to invoke us only once
   var aliceHasInvoked := false
   var danaHasInvoked := false
   var aliceCharity := null
   var danaCharity := null

   def tryGiveToCharity() {
      if (aliceHasInvoked && danaHasInvoked){
         def [sealer, unsealer] := makeBrandPair("")

         # the actual donation doesn't matter
         def donation { }

         def box := sealer.seal(donation)

         aliceCharity <- giveUnsealer(unsealer)
         danaCharity <- giveSealedPurse(box)
  
      }
   }

   # alice has a cap to this facet
   def aliceFacet(charity) {
      if (!aliceHasInvoked){
         aliceHasInvoked := true
         aliceCharity := charity
         tryGiveToCharity()
      }
   }

   # dana has a cap to this facet
   def danaFacet(charity) {
      if (!danaHasInvoked){
         danaHasInvoked := true
         danaCharity := charity
         tryGiveToCharity()
      }
   }

   return [aliceFacet, danaFacet]
}

def makeCharity  {
   var gotUnsealer := false
   var gotSealedPurse := false
   var unsealer := null
   var sealedPurse := null

   # charity expects to be given unsealer before sealedPurse
   def charity {
      to giveUnsealer(u){
         if (!gotUnsealer){
            gotUnsealer := true
            unsealer := u
         }
      }

      to giveSealedPurse(sp){
         if (gotUnsealer && !gotSealedPurse){
            gotSealedPurse := true
            sealedPurse := sp
 
            # get the donation
            unsealer <- unseal(sealedPurse)
         }
      }
   }
}


Alice starts out with capabilities to herself, charity, and her facet of
the grantmatcher. Symmetrically for Dana.

The simper attack I found goes like this:

We assume some charity that both Alice and Dana have capabilities to.
Call this object TheCharity.

1. Alice invokes the GrantMatcher passing herself as the supposed
charity 
2. Alice invokes the TheChaity (posing as the GrantMatcher) passing
herself as the supposed unsealer
3. Dana invokes the GrantMatches passing TheCharity as the charity
4. The GrantMatches invokes Alice (the first charity received) passing
the freshly created unsealer
5. The GrantMatcher invokes TheCharity (the second charity received)
passing the freshly created box that can be unsealed by the unsealer

-- NOTE: TheCharity has now received a supposed unsealer (step 2) and a
supposed box (step 5). What it has actually received is Alice instead of
the unsealer --

6. TheCharity invokes the supposed unsealer (really Alice) passing the
box

Alice now has both the unsealer and the box.



On Fri, 2008-02-15 at 18:34 -0800, Jim Larson wrote:
> Dean Tribble's EQ-free solution to the grant matcher problem (cap-talk
> list on 2006-12-11) goes as follows:
> 
> 1. Alice and Dana provide capabilities (A and D, respectively) for
> their respective charities to the Grant Matcher (GM).
> 
> 2. GM creates a new sealer/unsealer pair, and seals a donation purse P
> with the sealer, resulting in a sealed box B.
> 
> 3. GM passes the sealed box B to A and the unsealer U to D.
> 
> 4. If A and D are references to the same underlying charity C (or
> transparent forwarders to C), then C will be able to unseal B to get
> the donation purse.
> 
> However, what if D is a corrupt partial forwarder controlled by Dana?
> Instead of relaying U to C, D could instead substitute a false
> unsealer U'.  Once C calls U'.unseal(B), Dana has both the unsealer
> and the sealed box, and can run off with the purse!
> 
> I have a solution, but the margin of this email is too small to
> contain it.  I'll try to write it up over the weekend.
> 
> Jim Larson
> 
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk