Download to read offline
![Capabilities
• Unique scheme to describes rights
alias * = /.+/
namespace { [+,-][tag,/tag-regexp/]:[feature,/feature-
regexp/](options,/options-regexp/) }
//example
clevercloud { +*:*(*) -/.*prod/:*(*) +*:log(read, drain) }
cleverbench { +rust:metrics(*) }
// another block
clevercloud { -wordpress:log(drain) }](https://image.slidesharecdn.com/biscuit-apidays2018-181212171528/85/Remove-centralization-on-Authorization-API-Days-Paris-2018-announcement-for-biscuit-28-320.jpg)
![Signing tokens
Token 1: [block] sig1
Deriving a token for [block 2] with pubkey P2:
sig2 = Sign(k2, block 2)
S = sig1 + sig2
Token 2: [block 1][block 2] S](https://image.slidesharecdn.com/biscuit-apidays2018-181212171528/85/Remove-centralization-on-Authorization-API-Days-Paris-2018-announcement-for-biscuit-32-320.jpg)
Uploaded byQuentin Adam
Remove centralization on Authorization - API Days Paris 2018 (announcement for biscuit)
The presentation discusses the challenges of centralization in security and proposes a new authorization token system that supports delegation and attenuation across multiple trust circles. It critiques existing methods like Kerberos, OAuth, and JWT for their complexity and vulnerabilities, and introduces a novel approach using pairing-based cryptography for secure and efficient token management. Additionally, it outlines technical details and encourages further exploration and implementation in various programming environments.
More Related Content
Similar to Remove centralization on Authorization - API Days Paris 2018 (announcement for biscuit)
More from Quentin Adam
Remove centralization on Authorization - API Days Paris 2018 (announcement for biscuit)
- 1. Remove centralisation in Security QuentinADAM @waxzce & Geoffroy COUPRIE @gcouprie Clever Cloud 💡☁️ At API Days Paris 2018
- 2. Quentin ADAM @waxzce CEO @Clever Cloud Geoffroy COUPRIE @gcouprie Developer @ Clever Cloud
- 3.
- 4.
- 5. Git push It’s freeto try it out
- 6. Deploy & Application sustainability European Cloud& on premises
- 7.
- 8. Authorization need tobe distributed
- 9. Authentication = 🛂 Authorization= 🗝 Transport = 📜 Remember
- 10. Kerberos • Authorization +Transport • Ticket based • Centralized • Hard to distribute • Network intensive • Not embeddable in the browser
- 11. RADIUS • Authentication +Transport • Centralized • Hard to distribute • Network intensive • Not embeddable in the browser
- 12. SAML • Authorization &Authorization on SSO context • Based on HTTP and browsing • Complex
- 13. Cookie • HTTP only •Arbitrary data • Leading to mistake • Transport / storage • Tooling and options on the browsers is mature
- 14. More about cookies,by @hsablonniere FR : https://www.youtube.com/watch? v=KL9MR721c4w EN: https://www.youtube.com/watch? v=y6mwekHkgVQ
- 15. Oauth • Delegate Authentication& somehow Authorization • Implementation non consistent • Centralized • Token mess and easy to steal
- 16. JWT • Authorization token& transport agnostic • Can convoy identity
- 17. JWT • Heavy token •Complexity, leading to security issue • Data Staleness • No delegation nor attenuation
- 18.
- 19. Macaroons • Authorization token& transport agnostic • Can convoy identity
- 20. Macaroons • Based onshared secret • Security weakness • All validators need to be 100% trusted • Heavy • Caveat are not normalized = lot’s of business specific code
- 21. So, we arenot satisfied.
- 22. Avoid shared secret Andallow the use of the token for multiple trust circles
- 23. Allow Delegation andattenuation
- 24.
- 25.
- 26. New authorization token •Transport free • Fit • Defining capabilities • Delegation & Attenuation • Multiple trust circles ready • Based on fancy crypto Logo by @madgraphism
- 27. Based on HPACK •Using HPACK (HTTP/2 part) compression oriented format • K/V model to store data • Prebuild headers : • Identity • Issuer • Expiration • Rights
- 28. Capabilities • Unique schemeto describes rights alias * = /.+/ namespace { [+,-][tag,/tag-regexp/]:[feature,/feature- regexp/](options,/options-regexp/) } //example clevercloud { +*:*(*) -/.*prod/:*(*) +*:log(read, drain) } cleverbench { +rust:metrics(*) } // another block clevercloud { -wordpress:log(drain) }
- 29. Pairing based cryptography Pairinge: G1 x G2 -> Gt with G1 and G2 additive groups of prime order q, Gt multiplicative group of order q with a, b from Fq* finite field of order q with P from G1, Q from G2 e(aP, bQ) == e(P, Q)^(ab) More specifically: e(aP, Q) == e(P, aQ) == e(P,Q)^a e(P1 + P2, Q) == e(P1, Q) * e(P2, Q)
- 30. Signature choose k fromFq* as private key, g2 a generator of G2 public key P = k*g2 Signature S = k*H1(message) with H1 function to hash message to G1 Verifying: knowing message, P and S e(S, g2) == e( k*H1(message), g2) == e( H1(message), k*g2) == e( H1(message), P)
- 31. Signature aggregation With messagesm1 and m2, public keys P1 and P2 signatures S1 = Sign(k1, m1), S2 = Sign(k2, m2) the aggregated signature S = S1 + S2 Verifying: e(S, g2) == e(S1+S2, g2) == e(S1, g2)*e(S2, g2) == e(k1*H1(m1), g2) * e(k2*HA(m2), g2) == e(H1(m1), k1*g2) * e(H1(m2), k2*g2) == e(H1(m1), P1) * e(H1(m2), P2)
- 32. Signing tokens Token 1:[block] sig1 Deriving a token for [block 2] with pubkey P2: sig2 = Sign(k2, block 2) S = sig1 + sig2 Token 2: [block 1][block 2] S
- 33. Technical details Using curveBLS 12 381 Example of library this can be implemented with: - pairing crate: https://github.com/zkcrypto/pairing - mcl: https://github.com/herumi/mcl No formal proof or audit for now
- 34. Can be usedas SSO
- 35. Built in revocationmechanism
- 36. Current Performances can validate3 caveats in 1.7ms size: public key 128 hex characters signature 64 hex characters
- 37. Status • RFC inless than 20 days on Clever Cloud blog http://www.clever-cloud.com/blog • C++/rust implementation • Wasm ? • JVM / Java will be ongoing • Need audit, need comment
- 38. We are @gcouprie& @waxzce on twitter Give CLEVER-CLOUD.COM a try Free credits coupon : cc-api-18 Thx for listening
Editor's Notes
- #14 - cookies - easy to handle (random string) - linked to session data on the server -> state management - no delegation - easy to revoke (delete from state) - any service validating auth must access the shared state - browser support is great (cf tough cookies https://scotthelme.co.uk/tough-cookies/ ) - use with TLS
- #17 - JWT - JSON data + signature (and possibly encrypted data), lots of base64 - can embed user specific data, and we can detect if that data was modified - use public key, so the service validating the token is not necessarily the one that created it - the validating service should not need shared state, BUT - revocation will either need state management or short expiration dates (and probably state management just to be sure)) - quite large (can exceed the size of a cookie) - so they are often stored in localstorage, so they can be stolen via XSS - complex: many ways to sign or encrypt things, too many parameters, which leads to insecure implementations and insecure usage - no delegation (cannot create a valid signature from another one) - data staleness
- #18 - JWT - JSON data + signature (and possibly encrypted data), lots of base64 - can embed user specific data, and we can detect if that data was modified - use public key, so the service validating the token is not necessarily the one that created it - the validating service should not need shared state, BUT - revocation will either need state management or short expiration dates (and probably state management just to be sure)) - quite large (can exceed the size of a cookie) - so they are often stored in localstorage, so they can be stolen via XSS - complex: many ways to sign or encrypt things, too many parameters, which leads to insecure implementations and insecure usage - no delegation (cannot create a valid signature from another one) - data staleness
- #20 - macaroons - meant for delegated auth: if you have a macaroon, you can add claims to restrict it, and create a new valid macaroon from it (and we can’t get the old macaroon back from the new one) - uses HMAC - validation requires knowing the original secret of the macaroon, so the creation service must share that secret with the validation service - as usual, revocation will require shared state - typically stored as one long base64 string (binary format, not well specified) - has a concept of third party macaroon, so a macaroon can require authorization from another service we already share a key with
- #21 - macaroons - meant for delegated auth: if you have a macaroon, you can add claims to restrict it, and create a new valid macaroon from it (and we can’t get the old macaroon back from the new one) - uses HMAC - validation requires knowing the original secret of the macaroon, so the creation service must share that secret with the validation service - as usual, revocation will require shared state - typically stored as one long base64 string (binary format, not well specified) - has a concept of third party macaroon, so a macaroon can require authorization from another service we already share a key with