non-bearer/swissNum sturdyrefs

[Christopher Lemmer Webber]

I admire how E takes the approach that SturdyRefs give you an entry
point into a vat, and then the rest of the connections you have to ocaps
in the vat flow from mostly liverefs that come from that initial entry
point (or, well, other SturdyRefs).

That said, I think something that tends to make people nervous about
SturdyRefs is the "what happens if there's a breach?" scenario. Now you
might say, well, the best thing is to not have breaches, but it seems
like our architectures are still so insecure that even entities that are
trying their hardest get breached.

I think that points to part of the nervousness about swissNums: if you
get breached, even if you can restore your system state to a point
pre-breach, anyone who can *see* the swissNums can now access them. You
can revoke all those sturdyRefs, but now you've cut off access to your
system by the people you still want to connect. You also leak access to
all your outgoing connections.

I'm not sure whether we can do anything about the leakage of outgoing
connection access, or at least I'm not going to consider it for the
moment. Instead, let's consider... can we make a better incoming
sturdyRef?

One way to do it might be to have each sturdyRef correspond to a unique
signing/verification keypair. Internally, the verification key points
to the appropriate object. The external entity holding the sturdyRef
would now like to connect to the vat and its object, so it tells the vat
"hey, I'd like to invoke this sturdyRef now". The vat returns a nonce
which the sturdyRef holder must sign along with the invocation. This
flow happens every time an invocation occurs. (The reason the vat
provides the nonce every time is it prevents the vat from having to
store state of past invocation nonces, only currently-pending nonces,
but I suppose you could reduce round trips by letting the invoker
sign both the nonce along with a timestamp.)

Again, one-off-keys are critical here.

Perhaps this has been discussed before. Forgive me, I'm new. :)

Anyway, what do people think?
- Chris

[Mark S. Miller]

At http://wiki.erights.org/wiki/Capability-based_Active_Invocation_Certificates Baldur (cc'ed) wrote:

> 5. In a PostalRef scenario. (PostalRefs are offline like SturdyRefs but you can send it eventual sends which will then be written out as authroization/active cert(s))

Hi Baldur, I think this is relevant to Chris' question, but I couldn't find any further explanation of PostalRefs. Could you explain? Thanks.

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To post to this group, send email to cap-...@googlegroups.com.
Visit this group at https://groups.google.com/group/cap-talk.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/87a7dw4is1.fsf%40dustycloud.org.
For more options, visit https://groups.google.com/d/optout.

--

  Cheers,
  --MarkM

[Baldur Jóhannsson]

A PostalRef is more akin to a far ref or remote promise than SturdyRef.

But instead of live refs spanning between vats via CapTP connections ontop of VatTP connections those PostalRefs accumulate eventual sends.

Those accumulated eventual sends are then encoded into ActiveCapCerts. Those I call letters or postcards depending on the confidentiality sought.

How those letters or postcards are then moved between vats is not something I have decided on and probably let clients of particular starting PostalRef sort that out.

What I suspect you are after is how ActiveCapCerts bridge into the world of live near refs at destination vats.

As stated in the linked erights wiki page an ActiveCapCert is nothing more than public key cryptographically signed source code that becomes the function body of a closure when instanciated at the recipiant vat. ActiveCapCerts are signed by their issuing vats private key.

The enviroment of aforesaid closure is the safeScope plus an lazy map of issuers public keys to sealers and the unsealer of the issuer of this ACC.

Iff the issuer of this ACC happens to be the recipiant vat itself then that enviroment also gets an FlexMap we can call the pet_binder. It maps petnames to objects.

Aforesaid pet_binder can already have some bindings in it put there when the vat was (re)incarnated per the vat specific initialization or reincarnation code. (Basically by policy)

In the usual granovetter intro scenario Alice has already been given, out-of-band, an ACC issued by VatC that is of the form:

// ecmascript 5 strict semantics and syntax
return getSealerOfIssuer(«VatAs public key or fingerprint thereof»).seal(pet_binder["Ye Olde Carolina"]);

signed by VatCs private key. Now, Alice can embed this ACC in her own ACC of the form:

const Carol = myUnsealer.unseal(ActiveCapCert(«base64 or other such full cert form of above ACC»)());
// do something with Carol here

(Replace the stuff between the «» with apropos contents).

As you see, Malroy (or was it Mallet?) can not gain any authority or access to Carol knowing the above ACCs or the petname string "Ye Olde Carolina", unless of course Alices above ACC delegates such or attenuation thereof to him.

Does this sketch out enough to give you an inkling about how to do such non-bearer sturdy ref esque things, Christopher?

To unsubscribe from this group and stop receiving emails from it, send an email to cap-...@googlegroups.com.

To post to this group, send email to cap-...@googlegroups.com.
Visit this group at https://groups.google.com/group/cap-talk.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/87a7dw4is1.fsf%40dustycloud.org.
For more options, visit https://groups.google.com/d/optout.

