Tracking issue: IFC evolution

[tiziano88]

This is a tracking issue for upcoming (and some past) work related to IFC functionality in Oak.

The canonical references for IFC-related work are the following GitHub milestones:

• IFC v0: foundational work that is necessary to achieve a meaningful and sound IFC system in Oak; until this is completed, Oak should not be used in production
• IFC v1: additional work that allows implementing more expressive patterns or advanced functionality via IFC

Most of the logic behind IFC in Oak is similar to existing literature, but some of the concepts are implemented in a more practical way compared to previous academic work.

In particular, in Oak, the overall lattice of principals can be considered composed of sub-lattices, each dealing with one type of principal. The available principals (and corresponding sub-lattices) are:

User

A user principal represents the authority of a physical user (usually a person, but may also be a more abstract entity, e.g. a group of people, or a company).

The principal is identified by a public key, which represents the authority of a user possessing the corresponding secret key. In order to declassify data labelled with this principal, the user proves their identity directly to the Oak Runtime by producing a signature of a challenge (generated by the Runtime itself) with the secret key, without disclosing the actual secret key itself.

e.g.:

User a generates a key pair (sk_a (secret key), pk_a (public key)).

When connecting over gRPC to an Oak Application, the user agent (e.g. command-line client, web browser, mobile app) authenticates to the remote Oak Runtime by fetching a challenge from the Runtime (a random string generated by the Runtime itself), signs it with sk_a (which never leaves the client device), producing a signed challenge, and sends the signed challenge back to the Runtime, over the same gRPC channel. From this point onwards, the connection is authenticated, and the Runtime considers the other endpoint of the connection as controlled by the user with public key pk_a.

Persistent User Identity

The user key may be a persistent identity (e.g. an actual logged in user), in which case it may be used in conjunction with a more general Public Key Infrastructure (PKI) in order to match a more abstract user identifier to such key (e.g. via keybase, key transparency, or another registry of public keys).

For instance, if user b wanted to send data to an Oak Application in such a way that it may be received only by user a, b may look up pk_a on some PKI or registry, and then label data with a principal corresponding to pk_a itself. Data labelled in this way may then be further processed by the Oak Application, following standard IFC rules, resulting in any derived data also being labelled with pk_a. Finally, when a wants to retrieve such data (either original or derived), a would connect to the Oak Application, prove its identity by showing a proof of possession of sk_a (as described above), which would allow the Oak Runtime to declassify data labelled with pk_a within the gRPC or HTTP node that a is acting from.

Ephemeral User Identity

A similar but simpler case is that in which a user wants to send some data to an Oak Application, but the expectation is that data will only be used to fulfill a single request (or a small number of requests), but not persisted further. For instance, this may be used to emulate a behaviour similar to a Private Information Retrieval (PIR) protocol, but in which the "privacy" is enforced by IFC instead of a cryptographic scheme. To do this, the user agent generates an ephemeral key pair (sk_ε, pk_ε) (in the same way as for the persistent identity), but does not even publicize the public key anywhere. Instead, it labels data with pk_ε, while at the same time authenticating to the Oak Application with a proof of possession of sk_ε, over the same gRPC / HTTP connection. In this way, effectively the data is labelled in such a way that it may be retrieved only by the same client that generated the key pair. Note that if the application requires multiple interactions by the client, the client may actually use the ephemeral identity for as long as necessary. The identity is only ephemeral in the sense that no other party is expected to refer to it, apart from the generator of the identity itself. This is conceptually similar to generating a session key, and using it to encrypt data, which is expected to be retrieved by the same client.

Group Identity

Another use case is that in which a group of people (e.g. a, b, c as members of a team, with corresponding key pairs) want to create a shared identity that would allow any of the members to access some labelled data. In order to do this, the most natural solution would be for Oak to support disjunctions as part of compound labels, so that data may be labelled with pk_a ∨ pk_b ∨ pk_c. This is not currently supported though, but it may be emulated with the following scheme: a generates a fresh key pair (sk_t, pk_t) for the team (distinct from a's own key pair); it then publishes pk_t publicly and advertises is as the key for the team, and encrypts sk_t with sk_b and sk_c, and sends these encrypted keys to b and c, respectively, who can decrypt it and obtain sk_t. At this point, a, b and c are all in possession of sk_t, and may use it to authenticate to an Oak Application in order to retrieve data labelled with pk_t. This is similar to per-team keys in keybase.

WebAssembly module hash

TODO

WebAssembly module signature

TODO

Dependencies

• client-side
  • gRPC / protobuf
  • HTTP / JSON
  • provide a mechanism for attaching labels to HTTP requests to Oak Applications from Chrome #1347 Chrome support for labels
  • Client API for creating complex Oak labels #1265 Client API for creating complex Oak labels
• core
  • Assign labels on channel creation #975 Assign labels on channel creation
  • Introduce IFC tag for TLS certificate #820 principal for TLS certificate
  • Implement downgrading privilege for user principals authenticated over gRPC / HTTP #1452 principal for auth challenge / response
  • Channel Read Information Flow Violation #1197 Linear read handles
  • Only allow public Nodes to create entities #1167 Only allow public Nodes to create entities
• ABI / SDK
  • Implement support in the SDK for finding the Label associated with a channel #1406 finding the Label associated with a channel
• experimental
  • [IFC] support labels with implication between principals #1364 implication between principals
  • [IFC] support labels with parametrically polymorphic parameters #1371 parametrically polymorphic parameters
  • Represent enclave / platform / storage as IFC label principal #1473 Represent enclave / platform / storage as IFC label principal
• examples
  • Implement labels for examples #1066 Implement labels for examples