bloomberg / spire-tpm-plugin Goto Github PK

View Code? Open in Web Editor NEW

71.0 8.0 17.0 152 KB

Provides agent and server plugins for SPIRE to allow TPM 2-based node attestation.

License: Apache License 2.0

Makefile 0.89% Go 81.63% Shell 15.89% Dockerfile 1.59%

spiffe spire tpm2 tpm-attestation

spire-tpm-plugin's Introduction

SPIRE TPM Plugin

This repository contains agent and server plugins for SPIRE to allow TPM 2-based node attestation.

Demo

Here's a quick demo that shows how this plugin looks when run:

Quick Start

Before starting, create a running SPIRE deployment and add the following configuration to the agent and server:

Agent Configuration

NodeAttestor "tpm" {
	plugin_cmd = "/path/to/plugin_cmd"
	plugin_checksum = "sha256 of the plugin binary"
	plugin_data {
	}
}

Server Configuration

NodeAttestor "tpm" {
	plugin_cmd = "/path/to/plugin_cmd"
	plugin_checksum = "sha256 of the plugin binary"
	plugin_data {
		ca_path = "/opt/spire/.data/certs"
		hash_path = "/opt/spire/.data/hashes"
	}
}

key	type	required	description	default
ca_path	string		the path to the CA directory	/opt/spire/.data/certs
hash_path	string		the path to the Hash directory	/opt/spire/.data/hashes

Directory Configuration

For this plugin to work, either ca_path, hash_path, or both must be configured.

Certificate Directory

Contains the manufacturer CA cert that signed the TPM's EK certificate in PEM or DER format. Drop all manufacturer CA certs in the directory ca_path.

Note: not all TPM's have an EK certificate, if yours does not then use hash_path

Hash Directory

Contains empty files named after the EK public key hash. Use the get_tpm_pubhash command to print out the TPM's EK public key hash. Example:

agent  $ ./get_tpm_pubhash
1b5bbe2e96054f7bc34ebe7ba9a4a9eac5611c6879285ceff6094fa556af485c 

server $ mkdir -p /opt/spire/.data/hashes
server $ touch /opt/spire/.data/hashes/1b5bbe2e96054f7bc34ebe7ba9a4a9eac5611c6879285ceff6094fa556af485c

How it Works

The plugin uses TPM credential activation as the method of attestation. The plugin operates as follows:

Agent generates AK (attestation key) using TPM
Agent sends the AK attestation parameters and EK certificate or public key to the server
Server inspects EK certificate or public key
1. If hash_path exists, and the public key hash matches filename in hash_path, validation passes
2. If ca_path exists, and the EK certificate was signed by any chain in ca_path, validation passes
If validation passed, the server generates a credential activation challenge using
1. The EK public key
2. The AK attestation parameters
Server sends challenge to agent
Agent decrypts the challenge's secret
Agent sends back decrypted secret
Server verifies that the decrypted secret is the same it used to build the challenge
Server creates a SPIFFE ID in the form of spiffe://<trust_domain>/agent/tpm/<sha256sum_of_tpm_pubkey>
All done!

For info on how TPM attestation usually works and how this implementation differs, visit TPM.md.

Building

To build this plugin on Linux, run make build. Because of the dependency on go-attestation, you must have libtspi-dev installed.

Contributions

We ❤️ contributions.

Have you had a good experience with this project? Why not share some love and contribute code, or just let us know about any issues you had with it?

We welcome issue reports here; be sure to choose the proper issue template for your issue, so that we can be sure you're providing the necessary information.

Before sending a Pull Request, please make sure you read our Contribution Guidelines.

License

Please read the LICENSE file.

Code of Conduct

This project has adopted a Code of Conduct. If you have any concerns about the Code, or behavior which you have experienced in the project, please contact us at [email protected].

Security Vulnerability Reporting

If you believe you have identified a security vulnerability in this project, please send email to the project team at [email protected], detailing the suspected issue and any methods you've found to reproduce it.

Please do NOT open an issue in the GitHub repository, as we'd prefer to keep vulnerability reports private until we've had an opportunity to review and address them.

spire-tpm-plugin's People

Contributors

Stargazers

Watchers

Forkers

boxboat rodolfoams anderson-tomkelski sdminonne galo christophgraham whiteley mchorfa stjordanis venuvasuu21

spire-tpm-plugin's Issues

Abandoned project

It seems this one doesn't work with latest (v1.0+) SPIRE versions and according to repo activity - project is abandoned.

Use hex-encoded Public Key Hash instead of Base64 to avoid / char in SPIFFE-ID

