github.com/jlmucb/cloudproxy@v0.0.0-20170830161738-b5aa0b619bc4/Doc/Authentication.txt

Authentication in the Cloud, 
i.e. A Survey of Approaches to Authentication for Tao Applications
------------------------------------------------------------------

Let's consider how services (components, programs, etc.) running within a cloud
infrastructure can authenticate each other. Specifically, let's assume:
* There are two programs, A and B. Program B opens a connection to A, and B
  wants assurance that it is really speaking with A (or vice versa).
* Assume that A and B can be identified by code hashes Ha and Hb.
* A and B are part of the same administrative domain, Dapp, which I'll represent
  as signing key Kd.
* When executed, A and B are configured with domain-specific
  information containing, e.g. Ha, Hb, and Kd.
* A and B may be running on the same cloud node or on different nodes within a
  single cloud. 
* The underlying cloud nodes and infrastructure are probably a different
  administrative domain, Dcloud, which I'll represent as signing key Kc.
* The cloud infrastructure implements Tao, or something like Tao, which provides
  to A and B various trusted local services, i.e. management of encryption or
  signing keys, sealed storage, measurement and attestation, etc.

We want to construct an authenticated channel between A and B. 

Authentication Across Cloud Nodes
---------------------------------

Suppose A and B are executing on different cloud nodes. Here are some approaches
we could take:

1. TLS + local asym. keys + local Tao attestation + offline TPM attestation.

This is what is currently used in the Tao implementation.
* Kd publishes an attestation describing what constitutes a "good platform".
  This includes, e.g. Kc and various other parameters.
* Kd publishes an attestation describing what constitutes a "good program", i.e.
  containing Ha and Hb.
* Each local cloud node platform i has a TPM, represented by key Ktpm_i, that
  serves as a local root of trust.
* Kc attests that Ktpm_i is held by a good platform, i.e. a platform with
  certain properties P_i. This step is done offline, e.g. during
  installation/configuration of the cloud node.
* Programs A and B generate asymmetric keys Ka and Kb. This might happen when
  A and B first execute or when they are installed and configured.
* Ktpm_i attests (through one or more levels of Tao) that Ka is held by
  program A and that A has been configured to run under domain Kd.
* B opens a TLS channel to A and the two authenticate using Ka and Kb and
  self-signed certificates.
* A then sends to B the attestations from Kc and from Ktpm_i.
* B does this:
  - Using Kd's attestation about platforms, B checks that Kc and Kc's
	attestation about Ktpm_i satisfies the definition for Ktpm_i to be a "good
	platform".
  - B extracts the domain key from Ktpm_i's attestation and checks that it
    matches the app domain key Kd that B itself was configured with.
  - Using Kd's attestation about programs, B extracts the hash from Ktpm_i's
	attestation and checks that it meets the domain's definition of "program A".
  - B extracts the key from Ktpm_i's attestation and checks that it matches the
    TLS key that was used during connection handshaking.

At this point, B knows that it is connected to program A.

