Rights Amplification

Rights amplification is a security mechanism where bringing two or more authorities into one place results in a new authority. That is, the whole is greater than the sum of its parts.

Most implementations of CapabilitySecurityModels support some form of RightsAmplification.

MarkMiller?'s EeLanguage (which supports ObjectCapabilityModel) achieves this via sealer/unsealer pairs. That is, you can create a pair of objects such that the 'sealer' can seal the message it receives, and only the 'unsealer' can later unseal the message. This is a RightsAmplification mechanism because it takes both the sealed message and the unsealer to have the authority to read the message (which may, of course, contain more capabilities).

EeLanguage supports this as a primitive; the 'sealer' doesn't perform any encryption unless the sealed message crosses host boundaries. Presumably, a sealer/unsealer could be implemented by pure objects via use of a serialization and encryption algorithm, but doing so is non-trivial (especially when dealing with object names, generic type-safety, and obtaining random bits).

The sealer/unsealer rights amplification can be used for a number of things. One could use it to implement first-class type abstractions, to secure a dataflow, to track 'responsibility' (see http://www.erights.org/elib/capability/horton/), to force a quorum, even to implement (ugh) ACLs, and so on.

PasswordCapabilityModel, or at least a few variations of it like SimplePublicKeyInfrastructure, perform rights amplification by a more direct approach. Basically, you get two certificates. One of them says: "People who have a need to know about Foo also need to know about Bar, signed Alice." Another of them says "John needs to know about Foo, signed Alice." The first certificate provides a rule that amplifies the latter, granting John a right to know about Bar. The potential complexity of such rules depends only upon the language used to describe them.

A RightsAmplification mechanism goes a long way to allowing developers and users to capture interesting security patterns and policies.


EditText of this page (last edited January 5, 2010) or FindPage with title or text search