SPIFFE-ID paths may be hierarchial, and using the base64 encoded Public Key Hash results in SVIDs that look like:

spiffe://domain.test/spire/agent/tpm/c1XbxrikL+sgdCw7hKFlmh2/y/QenHiIfLazBlsG/yQ=

This appears as if the path is hierarchial, since base64 includes / in it's character set

Additionally, #4 proposes storing authorized Public Key Hashses as an empty file on the filesystem. Since / is a directory separator on Linux, it cannot be represented in a file

Hex encoding for SHA256 representations is fairly standard practice, and would alleviate these issues

Add note about not supporting plugin SDK / newer Spire versions

Since SPIRE v1.1.0, SPIRE no longer supports plugins that don't use the plugin SDK. That includes the SPIRE TPM plugin in this repository. Unfortunately, newer SPIRE versions seem to produce confusing and unhelpful error messages (a piece of which is shown below) when one attempts to use a plugin that doesn't use the plugin SDK.

err="rpc error: code = Unimplemented desc = unknown service plugin.GRPCStdio" external=true plugin_name=tpm plugin_type=NodeAttestor subsystem_name=tpm.stdio site:github.com

Due to this, I feel it would be helpful to those seeking to use this plugin if at least one of the following were done:

Add a note to the README saying that the plugin does not use the plugin SDK and thus will not work with SPIRE versions v1.1.0 or later.
Add a note to the README mentioning the fork here, since that fork does use the plugin SDK.

Add Tests

Add tests to plugin.

Comments from #4 for reference:

Use the github.com/google/go-tpm-tools/simulator package.

Load an EK Cert into the simulator. This project does it with bash, just need to figure out what those commands would be in Go: https://github.com/mrcdb/tpm2_ek_cert_generator

Once tpm2-tools supports tpm2tools.StoreEKCert and tpm2tools.EKCertTemplate, the functionality from https://github.com/mrcdb/tpm2_ek_cert_generator could be ported to go, see #4 (comment)

node reimaging question

This is more of a question then an issue. The documentation is a bit unclear on this point. If the node is totally reinstalled, will it end up using the same AK or generate a new one? Would the SVID change in this case? If reimaged too frequently would the keys waste too much space in the TPM and cause attestation to fail?

Using Simulated TPM for node attestation

Not a feature request, but more of a question at this point.

Is your feature request related to a problem? Please describe.
I see references to the MS TPM 2.0 simulator in the pkg/ dir and ci/ dir.
I'm trying to see if I can hook up this plugin to the MS TPM 2.0 simulator running on my machine at the default port.

Describe the solution you'd like
Is there already a way to connect to the TPM simulator on TCP port? If so, a "help" guide would be great.

x509 Certificate type mismatch causing build to fail

Describe the bug

x509 Certificate type mismatch causing build to fail in Go 1.14.2

To Reproduce
Steps to reproduce the behavior:

Use Go 1.14.2
Run make
Error:

cmd/server/tpm_attestor/tpm_attestor.go:170:39: 
cannot use leaf (type *"crypto/x509".Certificate) 
as type 
*"github.com/google/certificate-transparency-go/x509".Certificate 
in argument to 
"github.com/bloomberg/spire-tpm-plugin/pkg/common".GetPubHash

Expected behavior

Builds properly

Screenshot

Environment (please complete the following information):

Ubuntu 20.04
Go 1.14.2
libtspi-dev for trousers

Trust based on EKPub

Describe the solution you'd like

Currently, EKCert chain must be validated and a node is allowed. This requires the server to have CA roots for each TPM manufacturer, and trusts all devices with a matching CA root.

I think it would also be beneficial to allow for a list of EKPub hashes to be considered. This would mean trust could be locked down to only certain devices that are on the EKPub whitelist

One solution would be an optional server configuration, such as:

ek_pub_hash_path  = "/opt/spire/.data/ek_pub_hashes"

Each file in that directory would be an empty file with a filename being a SHA-256 hash of an authorized EK Pub. If ek_pub_hash_path is supplied, a check for file exists on {ek_pub_hash_path}/{ek_pub_hash} would be performed and if found, considered valid.

Describe alternatives you've considered

Considered a datastore API for checking EK Pubs that reside in a remote datastore, but that would introduce additional complexity into this project, and could be handled out-of-band.

Additional context

The solution would be similar to the "Trust based on EKPub" described here: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/manage/component-updates/tpm-key-attestation#BKMK_DeploymentOverview

Could not verify cert: Unhandled Critical Extension

Describe the bug
TPM node attestation fails with error: "tpm: could not verify cert: x509: unhandled critical extension (2.5.29.17)"