Skip to content

Commit

Permalink
doc: Updated documentation
Browse files Browse the repository at this point in the history
Signed-off-by: Simon Ott <[email protected]>
  • Loading branch information
smo4201 committed Feb 21, 2024
1 parent 70f17c3 commit ecbf849
Show file tree
Hide file tree
Showing 4 changed files with 287 additions and 118 deletions.
101 changes: 42 additions & 59 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,10 +5,10 @@
[![Go Report Card](https://goreportcard.com/badge/github.com/Fraunhofer-AISEC/cmc)](https://goreportcard.com/report/github.com/Fraunhofer-AISEC/cmc)

The CMC repository provides tools and software to enable remote attestation of computing platforms,
as well as remote attested TLS channels between those platforms. Currently, the CMC repository
supports Trusted Platform Module (TPM) attestation, as well as AMD SEV-SNP attestation. The goal
is to make attestation easy for verifiers without prior knowledge of the software stack, based
on a set of trusted CAs and signed metadata describing the software stack.
as well as remote attested TLS and HTTPS channels between those platforms. Currently, the CMC
repository supports Trusted Platform Module (TPM) attestation, as well as AMD SEV-SNP attestation.
The goal is to make attestation easy for verifiers without prior knowledge of the software stack,
based on a set of trusted CAs and signed metadata describing the software stack.

*A detailed description of the architecture can be found in our*
*[paper](https://dl.acm.org/doi/pdf/10.1145/3600160.3600171) and in the*
Expand All @@ -21,13 +21,15 @@ on a set of trusted CAs and signed metadata describing the software stack.
- For AMD SEV-SNP an SNP-capable AMD server
- Building the *cmcd* requires *go* (https://golang.org/doc/install)

## Quick Demo Setup
## Quick Start

The CMC repository contains a complete local example setup including a demo CA and all required
configurations and metadata. It was tested on Ubuntu 22.04 LTS.
The CMC repository contains a complete local TPM-based example setup including a demo CA and all
required configurations and metadata. It was tested on Ubuntu 22.04 LTS.

> :warning: **Note:** You should run this only for testing on a development machine, or inside
> a Virtual Machine (VM). The software directly interacts with the hardware (TPM or AMD SP).
> a Virtual Machine (VM). The software directly interacts with the TPM
### Setup and Build

Clone the repository:
```sh
Expand All @@ -45,15 +47,11 @@ For the JSON example configuration folders to work without modifications, choose
the folder `cmc-data` located in the same root folder the `cmc` repository resides in.
Export this root folder as `$CMC_ROOT`.

*For an alternative demo setup with a more complex PKI and policies based on the requirements of*
*the International Data Spaces (IDS), see [IDS Example Setup](./doc/ids-example-setup.md)*

*For instructions on creating and signing the metadata with an arbitrary PKI yourself,*
*see [Manual Setup](./doc/manual-setup.md)*
### Run

## Run

### Generate and Verify Attestation Reports
The tools can generate and verify attestation reports, establish attested TLS connections and
establish attested HTTPS connections. For detailed instructions refer to
[Manual Setup](./doc/manual-setup.md)

```sh
# Start the EST server that supplies the certificates and metadata for the cmcd
Expand All @@ -62,63 +60,48 @@ Export this root folder as `$CMC_ROOT`.
# Build and run the cmcd
./cmcd -config $CMC_ROOT/cmc-data/cmcd-conf.json

# Run the testtool to retrieve an attestation report (stored in current folder unless otherwise specified)
./testtool -mode generate

# Run the testtool to verify the attestation report (stored in current folder unless otherwise specified)
./testtool -mode verify -ca $CMC_ROOT/cmc-data/pki/ca.pem
```

Note that the JSON configuration files in the example setup contain relative paths and the
above commands are meant to be run from within the respective source directories inside the
`cmc` repository.

### Establish Attested TLS Connections

Instead of using the `testtool` to simply generate and verify attestation reports, it can also
be used to establish attested TLS connections:

```sh
# Run an attested TLS server
./testtool -mode listen -addr 0.0.0.0:4443 -ca $CMC_ROOT/cmc-data/pki/ca.pem -mtls
./testtool -config $CMC_ROOT/cmc-data/testtool-conf.json -mode listen

# Run an attested TLS client estblishing a mutually attested TLS connection to the server
./testtool -mode dial -addr localhost:4443 -ca $CMC_ROOT/cmc-data/pki/ca.pem -mtls
```

### Establish Attested HTTPS Connection

The `testtool` can also perform user-specified attested HTTPS requests and act as an attested HTTPS demo server, respectively.

```sh
# Run two attested HTTPS servers
./testtool -config $CMC_ROOT/testtool-config.json -addr 0.0.0.0:8081 -mode serve
./testtool -config $CMC_ROOT/testtool-config.json -addr 0.0.0.0:8082 -mode serve

# Perform multiple user-specified attested HTTPS requests to both servers. Each connection is attested, while multiple requests to the same server use the established attested TLS connections
./testtool \
-config ../../cmc-data/testtool-lib-config.json \
-addr https://localhost:8081/post,https://localhost:8082/post \
-mode request \
-method POST \
-data "hello from attested HTTPS client" \
-header "Content-Type: text/plain"
./testtool -config $CMC_ROOT/cmc-data/testtool-conf.json -mode dial
```


**Note**: The *cmcd* TPM provisioning process includes the verification of the TPM's EK certificate
chain. In the example setup, this verification is turned off, as the database might not contain
the certificate chain for the TPM of the machine the *cmcd* is running on. Instead, simply a
warning is printed. The intermediate and root CA for this chain can be downloaded from the TPM
vendor. The certificates can then be added in to the ```cmc/example-setup/tpm-ek-certs.db```
database. The ```verifyEkCert``` parameter in the *estserver* config can then be set to true.
vendor. The certificates can then be added in to the `cmc/example-setup/tpm-ek-certs.db`
database. The `verifyEkCert` parameter in the *estserver* config can then be set to true.

## Further Documentation

## Configuration
### Architecture

An overview of the architecture is given in [Architecture](./doc/Architecture.md).

### Configuration

The tools can be configured via JSON configuration files and commandline flags. For an explanation,
each binary can be run with the `-help` flag. All configuration options are explained in the
[Configuration Documentation](./doc/configuration.md).

## Build
#### Detailed Setup

For instructions on creating and signing the metadata with an arbitrary PKI yourself,
see [Manual Setup](./doc/manual-setup.md)

### Build

See [Build Documentation](./doc/build.md)

### Integration

Usually, the attested TLS or HTTPS libraries are used within own projects to provide attestation
for TLS or HTTPS connections, as described in [Integration](./doc/integration.md)

### Additional Demo Setups

For an alternative demo setup with a more complex PKI and policies based on the requirements of
the International Data Spaces (IDS), see [IDS Example Setup](./doc/ids-example-setup.md)

18 changes: 13 additions & 5 deletions doc/Architecture.md
Original file line number Diff line number Diff line change
Expand Up @@ -80,10 +80,18 @@ __attestedtls:__
The *attestedtls* package provides an exemplary protocol which shows how a connection between two
parties can be performed using remote attestation. After a tls connection is established, additional
steps are performed to obtain and verify the attestation reports from the respective communication
partner. Only then is the connection provided to the server / client.
partner. Only then is the connection provided to the server / client. For an example on how to
integrate the library into own applications, the *testtool* with its modes *listen* and
*dial* can serve as an exemplary application.

__attestedhttp:__
The *attestedhttp packages utilizes **attestedtls** to provide HTTPS client and server capabilities
to applications. For an example on how to integrate the library into own applications, the
*testtool* with its modes *listen* and *dial* can serve as an exemplary application.

__testtool:__
The *testtool* can generate and verify attestation reports and establish attested TLS connections.
To estblish attestation TLS connections, the testtool makes use of the attested TLS package and thus
services provided by the cmcd to create an attested TLS connection. The client can be configured to
use one-sided or mutual attestation.
The *testtool* can generate and verify attestation reports and establish attested TLS as well as
attested HTTPS connections. For the latter, it makes use of the *attestedtls* and
*attestedhttp* packages. The testtool can act as a standalone application, i.e., integrate
all *cmc* functionality via their go API, or as a tool that interacts with the
*cmcd* via a gRPC, CoAP or socket API for performing remote attestation.
107 changes: 107 additions & 0 deletions doc/integration.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,107 @@
# Integration

To integrate attestation into own projects, run the *cmcd* on your system and replace the
go standard library `crypto/tls` or `net/http` package with the `cmc/attestedtls` or
`cmc/attestedhttp` package respectively. The API was kept as close as possible to the
original API, so that only some additional config options must be provided and many
data types, such as `net.Conn` (https://pkg.go.dev/net#Conn) can still be used.

In the following examples, error handling was omitted for simplicity. For the configurations,
see [configuration](./configuration.md) or look at the *testtool* code.

## Attested TLS

### Client

```go
// Import the attested TLS package
import atls "github.com/Fraunhofer-AISEC/cmc/attestedtls"

// Create CMC configuration (see configuration documentation)
conf := &CmcConfig{
// ...
}

// Establish attested TLS client connection
conn, _ := atls.Dial("tcp", "localhost:4443", tlsConf, atls.WithCmcConfig(conf))
defer conn.Close()

// Send data over the attested TLS connection
_, _ = conn.Write([]byte("Hello, World"))
```

### Server

```go
// Import the attested TLS package
import atls "github.com/Fraunhofer-AISEC/cmc/attestedtls"

// Create server TLS configuration
tlsConf := &tls.Config{
Certificates: []tls.Certificate{cert},
ClientAuth: clientAuth,
ClientCAs: roots,
}

// Create CMC configuration (see configuration documentation)
conf := &CmcConfig{
// ...
}

// Create an attested TLS listener
ln, _ := atls.Listen("tcp", "localhost:4443", tlsConf, atls.WithCmcConfig(conf))
defer ln.Close()

for {
// Accept connection and perform remote attestation
conn, _ := ln.Accept()

// Handle established connections
go handle(conn)
}
```

## Attested HTTP

### Client

```go
// Import the attested HTTPS package
import ahttp "github.com/Fraunhofer-AISEC/cmc/attestedhttp"

// Create attested HTTPS transport
transport := &ahttp.Transport{
IdleConnTimeout: 60 * time.Second,
TLSClientConfig: tlsConfig,
// Additional CMC configuration (see configuration documentation)
}

// Create attested HTTP client
client := &ahttp.Client{Transport: transport}

// Perform attested HTTPS GET request
resp, _ := client.Do("https://localhost:80/hello")
```

### Server

```go
// Import the attested HTTPS package
import ahttp "github.com/Fraunhofer-AISEC/cmc/attestedhttp"

// Create attested HTTP server
server := &ahttp.Server{
Server: &http.Server{
Addr: addr,
TLSConfig: tlsConfig,
},
// Additional CMC configuration (see configuration documentation)
}

// Use the golang net/http module functions to configure the server as usual
http.HandleFunc("/hello", handleRequest)

// Call the attested ListenAndServe method from the attested HTTP server
// to run the server
_ = server.ListenAndServe()
```
Loading

0 comments on commit ecbf849

Please sign in to comment.