Git Product home page Git Product logo

google / keytransparency Goto Github PK

View Code? Open in Web Editor NEW
1.6K 68.0 152.0 25.22 MB

A transparent and secure way to look up public keys.

Home Page: https://security.googleblog.com/2017/01/security-through-transparency.html

License: Apache License 2.0

Go 96.65% Shell 3.10% Dockerfile 0.25%
public-keys verifiable-data-structures block-chain key-management merkletree secure-by-default verifiable-random-function vrf coniks

keytransparency's Introduction

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 [email protected] \
--kt-url sandbox.keytransparency.dev:443 \
--fake-auth-userid [email protected] \
--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 [email protected] --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

Deploy the KeyTransparency service

  1. Run the deployment script

    # Download the latest version of keytransparency
    git clone https://github.com/google/keytransparency.git
    cd keytransparency
    
    # Run the deployment script for local environment
    ./scripts/deploy_local.sh deploy
  2. Check Docker's running containers

    docker container ls

    You should see 8 new running containers:

    • gcr.io/key-transparency/keytransparency-monitor
    • gcr.io/key-transparency/keytransparency-sequencer
    • gcr.io/trillian-opensource-ci/map_server
    • gcr.io/trillian-opensource-ci/log_signer
    • gcr.io/trillian-opensource-ci/log_server
    • gcr.io/key-transparency/keytransparency-server
    • gcr.io/trillian-opensource-ci/db_server
    • prom/prometheus
  3. Watch it Run

Terminate the KeyTransparency service

The script will remove all the containers and their networks.

# Run the script to undeploy
./scripts/deploy_local.sh undeploy

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

keytransparency's People

Contributors

adhintz avatar agl avatar alsophian avatar amarcedone avatar cesarghali avatar dazwilkin avatar dependabot-preview[bot] avatar dsnet avatar dvrkps avatar gdbelvin avatar gmichelo avatar heyitsanthony avatar jtoohill avatar juniway avatar kant avatar liamsi avatar libinjg avatar ludweeg avatar martin2112 avatar matiasinsaurralde avatar mhutchinson avatar pav-kv avatar phad avatar pphaneuf avatar prayagverma avatar ryanwwest avatar sckelemen avatar therealdrake avatar weikengchen avatar zyqsempai avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

keytransparency's Issues

HTTP: Implement HKP Server

For now only op=get requests are supported. Any other requests will return HTTP error code 501 ("Not Implemented").

This includes:

  • Implement op=get to read the key from the storage.
  • op=get unit testing.
  • Implement HTTP proxy server.
  • HTTP proxy unit testing.
  • Client testing, using test/api_proxy_test.py.

Create common Package

All common type definition and functionality that are used by multiple packages should go here.
This will also get rid of potential circular import errors.

Decide on and document the HTTP API

The status of the internal protos seems to be approaching agreement, but dmz and I only have a vague idea about the HTTP layer. We don't have specific requirements for how this should work, so agreeing will probably be not that hard, but it would still be nice to communicate this explicitly.

By "document" I mean something that people who don't speak goog.http annotations can understand well enough to implement. It does not need to be super formal or strict. Maybe just an explained example is sufficient.

go1.5 support: "internal" package paths

Currently building with go1.5 results in the following error:

package github.com/google/e2e-key-server/keyserver
    imports github.com/google/e2e-key-server/storage
    imports github.com/google/e2e-key-server/proto/internal: use of internal package not allowed

Merkle: Integrate Merkle Tree Implementation

This includes:

  • Update the tree whenever a new EntryStroage is added to the storage.

For now, all updates are added to the tree in the same epoch (epoch 1). This should be changed in the future to periodically advance epochs.

Create Javascript HTTP Client

This client will test the server as a whole by issuing HTTP requests to it. It is functionally similar to the deprecated api_proxy_test.py script.

HTTP: Integrate the New Proto

Integrate the new protobuf. This requires:

  • Changes in the RESTful API calls.
  • Changes in the API function calls.
  • Changes in the current storage implementation.
  • Modify all unit tests accordingly.
  • Modify v1 APIs test python script.

Support multiple entry_keys per Entry

This allows a user to distinguish whether their entry was reset by themselves or by the provider.
This distinction may also be hidden from the world if desired by not revealing which key the user vs. the provider owns

Server Configuration File

It might be better to a configuration file for the server. Please comment on this issue with anything that you think can go in this file and I will add it to the list below.

  • AUTHENTICATION_METHOD in rest/rest.go.
  • AUTHENTICATION_REALM in rest/rest.go.
  • CHANNEL_SIZE in storage/mem_store.go.

Refactoring Proxy and Key Server Returned Errors

This includes:

  • SignedEntryUpdate and Entry unmarshaling errors of v2.GetUser should be converted into Internal gRPC error instead of InvalidArgument.
  • Profile unmarshaling errors in v1.GetUser should be converted into Internal gRPC error instead of InvalidArgument.
  • All v2.GetUser errors should be gRPC errors.
  • All v1.HkpLookup errors should be gRPC errors.

Implement Monitor APIs

This includes:

  • Add proto-related material.
  • Implement GetMutations.
  • Implement GetMutationsStream.

Test monitoring APIs

Once implemented, the following API calls should be tested in the HTTP proxy server python testing script.

  • ListUserHistory.
  • ListSEH.
  • ListUpdate.
  • ListSteps.

Remove TreeNonce?

IIRC, the purpose of the per-merkle-tree nonce was to allow the provider to change the tree structure between epochs, aiming to prevent direct differential measurements of the churn of the userbase. As our tree structure is public anyway, rerandomizing it does not make sense. And the MerkleTree interface (and impl) would be simpler without that parameter.
Is there any reason that I am missing why we still need it?

Allow Command-Line Flags

This includes:

  • port in server.go.
  • AuthenticationRealm in rest/rest.go.
  • EntryStorageDBPath in common/common.go.

Document APIs

This includes:

  • README.md.
  • CONTRIBUTING.md.
  • API documentations.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.