# NEC-01: AWS Nitro Enclave Attestations Nostr-focused services deployed in the AWS Nitro Enclave might wish to use a particular Nostr key to interact with clients. To assure clients that service's Nostr `pubkey` is controlled by a particular code build, the service may produce an `attestation` Nostr event that includes a signature by AWS, the subject `pubkey` and the hashes of the code (*PCR values*). To achieve that, the service [requests attestation](https://github.com/aws/aws-nitro-enclaves-nsm-api/blob/main/docs/attestation_process.md#22-attestation-document-specification) from AWS VM and supplies the subject `pubkey`. The result is a binary blob in CBOR format that includes the enclave image's [PCR values](https://docs.aws.amazon.com/enclaves/latest/user/set-up-attestation.html#where) and the provided `pubkey`. According to the [spec](https://github.com/aws/aws-nitro-enclaves-nsm-api/blob/main/docs/attestation_process.md): > it is signed by AWS Nitro Attestation PKI, which includes a root certificate for the commercial AWS partitions that can be found [here](https://aws-nitro-enclaves.amazonaws.com/AWS_NitroEnclaves_Root-G1.zip) (SHA256 8cf60e2b2efca96c6a9e71e851d00c1b6991cc09eadbe64a6a1d1b1eb9faff7c) FIXME: need an example attestation blob and a link to parser utility. ## TEE Attestation Event After AWS produces an attestation document mentioning the Nostr `pubkey`, the service may produce a `TEE Attestation` Nostr event signed by the corresponding Nostr key. It is a `kind:23793` event with attestation included in `content` field in `base64` encoding. The `expiration` tag SHOULD be set to the timestamp of attestation expiry (commonly three hours). The `t` tag should signal `prod` or `dev` (default `dev`). ```js { "id": , "created_at": , "pubkey": , "kind": 23793, "content": , "tags": [ ["-"], // not for publishing ["t", <"prod" or "dev">], ["expiration", ] ] } ``` This event is not intended for publishing on relays, but SHOULD instead be included as `tee_root` tag in other Nostr events as a proof that `pubkey` is controlled by a particular enclave (or at least *was controlled* while the attestation was valid), example: ```js { "id": , "created_at": , "pubkey": , "kind": 1, "content": "Post from the enclave", "tags": [ ["tee_root", "\{\"id\": ,\"created_at\": ,\"pubkey\": ,\"kind\": 23793,\"content\": ,\"tags\": \[\[\"-\"\],\[\"t\",\"prod\"\],\[\"expiration\", \]\]\}"], ] } ``` ## Parsing and Validation To parse and validate the `kind:23793` event, clients SHOULD follow the [attestation spec](https://github.com/aws/aws-nitro-enclaves-nsm-api/blob/main/docs/attestation_process.md), and SHOULD verify that: - `public_key` field of the attestation blob matches the `pubkey` of the verified `kind:23793` event - `PCR values` of the attestation document match the expected values (either statically hard-coded or dynamically discovered) - `t` tag matches client's expectations (most clients should only use `prod` services) - `expiration` tag doesn't exceed the expiration of `attestation` certificate **IMPORTANT:** Without validating against a "trustworthy" set of `PCR values` (PCR 0, 1 and 2), the enclave attestation alone provides no additional safety guarantees, as clients can't know whether the enclaved code is safe or not. **NOTE**: All PCR values of **all zeroes** (except PCR4) signal that the service is launched in **debug** mode with console attached, clients should **never** use such services. ## Resources: - Reference implementation in TypeScript (*parseValidateAttestation*): [nostr-enclaves](https://github.com/nostrband/nostr-enclaves). - Implementation [guide by AWS](https://aws.amazon.com/blogs/compute/validating-attestation-documents-produced-by-aws-nitro-enclaves/). - NodeJS wrapper library to request attestations: [aws-nitro-enclaves-nsm-node](https://github.com/wei-rong-1/aws-nitro-enclaves-nsm-node/)