Messages:
  C -> D : "I am key=Kc and I run various platforms"
  D -> ? : D1a = sign(kd, "key=Kc platforms with properties prop=P1 running Tao hash=Hta, are good")
  D -> ? : D1b = sign(kd, "key=Kc platforms with properties prop=P2 running Tao hash=Htb, are good")
  D -> ? : D2a = sign(kd, "On good platforms, prog=Ha(Kd) are good")
  D -> ? : D2b = sign(kd, "On good platforms, prog=Hb(Kd) are good")
  C -> M_1 -> A: C1 = sign(kc, "tpm=Ktpm_1 has properties prop=P1")
  C -> M_2 -> B: C2 = sign(kc, "tpm=Ktpm_2 has properties prop=P2")
  M_1    : run code that constitutes Tao and A(Kd)
  M_2    : run code that constitutes Tao and B(Kd)
  A      : generate Ka,ka
  B      : generate Kb,kb
  Ktpm_1 -> A : A1 = sign(ktpm_1, "Code with hash=Ht says key=Ka binds to id=Ha(Kd)")
  M_1 -> A    : C1
  Ktpm_2 -> B : B1 = sign(ktpm_2, "Code with hash=Ht says key=Kb binds to id=Hb(Kd)")
  M_1 -> B    : C2
  A <-> B     : Establish TLS channel with Ka and Kb and self-signed certs
  A -> B      : C1
  A -> B      : A1
  B : verify(Kd, D1a)              // B learns D's policy about platforms
    : verify(D1a.key, C1)          // B learns C's view of A's purported platform
    : verify C1.prop == D1a.prop   // A's purported platform is good for D
    : verify(C1.tpm, A1)           // B learns A's purported platform's view of A's code
    : verify A1.hash == D1a.hash   // B learns A's purported platform OS is good for D
	: verify(Kd, D2a)              // B learns D's policy about programs
	: verify A1.id == D2a.prog     // A's puported program is good for D
    : verify A1.key == TLS.peerkey // B learns peer is really as purported (*)
	: conclude my peer is A1.id
  A : similar...

  (*) Note - Any good program A would not leak ka to any bad program, and no
  good program would use ka even if it had access (e.g. Tao or TPM). And a good
  TPM would not generate A1 for a bad program. So when B sees combination of Ka
  in the TLS handshake, plus a matching A1, it knows peer is good.

Performance:
  Setup: 3 asymmetric signature generations
    * D signs 1 messages (or many) during configuration of domain
    * C signs 1 message per platform during installation/setup of platform(s)
  Program launch: 2 asym key generations, 2 asym signatures
    * A and B generate asymmetric keys
    * TPMs each sign 1 message per program (or more with Tao indirect key)
  Connection: 6 asym verifications, 2-party asym TLS with length-1 cert chains.
    * A and B each verify 1 message from D 
    * A and B each verify 1 message from C
    * A and B each verify 1 message from TPM
    * A and B do TLS

Assumptions:
  Unforgeable asymmeric key signatures
    (used for Kd platform attestation, Kd program attestation, Kc platform
	attestation, ...)
  [NO - An ideal hash function (used to compute program identity)]
  [NO - Ability to audit code]
  A suitable and well-known mechanism for associating short identifiers with OS
    (i.e. TPM+tboot PCR scheme)
  A suitable and well-known mechanism for associating short, unique identifiers with
    configured, executing programs.
    (used for Tao, e.g. an ideal hash function and a schema for code, args, env, etc.)
  Various non-interactive (i.e. offline) principals can keep long-term secrets
    (holders of Kd and Kc need to protect corresponding private half)
  Cloud provider key Kc is well-known
    (in practice - via web and dns/dnssec, social mechanisms, etc.)
  Cloud provider has a way to learn Ktpm_i and learn/eval platform properties
    (this is completely unspecified, probably has some physical aspects to take
	ownership and get Ktpm_i out of the TPM, i.e. TPM "physical presence", and
	may involve generating and keeping TPM "owner" passwords)
  TPMs and Tao work as advertised
    (tpm protects ktpm_i, only signs correct statements, etc.)
  Online/interactive programs can generate random asymmetric keys 
  Online/interactive programs can keep secrets in short term (or long-term?)
    (kc is secret from all but local TPM, local OS/Tao, C, and D)
  TLS works as advertised
    (B can authenticate peer as a public key)

2. TLS + local asym. keys + app certs (+ bootstrap via option 1)

Similar to option 1, but don't use self-signed TLS certificates. Instead, A and
B, after generating their local keys Ka and Kb, both contact some service that
represents the appplication domain. That service provides A and B with x509
certificates signed by Kd. At connection time, B just does normal TLS
authentication then checks that the peer certificate was provided by Kd and
contains the name "program A". This is close to typical https/TLS usage. How
does the service decide whether to issue a certificate for some key? Presumably
using option 1 between A (or B) and the service.

Messages:
  C -> D : C0 = "I am key=Kc and I run various platforms"
  C -> M_1 -> A: C1 = sign(kc, "tpm=Ktpm_1 has properties prop=P1")
  C -> M_2 -> B: C2 = sign(kc, "tpm=Ktpm_2 has properties prop=P2")
  M_1    : run code that constitutes Tao and A(Kd)
  M_2    : run code that constitutes Tao and B(Kd)
  A      : generate Ka,ka
  B      : generate Kb,kb
  Ktpm_1 -> A : A1 = sign(ktpm_1, "Code with hash=Ht says key=Ka binds to id=Ha(Kd)")
  M_1 -> A    : C1
  Ktpm_2 -> B : B1 = sign(ktpm_2, "Code with hash=Ht says key=Kb binds to id=Hb(Kd)")
  M_1 -> B    : C2
  A -> D      : Kc, C1, A1
  D : verify Kc is reasonable
    : verify(Kc, C1)
    : verify C1.prop are reasonable
	: verify(C1.tpm, A1)
	: verify A1.hash and A1.id are reasonable
  D -> A : D1a = sign_x509(kd, "key=Ka binds to commonname=Ha(Kd) for ca=Kd ...")
  B -> D      : Kc, C2, B1
  D : same as above
  D -> B : D1b = sign_x509(kd, "key=Kb binds to commonname=Hb(Kd) for ca=Kd ...")
  A <-> B     : Establish TLS channel with Ka and Kb and certs D1a, D1b
  B : verify TLS.peercert.ca == Kd && TLS.peercert.key == TLS.peerkey
	: conclude my peer is TLS.peercert.commonname
  A : similar...

Performance:
  Setup: 2 asymmetric signature generations, 2 asym verifications
    * C signs 1 message per platform during installation/setup of platform(s)
    * D verifies 2 messages from C
  Program launch: 2 asym key generations, 4 asym signatures, 2 asym
    verifications, and extra round-trip to D (twice).
    * A and B generate asymmetric keys
    * TPMs each sign 1 message per program (or more with Tao indirect key)
    * D verifies 2 messages from TPMs
    * D signs 2 messages
  Connection: 2-party asym TLS with length-2 cert chains.
    * A and B do TLS

Assumptions: Same as (1) except...
  Fewer non-interactive principals involved
  Interactive principal can keep long-term secrets
    (holder of Kd needs to be online but also protect the private half)
  x509 is secure

3. TLS + preshared sym. keys (+ bootstrap via option 1 or 2)

The shared app service generates a symmetric key Kab for the pair (A, B), and
provides A with (B, Kab) and B with (A, Kab). B connects to A TLS pre-shared key
using Kab. Since B was given (A, Kab) by the trusted shared service, B knows it
is connected to A (or to itself -- but that case is easy to rule out by just
exchanging names).  How does the service decide to give some program the key
Kab? Presumably using option 1 or 2 between A (or B) and the service, or using
any of a variety of (very interesting) proposals found in the literature for
identity-based crypto and symmetric key generation/distribution among a group of
nodes.

Performance:
  Setup: 2 asymmetric signature generations, 2 asym verifications
    * C signs 1 message per platform during installation/setup of platform(s)
    * D verifies 2 messages from C
  Program launch e.g.: 2 asym key generations, 2 asym signatures, 1-party TLS
	with length-1 cert chain (twice), extra round-trip to D (twice), 2 asym
	verifications, and 1 sym key generation (twice).
    * A and B generate asymmetric keys
    * TPMs each sign 1 message per program (or more with Tao indirect key)
    * D verifies 2 messages from TPMs
    * D generates 1 symmetric shared key
  Connection: 2-party sym TLS with psk and no cert chains.
    * A and B do TLS

Assumptions: Same as (2) except...
  Ability to generate short-term symmetric shared keys
  No x509


4. TLS + shared sym. keys (+ bootstrap via Tao)

