/ elib / capability

Delegating Responsibility in Digital Systems: Horton's "Who Done It?"

Delegating Responsibility in Digital Systems:
Horton's "Who Done It?"

by Mark S. Miller, Jed Donnelley, and Alan H. Karp

Download Horton

Horton paper at Usenix Hotsec07 -- hot topics in security

Presentation (PPT) (PDF)

Horton in stages

• The simplified Horton code from the draft paper as an executable test case. There are many simplifications in this code that need to be repaired to build a realistic Horton system. Here's a dependency graph of these fixes:
  • Handling n arguments. We use this as a base for motivating Horton's complexity. To understand why Horton isn't simpler, we need to examine what attacks are possible in these simpler systems.
    • Alice frames Bob. If Horton's wrap/unwrap functions were instead simple identity functions, then Alice could fool Carol into blaming Bob for messages sent by Alice.
    • Alice frames Carol. If we fix the above problems by implementing wrap/unwrap directly in terms of seal/unseal, Alice could still fool Bob into blaming Carol for bad service provided by Alice.
    • Alice frames Alice poorly(not ready yet). With both of the above problems fixed, i.e., in the real Horton system, Alice can still fool Bob and Carol into blaming Alice rather than each other. We consider this a feature, not a bug: Alice can elect to delegate authority while retaining full responsibility. Even in a naive distributed implementation, Bob and Carol are put in direct contact while still blaming Alice, demonstrating the unbundling of responsibility-tracking from remoting. However, the responsibility-taking technique shown here has problems.
    • Alice frames Alice well(not ready yet). The alternative responsibility-taking technique shown here does not have the previously shown problems. However, in a naive distributed implementation it still leaves Alice in the middle.
• Using eventual sends to preserve liveness between principals.
• With the principals ditributed across different vats.
• With "why" fields
  • For petnames
  • For reputation budgets
• Making better use of lexical nesting.
  • Using rights amplification to protect against app-object misbehavior.
    • Mailkeys as a Horton-like protocol.
• Handling n arguments & return results
• As an extension of pseudo-serialization
• Finally, having explained these extensions individually, we show them combined into the complete Horton system.