Skip to content
Branch: master
Go to file
Code

Latest commit

gdbelvin committed 74d4671 Jul 3, 2020
* DB_NAME and DB_ENGINE flags

* Use noop quota

Spanner doesn't have a quota impl

* DB_ENGINE=cloud_spanner

Inject GOOGLE_APPLICATION_CREDENTIALS

* Cloudspanner flags

* Set master hold interval

* server -v=3

* Set sequencer batch size

* pin trillian docker

* go get github.com/google/trillian@v1.3.10

* remove mysql sidecar

* proper proto copy

Files

Permalink
Failed to load latest commit information.
Type
Name
Latest commit message
Commit time
cmd
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

README.md

Key Transparency

GoDoc Build Status Go Report Card codecov

Key Transparency Logo

Key Transparency provides a lookup service for generic records and a public, tamper-proof audit log of all record changes. While being publicly auditable, individual records are only revealed in response to queries for specific IDs.

Key Transparency can be used as a public key discovery service to authenticate users and provides a mechanism to keep the service accountable.

Key Transparency empowers account owners to reliably see what public keys have been associated with their account, and it can be used by senders to see how long an account has been active and stable before trusting it.

Key Transparency can add verifiable and user-friendly auditing to any scenario that involves authenticating users with public keys, including Universal Second Factor Security Keys and end-to-end encryption.

Project Status

Key Transparency is a work-in-progress with the following milestones under development.

Key Transparency Client

Setup

  1. Install Go 1.13.
  2. GO111MODULE=on go get github.com/google/keytransparency/cmd/keytransparency-client

Client operations

View a Directory's Public Keys

The Key Transparency server publishes a separate set of public keys for each directory that it hosts. By hosting multiple directories, a single domain can host directories for multiple apps or customers. A standardized pattern for discovering domains and directories is a TODO in issue #389.

Within a directory the server uses the following public keys to sign its responses:

  1. log.public_key signs the top-most Merkle tree root, covering the ordered list of map roots.
  2. map.public_key signs each snapshot of the key-value database in the form of a sparse Merkle tree.
  3. vrf.der signs outputs of the Verifiable Random Function which obscures the key values in the key-value database.

A directory's public keys can be retrieved over HTTPS/JSON with curl or over gRPC with grpcurl. The sandboxserver has been initialized with a domain named default.

$ curl -s https://sandbox.keytransparency.dev/v1/directories/default | json_pp
$ grpcurl -d '{"directory_id": "default"}' sandbox.keytransparency.dev:443 google.keytransparency.v1.KeyTransparency/GetDirectory
Show output
{
   "directory_id" : "default",
   "log" : {
      "hash_algorithm" : "SHA256",
      "hash_strategy" : "RFC6962_SHA256",
      "public_key" : {
         "der" : "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEXPi4Ut3cRY3OCXWvcSnE/sk6tbDEgBeZapfEy/BIKfsMbj3hPLG+WEjzh1IP2TDirc9GpQ+r9HVGR81KqRpbjw=="
      },
      "signature_algorithm" : "ECDSA",
      "tree_id" : "4565568921879890247",
      "tree_type" : "PREORDERED_LOG"
   },
   "map" : {
      "hash_algorithm" : "SHA256",
      "hash_strategy" : "CONIKS_SHA256",
      "public_key" : {
         "der" : "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEgX6ITeFrqLmclqH+3XVhbaEeJO37vy1dZYRFxpKScERdeeu3XRirJszc5KJgaZs0LdvJqOccfNc2gJfInLGIuA=="
      },
      "signature_algorithm" : "ECDSA",
      "tree_id" : "5601540825264769688",
      "tree_type" : "MAP"
   },
   "max_interval" : "60s",
   "min_interval" : "1s",
   "vrf" : {
      "der" : "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEvuqCkY9rM/jq/8hAoQn2PClvlNvVeV0MSUqzc67q6W+MzY/YZKmPLY5t/n/VUEqeSgwU+/sXgER3trsL6nZu+A=="
   }
}

Generate Update Signing Keys

Every update to a user record in key transparency must be signed by an authorized-key.

Update signatures are saved in the Merkle tree data structure, producing a record of who made each change to a user's account, allowing products to distinguish between changes signed by a user key, the provider's key, or a reset-provider's key.

