[E-Lang] Lessons from ertpMint

Marc Stiegler marcs@skyhunter.com
Sat, 24 Feb 2001 01:47:10 -0700


The excitement about the ertpMint and the delightful security bug found in
the first version all occurred while I was on a trip. When I came back, I
embarked on an effort to apply the trust rules document that has been
mentioned here a couple of times as the first step towards automating trust
analysis in programs. The wild hope was that I could, by mechanically
applying the rules in that doc to the ertpMintMaker, spot the security
failure that I knew existed, but which I had refrained from reading about.

It was of course a wild hope. Markm and I both knew that the trust rules
document was incomplete and not really ready for this application. I was
unable to spot the bug just by following the rules. However, I did learn
several things in the process that may be useful:

-- Following the rules warned me that the following piece of the system was
improperly formed:

    to depositAll(src) :any {
     def assay := issuer vouch(src.assay)

It would be better to be:

    to depositAll(src) :any {
     def assay := (issuer vouch(src)).assay

I believe this is a correct identification of a weakness. The second form
allows the auditor to cut off analysis of possible forgeries sooner.

-- The following structure would be anathema for any truly automated system:

    to transfer(var src, dest) {
     src := issuer vouch(src)

because the automated system couldn't tell that the untrusted src object
wasn't receiving dangerous capabilities later in the method; the automated
system would wind up issuing bogus warnings. I submit it is also a little
hard for human auditors to work with too, though for the human programmer it
is more compact. Better for auditors (both human and automated) would be

    to transfer(untrustedSrc, dest) {
     def trustedSrc := issuer vouch(untrustedSrc)

or something of this nature.

-- the trust rules also said that the vouch(obj) method was something to
look hard at. However, the trust rules broke down by not telling me how to
look at it. In retrospect, I recognize that there is an aspect of the trust
rules that is glancingly implied by the doc as it now stands, but which is
not sufficiently explicit: a first step in the process is to identify
objects and methods that are truly capabilities, i.e., objects and methods
that convey authority. In the ertpMint, Hal spotted right off one criticial
object, the Incr object. What I missed utterly, and the trust rules helped
inadequately with, was recognizing that the "vouch" method in the issuer
object also conveyed an important unsealing authority.

-- Reflecting on this matter far into the night, I have concluded that
implementing "vouch" using sealer/unsealer pairs is a bad idea. I believe
Hal is correct that the problem can be fixed by using multiple vouchers, but
in fact those vouchers are still conveying unsealing authority and so have
to be watched carefully. In principle, a vouching operation just shouldn't
be conveying any authority at all. And because vouch is such a fundamental
part of multi-party security, we should identify a simple and standardizable
pattern for it, unswervingly use it ourselves, publish it in E in a Walnut,
etc. So in my next message, I propose 2 alternative patterns for an
authority-free vouching system for us to discuss.

--marcs