--

  Cheers,
  --MarkM

PS. Was the English in this message as rough as the wool of Icelandic sheepwool sweater, Mark? (just a bit of a gag here, think nothing of it ;-Þ )

PPS. I am also terrible at naming things in English.

[Bill Frantz]

Christopher's approach is similar to the SPKI (Simple Public Key
Infrastructure, not some other expansion of the acronym that
popped up later).

Mapping SPKI to the SturdyRef, vatA would issue a certificate to
vatB and sign it with vatA's signing key. This certificate
allows vatA to get a live reference to the object specified in
the certificate. In doing so, vatB must sign the challange sent
by vatA as part of the protocol.

If vatB wants to pass the certificate to vatC, is generates a
new delegation certificate and signs it which it passes to vatC.
vatA will check vatB's signature before engaging in the protocol
to get a live reference.

Note that since the users of the get live reference protocol
have to prove they have the signing key for the certificate, the
certificates can be public information. They don't need to be
kept secret.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz | Truth and love must prevail | Periwinkle
(408)356-8506 | over lies and hate. | 16345
Englewood Ave
www.pwpconsult.com | - Vaclav Havel | Los Gatos,
CA 95032

[Neil Madden]

Comments below

An aside, but unless you need 3rd-party verifiability or non-repudiation then you don’t need to use signatures for this. (Elliptic Curve) Diffie-Hellman can be used instead:

Rather than generating a nonce, the server generates an ephemeral key-pair and sends the client the fresh public key as the challenge. The client performs DH between the challenge public key and the private key (massociated with this sturdyRef to derive symmetric key(s). The client then sends its request using the symmetric keys for authenticated encryption (or just HMAC). 

The server can derive the same keys by DH between the ephemeral private key and the public key associated with the sturdyRef. 

See Noise [1] or CurveCP [2] for fully worked out protocols.

I believe DH is already used for vat-to-vat connections so this would allow the same primitives to be used for both cases. 

That said, there are simpler half-way measures that may be more performant:

1. The server can store a secure hash of the Swiss number. Assuming the Swiss number is unguessable then the hash cannot be brute forced.

2. A solution I like when the Swiss numbers (OAuth tokens in my case) are stored in a database that is external to the server is to give the server a separate HMAC key. The server then signs the Swiss numbers when sending them to other vats so that the external form is:

Swiss number + hmac(key, Swiss number)

As the HMAC key is kept separate from the database (ideally on a different machine), anyone who compromises the database through SQL injection or whatever cannot create a valid reference even though they know all the Swiss numbers. 

The second solution is nice because the server vat can quickly authenticate an incoming reference before performing any database lookup, and you can easily avoid timing attacks against database lookups. Finally, you can then swap the raw HMAC scheme for Macaroons and start appending caveats if you wish. 

[1] https://noiseprotocol.org/

[2] https://curvecp.org/

— Neil

[Christopher Lemmer Webber]

Neil Madden writes:

> An aside, but unless you need 3rd-party verifiability or
> non-repudiation then you don’t need to use signatures for
> this. (Elliptic Curve) Diffie-Hellman can be used instead:
>
> Rather than generating a nonce, the server generates an ephemeral
> key-pair and sends the client the fresh public key as the
> challenge. The client performs DH between the challenge public key and
> the private key (massociated with this sturdyRef to derive symmetric
> key(s). The client then sends its request using the symmetric keys for
> authenticated encryption (or just HMAC).
>
> The server can derive the same keys by DH between the ephemeral
> private key and the public key associated with the sturdyRef.
>
> See Noise [1] or CurveCP [2] for fully worked out protocols.
>
> I believe DH is already used for vat-to-vat connections so this would
> allow the same primitives to be used for both cases.
>

> [1] https://noiseprotocol.org/
> [2] https://curvecp.org/

That's interesting; I never thought of this before.

> That said, there are simpler half-way measures that may be more
> performant:
>
> 1. The server can store a secure hash of the Swiss number. Assuming
> the Swiss number is unguessable then the hash cannot be brute forced.

That's a really good idea.

> 2. A solution I like when the Swiss numbers (OAuth tokens in my case)
> are stored in a database that is external to the server is to give the
> server a separate HMAC key. The server then signs the Swiss numbers
> when sending them to other vats so that the external form is:
> Swiss number + hmac(key, Swiss number)
> As the HMAC key is kept separate from the database (ideally on a
> different machine), anyone who compromises the database through SQL
> injection or whatever cannot create a valid reference even though they
> know all the Swiss numbers.
>
> The second solution is nice because the server vat can quickly
> authenticate an incoming reference before performing any database
> lookup, and you can easily avoid timing attacks against database
> lookups. Finally, you can then swap the raw HMAC scheme for Macaroons
> and start appending caveats if you wish.

Hm interesting. I need to think about this one a bit more, but I
appreciate these ideas... good stuff to think about.