Each account has an updatable policy that lists the current set of authorized public keys that are allowed to make updates to the user's record.

To create an initial set of update signing keys, run the authorized-keys create-keyset command. Keys will be saved in a .keyset file in the current working directory.

$ PASSWORD=[[YOUR-KEYSET-PASSWORD]]
$ keytransparency-client authorized-keys create-keyset --password=${PASSWORD}
Show output
$ PASSWORD=[[YOUR-KEYSET-PASSWORD]]
$ keytransparency-client authorized-keys create-keyset --password=${PASSWORD}
$ keytransparency-client authorized-keys list-keyset --password=${PASSWORD}
My Authorized Keys:
primary_key_id:17445529 key_info:<type_url:"type.googleapis.com/google.crypto.tink.EcdsaPrivateKey" status:ENABLED key_id:17445529 output_prefix_type:TINK >

Publish the public key

Any number of protocols may be used to prove to the server that a client owns a userID. The sandbox server supports a fake authentication string and OAuth.

Create or fetch the public key for your specific application.

 openssl genpkey -algorithm X25519 -out xkey.pem
 openssl pkey -in xkey.pem -pubout
 -----BEGIN PUBLIC KEY-----
 MCowBQYDK2VuAyEAtCAsIMDyVUUooA5yhgRefcEr7edVOmyNCUaN1LCYl3s=
 -----END PUBLIC KEY-----
keytransparency-client post user@domain.com \
--kt-url sandbox.keytransparency.dev:443 \
--fake-auth-userid user@domain.com \
--password=${PASSWORD} \
--verbose \
--logtostderr \
--data='MCowBQYDK2VuAyEAtCAsIMDyVUUooA5yhgRefcEr7edVOmyNCUaN1LCYl3s=' #Your public key in base64

Get and verify a public key

keytransparency-client get <email> --kt-url sandbox.keytransparency.dev:443 --verbose
✓ Commitment verified.
✓ VRF verified.
✓ Sparse tree proof verified.
✓ Signed Map Head signature verified.
CT ✓ STH signature verified.
CT ✓ Consistency proof verified.
CT   New trusted STH: 2016-09-12 15:31:19.547 -0700 PDT
CT ✓ SCT signature verified. Saving SCT for future inclusion proof verification.
✓ Signed Map Head CT inclusion proof verified.
keys:<key:"app1" value:"test" >

Verify key history

keytransparency-client history user@domain.com --kt-url sandbox.keytransparency.dev:443
Revision |Timestamp                    |Profile
4        |Mon Sep 12 22:23:54 UTC 2016 |keys:<key:"app1" value:"test" >

Checks

Running the server locally with Docker Compose

Prerequisites

  • GoLang
  • OpenSSL
  • Docker
    • Docker Engine 1.17.6+ docker version -f '{{.Server.APIVersion}}'
    • Docker Compose 1.11.0+ docker-compose --version
go get github.com/google/keytransparency/...
cd $(go env GOPATH)/src/github.com/google/keytransparency

# Generate Private Keys
./scripts/gen_monitor_keys.sh -f
pushd genfiles
go run "$(go env GOROOT)/src/crypto/tls/generate_cert.go" --host localhost,127.0.0.1,::
popd

# Build Docker Images
export TRAVIS_COMMIT=$(git rev-parse HEAD)
docker-compose build --parallel

# Run
docker-compose -f docker-compose.yml docker-compose.prod.yml up -d

# Create directory
docker run -t --network kt_attachable gcr.io/key-transparency/init:${TRAVIS_COMMIT} sequencer:8080 -- curl -k -X POST https://sequencer:8080/v1/directories -d'{"directory_id":"default","min_interval":"1s","max_interval":"60s"}'
  1. Watch it Run
  1. Integration test for Docker Compose

Development and Testing

Key Transparency and its Trillian backend use a MySQL database, which must be setup in order for the Key Transparency tests to work.

docker-compose up -d db will launch the database in the background.

Directory structure

The directory structure of Key Transparency is as follows:

Support

Acknowledgements

Key Transparency would not have been possible without a whole host of collaborators including researchers, interns, and open source contributors.

Key Transparency was inspired by CONIKS and Certificate Transparency.

Related

You can’t perform that action at this time.