The custom attestation server generates attestations using a hardcoded cerificate chain and makes them available using a HTTP server. It expects callers to provide one or more of a public key, user data and nonce which are included in the attestation.
IMPORTANT: The attestations generated by this server are NOT real and NOT really secure. They are meant to be used during local development or a testing environment.
cargo build --releaseReproducible builds can be done using Nix. The monorepo provides a Nix flake which includes this project and can be used to trigger builds:
nix build -v .#<flavor>.attestation.server-custom-mock.<output>Supported flavors:
gnumusl
Supported outputs:
default, same ascompresseduncompressedcompressed, usingupxdocker,uncompressedbinary packaged into a docker tar
$ ./target/release/oyster-attestation-server-custom --help
http server for handling attestation document requests
Usage: oyster-attestation-server-custom [OPTIONS]
Options:
-i, --ip-addr <IP_ADDR> ip address of the server [default: 127.0.0.1:1350]
-h, --help Print help
-V, --version Print version
The attestation server exposes attestations through two endpoints which encode the attestation in one of two format - raw and hex. The raw format is a binary format with the raw bytes of the attestation. The hex format is the same attestation, simply hex encoded. Therefore, the raw format is about half the size of the other while the hex format is ASCII letters and numbers only.
Both endpoints accept query parameters which can be used to set the public key, user data and nonce in the attestation document.
/attestation/raw
public_key: Optional, hex encoded public key without the0xprefix that is included in thepublic_keyfield of the attestation after being decoded into raw bytesuser_data: Optional, hex encoded user data without the0xprefix that is included in theuser_datafield of the attestation after being decoded into raw bytesnonce: Optional, hex encoded nonce without the0xprefix that is included in thenoncefield of the attestation after being decoded into raw bytes
While all query parameters are optional, any useful attestation will likely include at least the public key to extend the chain of trust.
$ curl '<ip:port>/attestation/raw?public_key=<public_key>&user_data=<user_data>&nonce=<nonce>' -vs | xxd
* Trying <ip:port>...
* Connected to <ip> (<ip>) port <port> (#0)
> GET /attestation/raw?public_key=<public_key>&user_data=<user_data>&nonce=<nonce> HTTP/1.1
> Host: <ip:port>
> User-Agent: curl/7.81.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< content-type: application/octet-stream
< content-length: 4466
< date: Sat, 06 Apr 2024 07:28:41 GMT
<
{ [2682 bytes data]
* Connection #0 to host <ip> left intact
00000000: 8444 a101 3822 a059 1106 a969 6d6f 6475 .D..8".Y...imodu
00000010: 6c65 5f69 6478 2769 2d30 6631 6364 3737 le_idx'i-0f1cd77
00000020: 6433 3766 6438 6263 6339 2d65 6e63 3031 d37fd8bcc9-enc01
00000030: 3865 3761 6136 3165 3230 3430 6666 6664 8e7aa61e2040fffd
00000040: 6967 6573 7466 5348 4133 3834 6974 696d igestfSHA384itim
00000050: 6573 7461 6d70 1b00 0001 8eb2 4f18 9864 estamp......O..d
...
...
/attestation/hex
public_key: Optional, hex encoded public key without the0xprefix that is included in thepublic_keyfield of the attestation after being decoded into raw bytesuser_data: Optional, hex encoded user data without the0xprefix that is included in theuser_datafield of the attestation after being decoded into raw bytesnonce: Optional, hex encoded nonce without the0xprefix that is included in thenoncefield of the attestation after being decoded into raw bytes
While all query parameters are optional, any useful attestation will likely include at least the public key to extend the chain of trust.
$ curl '<ip:port>/attestation/hex?public_key=<public_key>&user_data=<user_data>&nonce=<nonce>' -vs | xxd
* Trying <ip:port>...
* Connected to <ip> (<ip>) port <port> (#0)
> GET /attestation/hex?public_key=<public_key>&user_data=<user_data>&nonce=<nonce> HTTP/1.1
> Host: <ip:port>
> User-Agent: curl/7.81.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< content-type: text/plain; charset=utf-8
< content-length: 8932
< date: Sat, 06 Apr 2024 08:22:00 GMT
<
8444a1013822a0591106a9696d6f64756c655f69647827692d3066316364...
...
The attestations include one root certificate in the cabundle field that is self-signed and one leaf certificate in the certificate field that is signed by the root certificate.
While verifying, the expected root public key is 0x6c79411ebaae7489a4e8355545c0346784b31df5d08cb1f7c0097836a82f67240f2a7201862880a1d09a0bb326637188fbbafab47a10abe3630fcf8c18d35d96532184985e582c0dce3dace8441f37b9cc9211dff935baae69e4872cc3494410. You can match it against the root certificate below.
The certificates were generated using certstrap and can be found in the certs directory.
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: ecdsa-with-SHA384
Issuer: CN = root
Validity
Not Before: Jan 1 00:00:00 1970 GMT
Not After : Dec 6 07:55:26 2054 GMT
Subject: CN = root
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit)
pub:
04:6c:79:41:1e:ba:ae:74:89:a4:e8:35:55:45:c0:
34:67:84:b3:1d:f5:d0:8c:b1:f7:c0:09:78:36:a8:
2f:67:24:0f:2a:72:01:86:28:80:a1:d0:9a:0b:b3:
26:63:71:88:fb:ba:fa:b4:7a:10:ab:e3:63:0f:cf:
8c:18:d3:5d:96:53:21:84:98:5e:58:2c:0d:ce:3d:
ac:e8:44:1f:37:b9:cc:92:11:df:f9:35:ba:ae:69:
e4:87:2c:c3:49:44:10
ASN1 OID: secp384r1
NIST CURVE: P-384
X509v3 extensions:
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
X509v3 Subject Key Identifier:
03:DA:F8:14:E8:2A:77:6C:55:70:65:15:1C:08:B7:0D:7E:17:FA:01
Signature Algorithm: ecdsa-with-SHA384
Signature Value:
30:64:02:30:34:d6:ba:1f:c4:56:88:51:0f:92:61:2b:db:7f:
b1:b0:22:88:72:e8:a7:84:85:ec:e2:47:1a:39:0e:01:85:ab:
23:5c:27:89:2d:4c:35:a9:52:dc:b3:e5:c6:41:da:bf:02:30:
22:b6:d4:c7:66:80:0b:7d:3f:9c:c0:12:9f:c0:8b:f6:87:f8:
68:7b:88:a1:07:ea:cb:ad:7a:7b:49:f6:be:1f:73:f8:01:dd:
69:f8:58:37:63:53:d6:0f:34:43:da:9d
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
99:35:f9:94:2d:28:5a:a3:08:28:ca:be:b6:17:80:6f
Signature Algorithm: ecdsa-with-SHA384
Issuer: CN = root
Validity
Not Before: Jan 1 00:00:00 1970 GMT
Not After : Dec 6 07:55:25 2054 GMT
Subject: CN = leaf
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit)
pub:
04:86:92:82:96:8b:06:cf:61:b9:c3:0c:3b:bf:a1:
76:72:5c:ae:06:34:e8:c0:52:53:6f:1a:ac:ff:52:
f3:70:30:87:f1:a8:24:6f:70:36:b1:bf:e2:63:79:
a3:50:43:4f:3b:40:90:90:bf:ef:6e:95:1c:d1:ce:
41:82:89:54:bf:4b:5b:0c:c6:26:6e:3c:08:63:f0:
15:38:42:72:d9:90:ff:4a:18:af:35:3f:88:45:00:
a4:ad:b3:7f:1c:c4:11
ASN1 OID: secp384r1
NIST CURVE: P-384
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment, Data Encipherment, Key Agreement
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Subject Key Identifier:
9A:F6:C1:7C:9A:E3:D8:07:B3:59:6B:0B:05:DB:7B:30:76:4A:E1:1B
X509v3 Authority Key Identifier:
03:DA:F8:14:E8:2A:77:6C:55:70:65:15:1C:08:B7:0D:7E:17:FA:01
Signature Algorithm: ecdsa-with-SHA384
Signature Value:
30:66:02:31:00:b1:ea:c6:ba:5d:62:07:e4:cf:c3:83:36:be:
2a:87:60:a4:15:4c:56:93:b2:46:89:ec:58:52:91:57:3f:ec:
da:b2:d9:cb:35:4d:e8:88:95:c2:5a:47:09:25:c8:38:d9:02:
31:00:f0:c0:ec:3a:44:07:ce:81:76:8c:07:d9:28:85:85:bc:
f8:4f:26:f5:57:55:5a:8b:e7:e8:ed:b4:82:6a:4e:d0:f2:58:
70:8b:42:50:a8:4c:b5:fa:b4:ff:72:14:09:8e
This project is licensed under the Apache License, Version 2.0. See LICENSE.txt.