10B/ ZKP’s & API Access

Securing API Access with ZKS

Session Convener: Seth Back

Notes-taker(s): Steve Venema

Tags / links to resources / technology discussed, related to this session:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

20 attendees

API Access Threat model

• Tampering with data in transit
• Replay f requests
• Unauthorized access to data
• Exploiting implicit trust
  • (external -> internal / internal -> internal)

API tokens

• Pros
  • Single token
  • No special computation
• Cons
  • Relies on transport security
  • No request integrity

Public / Secret Token (e.g., AWS token)

• Prosure over specific data
• Without exposing that signature
• In a format that can be publicly verified
  • Secret is actually a secret
  • Request integrity
• Cons
  • Arbitrary connection between tokens
  • Implicit trust / over provisioning access

What do we mean by ZKP in this context (PS Signatures)

• Prove knowledge of a signature

Fixed!

• Sig…

Implementation: Oberon

• Https://github.com/mikelodder7/oberon
• Rust & Go
• Flexible (use case agnostic)

Trinsic’s use

• Login generates “token” tied to the account
• Blinded before returned (2FA / no reliance on transport security)
• Nonce includes timestamp and request hash
• Validation at service level using public key

Ex:

• Oberon ver=1, proof=asdfasdf, data=afafasd, nonce=asdfasdfadf

Q: You mentioned macaroons; can you go into more detail?

A: whitepaper, a way to use hashes on signatures to attenuate authority

Do a ZKP on the macaroon – seen this used

Q: Combining API keys, access tokens, OAuth2 tokens

Nonce is different each time. Can …

Biggest value: Never have the API token pass over the wire

C: RFC8749Http structured headers – encouraging use of this in the future

Another version of Oberon coming out

Q: What formats supported

A: You are generating a ZKP of the hash of *any* data