[cap-talk] Description of s13

[Jonathan S. Shapiro]

Jed:

I would like to "go meta" on this conversation.

The reason we are having so much trouble in our discussion of S13 is
that the description given in that section of Managing Domains leaves
too many things unstated. Perhaps it relies on statements elsewhere in
the document that I had no time to find. Here are some things one needs
to know that are not clearly stated stated in that section:

1. When are keys generated? I have asked this several times, and I don't
recall that you have answered this yet.

2. Which parts of which keys are held by whom? Which parts by the
respective domains and which parts by their supervisors? Without this,
it is not possible to assess what protection is actually achieved.

3. The description does not describe who is responsible for which parts
of which transforms. The domains? The supervisor? The transport?

4. The notation of the diagram is confusing. I understand the
annotations on the arcs and the "in memory" notations (though the "in
memory" notations appear poorly chosen to me). I do not understand the
annotations *inside* the domains that seem to appear at the head/tail of
the arcs, and these are not explained. Hmm. On reflection, the head/tail
annotations appear to describe the cryptographic transform applied at
the sender/receiver sides. I still need to know who does the transform
(app or supervisor or transport).

5. Issues of transmission are being horribly conflated with issues of
in-memory capability protection. This makes the entire picture
unnecessarily complicated. Combined with my issues [1,2] I find the
whole thing fairly incomprehensible.

In the absence of clear statements on points [1,2], it is not possible
to say whether this scheme is protected.

Here are my *conjectures* on the answers:

[1] I still don't know.

[2] Every domain X holds Xu (it's own decryption key). Any domain A may
promiscuously obtain the encryption key Bd for a second domain B.

[3] All encryption is performed by the respective applications. There is
no encryption assumed by supervisor or transport.

[4] Notations at tail/head of arc describe transform applied by the
respective domain prior to send and after receipt, respectively.


If these assumptions are correct, then the scheme fails in its primary
objective (preventing memory theft). Note in particular that the memory
image of A contains Au, and further contains many things of the form
Ad(s), where s is some bit string. It is not at all difficult for an
attacker to apply one to the other by scanning memory for plausibly
random bit strings to discover the keys. Because of this, having A hold
Ad(Su(c)) in memory is equivalent to holding Su(c) in memory. Once Su(c)
is stolen, the thief may apply Xd(Su(c)) to create a validly encoded
capability for an arbitrary domain S.

If these assumptions are correct, this scheme is definitely NOT
observably confinable, because there is no way to know what capabilities
a domain X holds. Knowing the communication links available to X may be
conservatively sufficient, but probably not in practice.

shap
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC