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

In other documents, the details of how Tao can support the creation of
authenticated channels is left unspecified. Here are some ideas.

1. TLS PSK (Pre-Shared Keys) and OpenSSL
----------------------------------------

There are TLS suites defined that use symmetric keys for authentication, where
both endpoints have some shared key in common.

For example, openssl already supports:
  TLS_PSK_WITH_AES_128_CBC_SHA
Ideally, to get perfect forward secrecy and GCM we could use one of:
  TLS_DHE_PSK_WITH_AES_128_GCM_SHA256    = {0x00,0xAA};
  TLS_DHE_PSK_WITH_AES_256_GCM_SHA384    = {0x00,0xAB};
Sadly, these aren't supported in openssl yet.

I'm going to assume that support could be easily added for these, that we could
find a different tls package with support for these, or that the existing PSK
support in openssl is good enough.

2. OpenSSL invokes Tao?
-----------------------

In the symmetric key outline elsewhere, two hosted programs don't necessarily
share any keys in common. Instead, there is some common ancestor Tao that is
trusted by both endpoints and which was ultimately responsible for generating
the symmetric keys for each endpoint. That common ancestor Tao can do some of
the symmetric key operations (signing and/or verification) on behalf of one (or
both) endpoint programs in a way that allows the two programs to verify each
other's symmetric-key signatures without directly sharing a key in common. That
is to say, TLS-PSK isn't quite applicable. 

One approach is to hack openssl (or somehow install hooks, support for which I
don't believe currently exist in openssl) so it talks to Tao. The idea would be
that that one or both endpoint programs invokes the underlying Tao during TLS
key exchange to do the necessary symmetric key operations. To make this actually
secure, however, the Tao probably needs to be involved in generating material
for the TLS pre-master secrets, generating and/or verifying the conversation
hashes, etc.  The Tao API would be complex, very TLS-specific, and the security
properties of the resulting protocol would not be obvious. 

3. Design a TLS-PSK-like protocol?
----------------------------------

Borrowing heavily from TLS_DHE_PSK_WITH_AES_128_GCM_SHA256, we could implement a
protocol that uses Tao symmetric keys rather than pre-shared keys, does ECDHE
exchange, etc. My guess is that this would lead to a slightly less ugly Tao API
than simply hacking TLS, but the API would still be complex and not obviously
correct or credible. 

4. Pass file descriptors (and TLS state) over pipes?
----------------------------------------------------

The current linux_tao_service uses pipes to connect hosted programs and the Tao.
It is possible to pass an open file descriptor over a pipe.  Suppose two hosted
programs, A/path1 and A/path2, both deriving from some common Tao ancestor A, are
attempting to establish a TLS connection. After opening the network connection,
both programs could pass their open file descriptors to Tao A. Tao A could then
just call the regular openssl TLS-PSK initialization routines with its own
symmetric key, followed by a short exchange of path1 and path2 to provide each
endpoint with the full name of its peer. Tao A would then send the open file
descriptors back to the hosted programs. Unfortunately, Tao A would also need to
somehow transfer the TLS state to each hosted program as well. I do not know if
that is feasible or simple in OpenSSL. Moreover, it is a little silly to even be
doing TLS (ECDHE, PSK signatures, etc.) here, since the same program (Tao A)
fully controls both endpoints of the connection -- Tao A could just skip the
entire handshake, pick a premaster secret and be done with it.

5. Don't use TLS, rely on OS-secured channels.
----------------------------------------------

Within a single machine, TLS isn't actually necessary if we have some other
means of establishing secure channels. Linux pipes are one possibility. I think
this is a non-starter: it complicates support for Tao-based virtual machines,
for example.

6. Have Tao common ancestors perform shared key distribution?
-------------------------------------------------------------

(I like this idea best.)

Tao can serve as the trusted third party in a session key distribution protocol,
ala kerberos, 3PKD (http://seclab.cs.ucdavis.edu/papers/Rogaway/3pkd.pdf), etc.

As a simplified example, suppose hosted programs A/path1 and A/path2 would would
like to communicate, and both share a common ancestor Tao A. Then Tao A can
generate a shared symmetric key for the two programs roughly as follows.
  Programs A/path1 and A/path2 connect and exchange their full names.
  Each program now has both key names, A/path1 and A/path2.
  Each program invokes some common ancestor A, giving it the two paths.
  Tao A verifies that the invoking program is one of the two paths.
  Tao A computes the longest common prefix of the two paths.
  Tao A generates the key corresponding to A/prefix
  Tao A generates the key corresponding to A/prefix/merge
    where merge is computed based on the two suffixes of path1 and path2,
    e.g. Hash(join(sort([path1suffix, path2suffix]))).
  Tao A returns the computed key to both A/path1 and A/path2.
  The two hosted programs can then use TLS-PSK with that common key.
  After the TLS handshake, both programs know they must be talking to the
    opposite program, since Tao A gave the key only to A/path1 and A/path2.

Another way to think of this is that Tao is providing "group" shared symmetric
keys, similar to how Tao can provide per-program shared symmetric keys. In this
view, a hosted program can invoke the Tao with a list of group members; if the
calling program is among the group members, then the Tao will return a symmetric
key that corresponds to that group. A caveat is that the Tao so invoked must be
a common ancestor (hence trusted) by all members of the group. In the TLS
example above, the group is always 2 members: the invoking program plus the peer
to which it is trying to establish a secure channel.


7. Long-Lived vs. Short-Lived Keys
----------------------------------

We don't currently specify how keys can be revoked, rotated, etc. And although
we are careful to use DHE-based TLS because it has perfect forward secrecy, we
don't have any provisions for dealing with a compromised policy key, tao key,
program key, etc. Session key distribution protocols do a much better job of
this, distinguishing short-lived session keys, long-lived user keys (password),
and expiration/rotation of both kinds of keys.

Ideal:
* The (public) names used in policies, audit logs, etc. are long lived,
  even if corresponding keys aren't. 
* Most/all keys can be expired, revoked, and/or rotated.
* Exposure of a single key should have limited impact. Larger impact should
  correspond to better protected.


Current:
* Policy key pair (long lived)
* AIK for each machine (long lived)
* keys for each linux tao service (long lived)
* Policy mentions AIK_pub, Tao_pub directly
* Sealed data contains program hash (long lived)
* Keys for each hosted program ID, sealed by Tao (long lived)

Problem:
- If we have a whole structure of sym keys, if we change the root one, we lose
the ability to generate or verify any signatures. So put the version numbers in
the names, introduce the new key version, start using the new keys and new
names, and slowly expire the old key.

Proposal: 
* Most everything is done online, with the exception of a single long-lived
  policy root key pair:
    PolicyRoot
  And a globally-unique name for this key, 
    PolicyRootName = f(PolicyRoot_pub) // maybe just base64-encode, maybe hash for compactness, etc.
* PolicyRoot signs a series of policy keys and (possibly overlapping) validity
  periods:
    Policy_1, Policy_2, ...
    Policy_Epoch_1, Policy_Epoch_2, ...
	Policy_Cert_i = Sign(PolicyRoot_priv, i | Policy_i | Policy_Epoch_i | ...)
  We might use as a name for each key:
    PolicyRootName_i = f(Policy_i_pub)
  But then we can't predict the names without the keys already generated, and we
  can't quantify over the names since they aren't related and have no structure.
  An alternative public long-lived name for each policy key is:
    PolicyRootName_i = (PolicyRootName, i)
  Here we can quantify over i to get all the future and past names.
* Each machine generates a new M_AIK_j periodically, gets it certified
  M_AIKCert_j by the current Policy_i key with a validity period M_AIK_Epoch_j
  that is a subset of Policy_Epoch_i, generates a corresponding sym key M_Sym_j
  to use as a sym key generator, seals that under the same PCRs. As a name for
  this machine, we can use
    MName_j = f(M_AIK_j_pub)
  or better:
    MName_j = (PolicyRootName, i) | (m, j)
  where m is a per-machine name added to M_AIK_Cert_j.
* To implement TPM::GetSymKey(ver=v), use M_Sym_j to generate a key, and name it
    LinuxName = (PolicyRootName, i) | (m, j) | (OS, v)
* Each linux_tao_service periodically asks TPM for a new SymKey, then uses it
  to generate signing, sealing, and derivative keys.
* Each program does LinuxTao::GetKey(ver=k) and has the name:
    ProgName = (PolicyRootName, i) | (m, j) | (linux, v) | (prog, k)

Policies can be written with quantifications for the version numbers if desired.
Maybe even have creation times, epoch numbers, etc., encoded into version
numbers, so we can quantify over epoch so compromised older keys can't issue
currently-useful certificates. Also, expiration encoded into names of sym keys
lets us do intersection of expirations at all levels.

Q: Can tpm implement GetKey()? Use AIK to quote some string, e.g. "get my key",
hash the resulting signature and use the result as AES key material. (Or use a
TPM-based encryption key to encrypt the same string.) Nobody without AIK w/
proper pcrs  can know sig unless we tell them (otherwise they could forge AIK
signature). Nobody can guess hash without sig. Unfortunately TPM signatures are
not deterministic, nor are encryptions. When we generate an AIK, we could also
generate an AES key in software, seal it under the same PCRs as the AIK, then
use it for future key generation.

Q: If we are goint to use sym keys for sealing long-term data, that data needs
to be migrated upwards when we re-key. How?
  - for online services with short term or active data, just use sym key and
  re-encrypt as needed during rekey operations
  - for long term, idle data maybe use a service that seals to a policy? This is
  what seal should be about --> seal is resistant to rekeying.
  But how can evey tao provide this service... either need a long-term
  encryption key (maybe a separate one just for sealing? but why have 2 keys...)
  ... or reseal during key regen (requires resource accounting at tao)... or
  better use per-seal-op keys, escrowed somehow with long-term keys?
    this sounds like a network svc, not a primitive offered by each Tao
  cTPM suggests using a "cloud srk"

Global Audit Log (see http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.123.2142&rep=rep1&type=pdf)
* Goal is to simply provide a one-way audit log.
* Rekey on each log update (or on interval)
* Forward secrecy is actually backwards, in a sense, from what I am worried
  about with rekeying and expiration. If current key is exposed, attacker is
  prevented from messing with historical stuff. I'm more worried about if old
  keys are compromised, attacker can mess with current stuff.


8. Hierarchy: Tao vs CloudProxy
-------------------------------

Q: Is the root Tao on a machine part of only a single policy domain?
A: Likely not, esp. with evmm. Instead, evmm has policies for launching guest
OS+tao, which may each be part of a different cloud-policy domain.

Q: May a Tao have more than one host Tao?
Disucssion: Maybe these two should be the same:
  M1/EVMM(pcrs)/Guest(linux_i)
  CloudPolicy/Platform_j
i.e. the guest has two hosts, one local and one remote.
And maybe the set of policies this guest can enforce is a function of the hosts
it has. So M1 and M1/EVMM(pcrs) can't do cloud policies, but guest can b/c it is
part of cloud.
Conclusion: Tao and CloudProxy (CloudTao?) are different. Tao layers form a
subprin relationship based on hardware roots of trust, with full and unavoidable
trust between layers. CloudTao on the other hand have a trust relationship (esp.
when it comes to authentication), but it isn't full trust, and you can imagine
guest maintaining secrets that are safe even from the cloud policy. CloudTao
layers are not subprins, and they aren't necessarily even layered. Communication
certainly doesn't primarily happen up/down in cloud layers, it might happen
mostly sideways. 

Conclusion: Tao api should be concerned with things that relate to subprin
relationship, things only the parent can do. Attestation of child properties,
for example. Maybe secrets (sealing/unsealing) bound to specific
children/descendents. Maybe communication between children/descendents. But
cloud-related stuff should be done by CloudTao, which provides other services
and a different trust relationship. Cross-machine authentication is a CloudTao
service, not a Tao service.

Observation: StartHostedProgram (and kill) is not Tao generic. Every Tao has
children, but they are spawned in completely different ways. We have 3 Tao
layers (TPM, EVMM/KVM, Linux) and can imagine more (Chrome, Java, Python, etc.).
None of them have much similarity in the spawning or initialization of hosted
programs.

9. Next Steps
-------------

Start defining useful cloud services, see what we need from each layer?
 - useful seal/unseal
 - append-only log
 - key rotation service
 - authentication/kdf/pkd service

Logger
 - connect via network (i.e. TLS)
 - connect via local pipe?
 - client authentication (as src of log messages)
 - optional server authentication (confidentiality of log messages)

AuditLog
 - same as logger, but specialized for authorization decisions
 - configurable in what info it keeps about each decision, e.g. statistics only,
   or full evidence, etc.

Rendezvous
 - Given a fully qualified service name, get a network location
 - register services
 - policy for who can claim to be what

Key epoch manager or time service or something?
 - coordinates/facilitates key rotation, expiration, etc.

CloudStorage
 - seal/unseal abstraction
 - flexible, cross-machine policies
 - maybe versioning, timestamping, etc.
 - maybe monotonic counters

CloudCounter
 - monotonic counters
 - for cert serial number generation, boot counters, etc.
 - integer based, hash based, etc.
 - automatic logging?

HttpsCertificateManager
 - hands out x509 certificates
   - uses
   - policy to decide pcr/hash -> name:port mappings
 - https public interface with audit log of all certs it has ever given out

App ideas: FileProxy? Nah.

App ideas: TimeCapsule service
 - think: password protected zip, but with policy instead of password
 - web facing
 - client wants to encrypt data indefinitely (e.g. escrow)
 - client specifies data
 - client specifies policy, e.g.:
    - after date x, reveal key to anyone that asks
	- with consent of threshold parties
	- policies that depend on date, etc.
	- multiple passwords
 - audit log of open attemps and successes
 - try not to link data and key so svc is trusted a little bit less (e.g. it
   never sees the data)
 - Q: Can we effectively *freeze* the policy? Somehow guarantee disclosure?

App ideas: Witness/NotaryPublic
 - web-facing 
 - timestamps and signs anything you submit
 - public audit log?
 - linked for sequencing?

App ideas: WebWitness
 - think: proof that web page existed
 - like witness, but given a URL, fetches page, renders, takes
 screenshot, signs screenshot and full html

App idea: xkcd password generator

App ideas: Key Distribution Server (see tom)
App ideas: Key-value store

Q: How to do x509 for https?
TPM is expert on pcrs, pcrs are expert on proghash, etc.
Each layer attests the next.
So we get full tao (non-x509) chain of sigs:
  tpmkey -> pcrs -> proghash -> ...
To get x509, we have to use:
  httpsroot -> ... -> witness.com
But then we lose the tpmkey, pcrs, proghash, etc.
So who holds httpsroot priv key? CA-prog, for which there is a tao chain.

So run CA-prog, which gets a tao chain for tao key, generates httpsroot, seals
priv, attests to httpsroot using its own tao key, and we now have full tao chain
  tpmkey -> pcrs -> proghash -> taokey -> httpsroot
publish that tao chain. Anyone who cares can look at that tao
chain to be convinced that httpsroot is held by a legit CA-prog (configured with
reasonable name policy). 

CA-prog + naming policy then generates x509 cert for witnesskey @ witness.com:80
after having been convinced by witness-prog tao chain:
  tpmkey -> pcrs -> proghash -> taokey -> witnesskey

So user sees x509 chain:
  httpsroot -> witness.com
  And if they care, they can click on link to get tao chains
  tpmkey -> pcrs -> proghash -> taokey -> httpsroot
  tpmkey -> pcrs -> proghash -> taokey -> witnesskey

 
(1) Witness
 Goal: client connects to witness.com
    with https secure pubkey witness_pub
	     certified for witness.com:80,
		 details friendly name is http-witness
		 details full name prog_hash+os_hash+pcrs+tpm_key
		         (this program is trustworthy for being a witness)
		 expiration ...
		 by Google(Witness)TaoHttpsCertManager
		    certfied for CA
			details friendly name is tao-https-certifier
			details full name prog_hash+os_hash+pcrs+tpm_key
		            (this program is trustworthy on pcr<-->dns bindings)
		            (and also trustworthy on friendly name)
		            (and also trustworthy on hash/os/pcr/tpmkey)
			expiration ...
			by Google(Witness)PolicyMgr
		            (and also trustworthy on friendly name)
		            (and also trustworthy on hash/os/pcr/tpmkey)
				by Google(Witness)Tao
						(and also trustworthy on hash/os/pcr/tpmkey)
 - above is trouble...
 - GoogleTao HTTPS ca key, offline?
 - Generate Witness HTTPS ca cert, self signed?
 - Generate domain policy key
 - offline sign policy that says
	[machine and OS setup]
    - any of the following machines (tpm aik) is okay
	- any of the following os (evmm and/or linux hash) is okay
	- only the following progs can run
	[some named groups]
	- any of the following prog speak for <policy.httpcert>
	[https cert policy]
	- policy.httpcert can mint x509 certs under
 - Generate HttpsCertificateManager key, certify it offline with policy key,
   seal private under a policy that says:
 - depends on HttpsCertificateManager service