[cap-talk] solve CSRF by making references unforgeable, not unshareable

David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Thu Mar 26 14:55:55 EDT 2009

Toby Murray wrote:
> On Thu, 2009-03-26 at 00:31 +0000, Karp, Alan H wrote:
>> David-Sarah Hopwood wrote:
>>> There is not much reason to make a capability representation both
>>> opaque and sparse: it would be redundant. However, there is nothing
>>> to prevent it.
>> One of Jed Donnelley's systems (DCCS?) encrypted sparse capabilities
>> with a key not available to the process holding them in order to
>> prevent leakage when people read dumps.
> This was also done in the Monash Password Capability System to ensure
> confinement, even in the presence covert channels.

Encryption does not make the representation opaque, strictly speaking.
A representation is opaque when the attacker is not able to obtain the
bits of the representation at all; not being able to decode the bits
doesn't count, or at least should be called something else.

Encrypted capabilities work by being sparse (if they were only encrypted
but not sparse, then it would be possible to forge a random but valid
capability). In the Monash system, this was done by XORing with a
per-process mask, if I remember correctly, which is not a secure
form of encryption.

> see
> http://comjnl.oxfordjournals.org/cgi/content/abstract/29/1/1
> (Sorry, I have no idea whether that link is behind some kind of
> firewall-implemented identity-based access control that filters on IP
> addresses or something, in which case the "Full Text" link that I can
> see might not be shown to others. Damn ambient authority.)

It is, but here is a public copy of the same paper:


David-Sarah Hopwood ⚥

More information about the cap-talk mailing list