The Vanadium security model defines mechanisms for identification, authentication, and authorization. The model supports fully decentralized, fine-grained, and auditable delegation of authority.
For example, Alice could choose to delegate access to Bob only under the following conditions:
- the operation is
- the current time is between
6PM and 8PM, and
- Bob is in Alice's
- Bob is in close physical proximity of Alice
Such delegations do not have to go through the cloud or any centralized service, can be accomplished by a single interaction between Alice and Bob, and encode an audit trail of the principals involved in the delegation.
All network communication is always mutually authenticated and encrypted. The model is heavily influenced by the work on Simple Distributed Security Infrastructure by Ronald Rivest and Butler Lampson.
Principals & blessings
The security model is centered around the concepts of principals and
blessings. A principal in the Vanadium framework is a public and
private key pair. All Vanadium processes act on behalf of a principal.
The notation (
PAlice, SAlice) is used
to refer to the public and private key respectively of a principal Alice.
Principals have a set of human-readable names bound to them, via blessings.
For instance, a television principal, represented by the key pair
Ptv, Stv), may have a blessing from the
manufacturer with the human-readable name of
Principals can have multiple blessings bound to them and thus have multiple
names, each reflecting the principal that granted the blessing. For example,
the particular PopularCorp tv owned by Alice might also have the name
Principals are authenticated and authorized based on the blessing names bound to them.
For example, a service may grant access to
alice:devices:hometv, which means that all
principals with a blessing name matching
alice:devices:hometv will have access.
Service administrators always use blessing names, not public keys, when making
authorization decisions or inspecting audit trails.
Concretely, blessings are represented by public-key certificate chains bound to the
principal's public key. For example, the name
popularcorp:products:tv could be bound to the public key
Ptv using a chain of three certificates:
- Certificate with public key
popularcorp, chained to
- Certificate with public key
products, chained to
- Certificate with public key
Chaining means that the certificate is signed by the private counterpart of the
public key in the previous certificate. The first certificate in the chain
is self-signed, i.e. signed by private counterpart of the public key mentioned
in the certificate (
Ppopularcorp in this case).
The first certificate is also called the root certificate and the first certificate's public key is called the blessing root.
The term blessing is used to refer to a certificate chain and the term blessing name is used to refer to the human-readable name specified in the certificate chain. If it is clear from the context, then blessing may be used in lieu of blessing name for brevity.
The private key of the principal will generally be hosted by a TPM (Trusted Platform Module) or an agent process and will not be held in memory of the application process to protect against leakage. Private keys are never sent on the network and are used only for digital signing operations.
Clients and servers in a Vanadium remote procedure call (RPC) always act on behalf of a principal, and mutually authenticate each other via blessings bound to the other end's principal. The Vanadium authentication protocol allows clients and servers to exchange blessings bound to them, and verify that the other end possesses the private counterpart of the public key to which their blessings are bound. At the end of the protocol, an encrypted channel is established between the client and server for performing the RPC. Forward-secrecy safe protocols (like TLS with ECDHE key exchanges or a NaCl box with ephemerel keys) are used for setting up the encrypted channel.
The authorizations associated with a principal are determined solely by the blessings bound to the principal. Delegation of authority across principals is achieved via the Bless operation. Bless allows a principal to extend one of its blessings and create a blessing bound to another principal's public key, thereby delegating any authorizations associated with the blessing.
For example, a principal (
Palice, Salice) may bless another principal
Ptv, Stv) by extending one of
her blessings, say
alice, with a certificate with the name
devices:hometv and the tv's public key
Ptv. This certificate is signed with the secret key of the blesser
Salice). The blessing can therefore be viewed as making
Ptvcan use the name
Blessing names are thus hierarchical, with colons used to distinguish the
alice) from the blessee (
In practice, delegation of authority is never unconditional and this is
supported by the security model. Blessings can carry caveats that restrict the
conditions under which the blessing can be used. For example, a principal
Palice, Salice) can bless
another principal (
alice:houseguest:bob but with the caveat that the blessing can only be used
to talk to her TV (and not to remote services that Alice uses).
This caveat is specified in the certificate written by
alice (for Bob's public key
Pbob). Thus the blessing makes a signed statement of
Pbobcan use the name
alice:houseguest:bobas long as
When Bob presents this blessing to a server, the server will recognize the
alice:houseguest:bob only if the server's own blessing name
Caveats can be placed on any information available at the time of the request. This includes, among other things, the time the request is being made, whether the blessing wielder is a client or a server, the communication protocol being used and the method being invoked.
Validation of some caveats may involve expensive computation or I/O or
information not accessible to the authorizing service. In such cases, the
blesser can push the burden of validation to a third party (i.e., neither the
party that wields the blessings nor the party that is authorizing them). For
example, Alice can allow Bob to use the blessing
alice:houseguest:bob only if
bob is within 100 feet of Alice's home. When bob wants to authenticate as
alice:houseguest:bob, he must obtain a discharge (proof) from the third-party
home_proximity_discharger (mentioned in the caveat) before he can
use the name
alice:houseguest:bob. Thus the blessing makes the signed
Pbobcan use the name
alice:houseguest:bobas long as
home_proximity_dischargerissues a discharge after validating that
"within 100 ft"of it.
By using such third-party caveats, the burden of making the network calls to obtain a discharge and the burden of any computation or I/O to validate the restrictions are moved to the wielder of the blessing and to the third-party respectively, away from the end at which the authorization decision is being made.
A blessing is considered valid in the context of an RPC if and only if
- the blessing is cryptographically valid, i.e., each certificate in the blessing's certificate chain has a valid signature.
- all caveats associated with the blessing are valid in the context of the RPC
- the blessing is recognized.
A blessing is recognized by a Vanadium application if and only if the application considers the blessing root as authoritative for the blessing name. (Recall that blessing root is the public key of the first certificate in the blessing's certificate chain.)
For example, an application may consider the root
Ppopularcorp as authoritative on all blessing names
that begin with
popularcorp. Such an application would then recognize the
popularcorp:products:tv if it is rooted in
All Vanadium applications are configured to consider certain blessing roots as authoritative for certain names, and this configuration may vary across applications.
In a remote procedure call, two authorization decisions need to be made:
- Does the client trust the server enough to make a call? Making a call reveals the identity of the client (i.e., its blessings), the object being manipulated, the method being invoked and the arguments.
- Does the server allow the client to invoke a method on an object with the provided arguments?
Both these decision are made using the following principle:
Authorization is based on validated blessing names
For example, a client may wish to invoke the
Display method on a service only
if the server presents a blessing matching the pattern
Similarly, the service may allow a client to invoke the
Display method only
if the client presents a blessing matching the pattern
The public keys of the client and server principals do not matter as long as they present a blessing with a valid name matching the other end's authorization policy. Each end ascertains the valid blessing name of the other end by validating all caveats associated with the blessing and verifying that the blessing is recognized.
A pattern is a blessing name that may optionally end in a
:$. If the pattern
ends in a `:$``, it is only matched by the exact blessing name. Otherwise, it
is matched by the blessing name and all its extensions.
For example, the pattern
alice:houseguest will be matched by the name
and its extensions (e.g.,
not by the name
alice:colleague or prefixes of the pattern (i.e.
alice). On the other hand, the pattern
alice:houseguest:$ would be matched
exactly by the name
Selecting a blessing
A principal may have collected multiple blessings and may need to choose which
subset of them to present when authenticating with a peer. It could present
all, at the cost of leaking sensitive information (e.g.,
bob is a houseguest
alice) when not necessary. Instead Vanadium provides a means to
selectively share blessings with appropriate peers.
All blessings for a principal are stored in a blessing store, akin to a cookie jar in web browsers. The store marks the blessings to be presented when acting as a server (and a server always reveals its blessings first as per the Vanadium authentication protocol). Clients select a subset of their blessings from the store to share with a server based on the blessing names of the server.
For example, Bob's blessing store can add the blessing
to the store only to be shared with servers matching the pattern
Thus, all servers run by alice (such as
will see the
alice:houseguest:bob blessing when Bob makes requests to them,
but any other servers that Bob communicates with will not know that he has this
blessing from Alice.
What is the plan for storing keys and blessings?
All "credentials" of a principal (its private key, blessings, recognized blessing roots) are stored in a
V23_CREDENTIALSdirectory on the file system. In the short term, the private key is kept encrypted at rest and decoded in memory by an 'agent' process. The 'agent' process is the only one with access to the private key and can audit usage of the key, similar to how 'ssh-agent' works. Longer term, we envision wider use of TPMs and the key being kept securely in them.
Why is authorization based on blessing patterns as opposed to fixed blessing names?
The main motivations for using patterns (as opposed to fixed strings) for authorization are to encourage delegation, enable auditing, and discourage insecure workarounds. For example, if Alice's tv authorizes based on the pattern
alice:houseguest, then an authorized principal Bob with the blessing
alice:houseguest:bobcan delegate Carol to use the tv by blessing her with the name
alice:houseguest:bob:friend(with appropriate caveats). This name would match the blessing pattern
alice:houseguest. By making safely constrained delegation easy, Vanadium aims to discourage insecure workarounds. If delegates were not authorized and Bob really wanted to share access to Alice's tv with Carol, he may be tempted to work around the restriction by running a proxy service for Carol. Alternatively, he could create a new private key, get that blessed as
alice:houseguest:boband share the key with Carol. By making blessings and patterns easy to use instead, Bob is discouraged from trying out these hacks.
Having said that, patterns can also terminate with a
$which forbid delegation. So the pattern
alice:$will only be matched by the blessing name
aliceand not by
alice:houseguestetc. While this facility does exist, application developers and administrators are encouraged to think hard about why they want to disallow delegation and whether doing so will encourage hacky, insecure workarounds.
Why does the pattern
alice:houseguestnot match prefixes like
alice:houseguestmatches the blessing name
alice:houseguestand any delegates like
alice:houseguest:carol, but not
aliceitself. Doing so does not really prevent
alicefrom accessing the resource, as
alicecan generate the blessing name
alice:houseguest:foofor herself at any time. However, this does protect against accidental use of authority.
Think of how
sudoworks in UNIX-based systems. Users with
sudoaccess can act as the superuser, but they must explicitly do so by invoking the
sudocommand. Similar to that,
alicecan generate the blessings required to access resources protected by the pattern
alice:houseguest, but she must explicitly choose to do so by blessing herself.
The authorization story described above demonstrates that there are two ways to authorize a client to invoke methods at a server: (1) add the blessing names of the client to the access list, or (2) bless the client, providing it with a blessing name (with caveats) that matches an existing entry in the access list. Which method is appropriate?
The appropriate method of authorization would depend on who wants to authorize whom and why. For example, consider these simple questions:
Do you have the ability to change the access list?
It is likely that only
alicecan change the access list on the tv (since she owns it). Thus, if
alice:houseguest:bobwants to provide
carolwith access to the tv, his options are to either bless
aliceand trouble her to change the access list or try workarounds like proxying the RPC.
On the other hand, if
daveshould be able to access the tv then she can add
daveto the access list and avoid the need to communicate with
dave(to bless him) first.
Are there conditions on the access?
Blessings allow for caveats on their use. For example,
alice:houseguest:bobcan only be used within 100ft of the house. For simplicity, Vanadium currently intends to support such caveats only on blessings and keep access lists as simple lists of patterns (instead of being able to specify arbitrary caveats in the access list).
What are the privacy implications of exchanging blessings using the Vanadium authentication protocol?
Blessings can often contain personally identifiable information such as usernames and email addresses, and therefore revealing them to unauthorized parties poses a privacy risk. (Note that revealing blessings to unauthorized parties does not pose a security or authorization risk as the blessings can only be used by the principal they are bound to.)
The Vanadium authentication protocol ensures that blessings are always exchanged over an encrypted channel and thus are protected from passive eavesdroppers. Protecting blessings from active attackers -- ones that can pose as a legitimate peer to the client or the server -- is more challenging. The protocol protects the client's blessings from being revealed to unauthorized recipients at the cost of revealing the server's blessings to all clients.
Servers always reveal their blessings first. This means that any client can learn the server's blessings by making a request to the server. The server can choose what blessings it authenticates with, and it is advisable that the server only choose blessings that it is comfortable revealing to all clients.
Clients reveal their blessings only after seeing the server's blessings. Clients can control the blessings revealed to individual servers by tagging blessings with server patterns in their blessing stores. A server pattern is a blessing pattern indicating that the specific blessing it accompanies can only be revealed to servers that have a blessing name matching the pattern.
For example, if a client has a blessing
alice:houseguesttagged with the pattern
alice:devicesin its blessing store then the blessing will only be revealed to servers that have blessings matching the pattern
alice:devices:tv). Other services (e.g.,
carol:homedoor) that the client communicates with will never see this blessing and thus never learn that the client is Alice's houseguest.