Suppose the underlying cloud platform can generate a shared key for any pair of
programs. A and B both request a shared key, then use TLS pre-shared key to
establish a connection. There are lots of ways for the underlying platforms to
generate shared keys. One is for them to derive shared keys from a shared
master key, presumably installed at platform-configuration time.

Messages:
  ? -> M_* : km 
  M_1      : run code that constitutes Tao and A(...)
  M_2      : run code that constitutes Tao and B(...)
  A        : generate Ka,ka
  B        : generate Kb,kb
  A -> OSa : request key for Ha(...),Hb(...)
  OSa      : generate Kab
  OSa -> A : Kab
  B -> OSb : request key for Ha(...),Hb(...)
  OSb      : generate Kab
  OSb -> B : Kab
  A <-> B  : TLS with psk, hint Ha(...),Hb(...)

Performance:
  Setup: None.
  Program launch: 2 sym key generations.
  Connection: 2-party sym TLS with psk and no cert chains.

Assumptions: 
  Ability to generate short-term symmetric shared keys
  Interactive principal can keep long-term master secret
    (OS is online but also holds a master shared secret)
  Ability to safeguard shared master secret

5. Platform-provided authentication

Let the underlying platform perform authentication on behalf of A and B. A and B
would establish a TLS or TLS-like connection, but the authentication handshaking
would be done by the underlying platform. How do the underlying platforms
authenticate? Presumably using option 1, 2, 3, or 6.

6. TLS + cached sessions (+ bootstrap via option 1 or 2)

B connects to A using option 1 or 2. Both sides then cache their TLS sessions.
Subsequently, B connects to A using the cached TLS sessions.

Authentication Within a Cloud Node
----------------------------------

Suppose A and B are executing on the same cloud node.  Any of options 1 - 6
still work, of course. Option 4 becomes somewhat easier, because there is no
longer a need to share a master key across cloud platforms.  Option 5 becomes
easier because the underlying platform can trivially authenticate to itself. And
for options that rely on an shared app service for generating or attesting to
keys, if the shared app service is co-located on the same cloud node, then
bootstrapping can be done using option 4 or 5 or any of the other options.

Some other options become available when A and B execute on the same cloud node:

7. OS-secured channels

Within a single machine, TLS and cryptography aren't really necessary if we have
some other means of establishing authenticated channels. Linux pipes, for
example.

Authorization Without Authentication
------------------------------------

8. Macaroons / Cookies

In some scenarios, we care more about authorization than about authentication or
auditing. In Macaroons, for example, clients (which are essentially anonymous)
hold cookie-like secret tokens, and services grant any bearer of an appropriate
token access to resources. Applying this scheme to our intra-cloud scenario,
program A might hold a macaroon which it sends to B over a TLS connection, and B
makes decisions on the basis of that macaroon without every authenticating the
connection. However, there are issues:

Before program A sends a macaroon to B over some connection, A needs to
authenticate the connection. Presumably this is done with options 1-7 (in
typical end-user https sceanios, this would be option 2).

Program A needs to obtain the macaroon from B either directly or through some
intermediary. These connections need to be authenticated as well, presumably
using options 1-7 (in typical end-user https scenarios, this would be passwords
which function here like pre-shared keys).

Other Approaches or Existing Work?
----------------------------------

Are there other approaches and related work I should be looking at? I am not
finding a whole lot of literature on authentication (or authorization) *within*
cloud services.

* Check how Amazon EC2, or Google or Microsoft cloud providers authenticate.

Short Paper Outline
-------------------

* Problem introduction
* Survey of approaches 1-8
* Discussion of tradeoffs 
 - Setup costs (per-platform and/or per-program) vs. connection-time costs
 - Crypto tradeoffs: need for secure storage, performance of shared vs. symmetric crypto
 - Trust issues, size of tusted computing base, multi-tennant issues
* Quantitative Evaluation (?)
 - Can we look at patterns of connections in a cloud service so that we can make
   a more informed discussion of the costs?