[cap-talk] network level designation and authorization, meta

[coderman]

On 6/19/06, Jed at Webstart <donnelley1 at webstart.com> wrote:
> ...
> >Coderman (full name??): >

apologies, martin peck.


> As I read the whole discussion, the focus is on protecting data on the
> wire (air).  I have to admit that I think of this topic as pretty much a
> solved problem (e.g. SSL).

i guess i agree in the sense that SSL (with self signed certs) could
solve this problem, just like openvpn uses SSL to solve the problem of
privacy between IPv4/IPv6 endpoints.

what i intended to focus on was that solving this problem should be
done at an IP endpoint level so that all services supported between
peers (that is, user centric) could share this authenticity and
privacy bootstrap.

what i wanted to move away from is every application or service level
protocol bolting an auth+privacy layer in front of their intended
purpose, like HTTPS, STARTTLS, etc.


> All this discussion applies (I believe) as well to protecting data as it
> does to protecting capabilities (generalized authority tokens) during
> communication.

there may be additional protection of capabilities above and beyond
communication channel authentication and privacy.  for example, using
public keys to facilitate inter-domain capability use instead of
data/token/id based capabilities.

as for protecting data (which is indeed relevant) i touched on this a
bit outside of the communication realm by suggesting full disk
encryption as a best practice and mandatory for good security.


> I would like to mention in this context the problem of protecting
> capabilities (authority tokens) in the memory of programs.  ...
> I would like to point out that for such
> vulnerable capability representations, there is more than just
> vulnerability on the wire (air) to consider, but also vulnerability
> in memory.  E.g. in process dumps, system dumps, on disks,
> etc.

protecting memory is hard, protecting disks less so.  any ring0
exploit compromises all of the keys present in memory or on disk.  if
you assume the operating system remains secure then locking memory
pages can prevent some disclosure of keys to disk (unencrypted swap
space or core dumps, etc).

likewise, full disk encryption can help ensure that anything saved to
disk will be kept private in the case of offline theft.  (for example,
bookmarks containing YURLs, the browser login manager (saved site
logins), etc).


> I developed a potential solution to this problem many years ago:
>
> http://www.webstart.com/jed/papers/Managing-Domains/#s13

i like the public key method you describe for protecting capabilities
between domains.  you mention "Its major weakness is the processing
costs involved in the transformations required." and i'd suggest that
this is very tractable with something like a padlock core that can
offload 4096 bit montgomery multiplication to hardware.

i'd love it if every CPU manufactured included entropy, AES, SHA, and
montgomery multiplication on die.  the space required is small enough
that there really is no good reason not to include it given the major
benefits provided (cryptographically secure random numbers, speed of
crypto operations, resistance to many side channels present in
software implementations, etc)

anyway, that's a longer and more off topic discussion...


> that incidentally also protects capabilities if communicated
> over un encrypted channels (though of course not protecting
> the data which is considered less sensitive, but likely should
> also be protected - as this thread addresses).  I've discussed
> this issue and the above implementation with others personally,
> but I think not in this broad context on the list before.

this is why i mentioned that you may want additional capability
security on top of communication privacy.  for the password / data
based capability representations communication privacy may be
sufficient.


> I believe this issue is independent of the topic of cryptographic
> protection of process to process communication (the focus of
> this thread to this point I believe).  I also believe, however, that
> appropriate protection of communicated authorities requires
> protection for them in memory (unlike data in general) in addition
> to protection on the wire (air).

agreed, though this is a much harder problem. i keep thinking of an
ibutton type hardened token which could manage such public key based
capabilities securely by keeping private keys out of system memory
entirely.

in any case, this issue goes beyond communication privacy as you
indicate and is important to consider lest someone think their
security problems are solved once transmitted data is encrypted.