Upgrade to Pro — share decks privately, control downloads, hide ads and more …

No Way JOSE: Lessons for authors and implemente...

No Way JOSE: Lessons for authors and implementers of open standards

Protocol and data format specifications can be ambiguous, insecure or have other problems. Programmers and users bear the brunt of these issues. Using JOSE as a case study, I’ll discuss mistakes for standards authors to avoid, and demonstrate programming techniques for mitigating some kinds of problems.

JOSE (JSON Object Signing and Encryption) is a set of IETF standards for JSON-based cryptographic objects. You might know it as JWT or JWS. It is used in OpenID Connect, ACME, and other protocols. JOSE emerged a few years ago and has been causing headaches for the presenter ever since.

Using JOSE as a case study, this presentation looks at mistakes to avoid when specifying a data format or cryptographic protocol. We’ll also explore programming techniques for mitigating some kinds of problems in specifications. In particular, we will cover:

- the flawed rationale for the JOSE working group
- why JSON is a poor wire format for cryptographic objects
- cryptography issues in the JOSE specifications
- ambiguities and interoperability problems in the specifications
- common vulnerabilities in JOSE libraries
- how library authors can encourage or enforce safe use
- advice for standards authors or working groups

Each topic will culminate in one simple, actionable takeaway.

Programming principles and techniques will be demonstrated using Haskell and its jose library, which is maintained by the presenter.

Fraser Tweedale

July 03, 2018
Tweet

More Decks by Fraser Tweedale

Other Decks in Programming

Transcript

  1. No way, JOSE! Lessons for authors and implementers of open

    standards Fraser Tweedale @hackuador July 3, 2018
  2. JOSE JSON Object Signing and Encryption IETF WG formed 2011,

    RFCs 2015 used in OpenID Connect, ACME
  3. JOSE & me I wrote a JOSE library for Haskell

    I participated in IETF discussions JOSE has lots of problems (sorry. . . )
  4. JOSE—rationale With the increased usage of JSON in protocols in

    the IETF and elsewhere, there is now a desire to offer security services, which use encryption, digital signatures, message authentication codes (MACs) algorithms, that carry their data in JSON format.1 1https://tools.ietf.org/wg/jose/charters
  5. JOSE—rationale Many current applications thus have much more robust support

    for processing objects in these text-based formats than ASN.1 objects; indeed, many lack the ability to process ASN.1 objects at all. To simplify the addition of object-based security features to these applications, the working group has been chartered to develop a secure object format based on JSON.2 2https://tools.ietf.org/html/rfc7165
  6. JOSE—assumptions ASN.1 libraries don’t exist It’s better to define new

    standard than write a library JSON is suitable for security/cryptographic objects ASN.1 is bad
  7. JOSE—irony 4.7. "x5c" (X.509 Certificate Chain) Parameter The "x5c" (X.509

    certificate chain) parameter contains a chain of one or more PKIX certificates [RFC5280]. The certificate chain is represented as a JSON array of certificate value strings. Each string in the array is a base64-encoded (Section 4 of [RFC4648] -- not base64url-encoded) DER [ITU.X690.1994] PKIX certificate value.
  8. {" signature ":" M3oVLXrbeFRT9Ef9d3WzR -D7dGtI eYoPBYmiCdtYqus "," protected ":" eyJhbGciOiJI

    UzI1NiIsImtpZCI6ImthcmF0ZSJ9 "," payload ":"e yJzdWJqZWN0IjoiZnJhc2VAZnJhc2UuaWQuYXUiLCJ pc3MiOiJocy1qb3NlIiwiYXVkIjpbImFsaWNlIiwiY m9iIl19Cg "}
  9. JSON—objects names within an object SHOULD be unique—RFC 8259 Is

    a JSON object a map? What kind of map? How should duplicate keys be treated?
  10. { "payload":"<payload contents>", "signatures":[ {"protected":"<integrity-protected header 1 contents>", "header":<non-integrity-protected header

    1 contents>, "signature":"<signature 1 contents>"}, ... {"protected":"<integrity-protected header N contents>", "header":<non-integrity-protected header N contents>, "signature":"<signature N contents>"}] }
  11. hs-jose—dealing with ambiguity data List a = Nil | a

    : (List a) data Identity a = Identity a
  12. hs-jose—dealing with ambiguity data JWS t = JWS ByteString (t

    Signature) type GeneralJWS = JWS List Protection type FlattenedJWS = JWS Identity Protection
  13. Dealing with ambiguity—abstraction abstract over ambiguities let the user decide

    what they want provide simple API for the common use cases
  14. verifyJWSWithPayload :: ( MonadError Error m , VerificationKeyStore m payload

    k , Foldable t ) => ValidationSettings -> (ByteString -> m payload) -- ^ decoder -> k -- ^ key store -> JWS t -> m payload
  15. Static type systems—benefits abstraction avoid type confusion attacks readability &

    maintainability enable advanced techniques for security3,4,5 3Two Can Keep a Secret, If One of Them Uses Haskell 4FaCT: A Flexible, Constant-Time Programming Language 5HOWTO: Static access control using phantom types
  16. Advice for standards authors avoid ambiguity & special cases exclude

    esoteric use cases get cryptographers to review write multiple implementations
  17. Recap write libraries, not standards don’t automatically reach for JSON

    don’t cut corners with crypto special cases belong in libraries abstract over ambiguities use statically typed languages write multiple implementations
  18. Questions? Except where otherwise noted this work is licensed under

    http://creativecommons.org/licenses/by/4.0/ https://speakerdeck.com/frasertweedale @hackuador hackage.haskell.org/package/jose