End to End Message Authenticity in Cloud Native Systems

Why does e2e authenticity matter?

Classic Setup: Micro-Services with TLS and auth via Bearer

graph LR
    User-->|TLS|Gateway
    Gateway-->|mTLS|Server
    Server-->|mTLS|Gateway
    Gateway-->|TLS|User

Intrusion: Hacked Gateway
- Can modify the request
- Could log auth tokens
- Could replay requests with different body or token

Idea:
- Client can sign the content and headers with a symmstric/asynmetric key
- Server can verify the signature
Implementation: Basicly just an additional Signature Header and a Header that tells us what is included in the signature
```
HTTPS POST /test
Authorization: Bearer <token>
Signature-Input: "authorization" @body
Signature: ahsz7d9zahbsdoih
```
Problem: Key distribution
Real-World: AWS v4 Signature shares accesskey and secretkey out of band and signs header with accesskey (symmatric)
Transitive Trust

TODO: Steal image from slides

Basicly adds a nonce that we have to sign and the idp now knows that we really posess it

TODO: Steal image from Slides

Assigns meaning to the nonce and can reconstruct the nonce for a reverse check

The demo uses GitHub as a PKI (since all public keys get exposed via github). Pretty cool: They automated the demo via a go cli.

TODO: Link to demo code TODO: Steal image from Slides

SPIFFE is the de-facto standard for distributing identities to workloads
1. Workloads asks “Who am I”
2. Agent attests the workload
3. Agent provides OIDC or X.509 to Workloads

WIMSE RFC: Basicly DPoP/OpenPub
1. Workload get’s a private key
2. Issuer binds workload identity to the public key
3. Auth trusts SPIFFE, it can trust the key