$30 off During Our Annual Pro Sale. View Details »

Macaroons for Rust

tarcieri
February 11, 2017

Macaroons for Rust

Rust Bay Area Meetup - Mozilla SF

Video: https://air.mozilla.org/rust-meetup-february-2017-02-09/

tarcieri

February 11, 2017
Tweet

More Decks by tarcieri

Other Decks in Programming

Transcript

  1. Macaroons
    A better kind of cookie
    Tony Arcieri · Rust Bay Area Meetup · February 9th, 2017

    View Slide

  2. View Slide

  3. Today’s Talk
    • Mini: Rust Cryptography Retrospective
    • Main: Macaroons
    • One more thing…

    View Slide

  4. What’s been happening in
    Rust Cryptography?

    View Slide

  5. Rust Cryptography Developments
    • Core issues: In-tree crypto + immovable types
    • RustCrypto GitHub Organization
    • ring: fast high-assurance infrastructural crypto library
    • ed25519-dalek: Fast Ed25519 signatures
    • Parity: a Rust implementation of an Ethereum client

    View Slide

  6. Core Rust
    Crypto RFCs

    View Slide

  7. View Slide

  8. View Slide

  9. https://cryptocoding.net/index.php/Coding_rules#Clean_memory_of_secret_data
    Drop, right?

    View Slide

  10. View Slide

  11. RustCrypto GitHub org:
    Modularizing rust-crypto

    View Slide

  12. View Slide

  13. https://github.com/RustCrypto

    View Slide

  14. View Slide

  15. Safe, fast, small crypto:
    ring

    View Slide

  16. OpenSSL

    View Slide

  17. OpenSSL
    BoringSSL
    Google “Corp SSL”
    BoringSSL

    View Slide

  18. SSL
    ring
    OpenSSL
    BoringSSL
    Google “Corp SSL”
    Bo

    View Slide

  19. ring
    OpenSSL
    BoringSSL
    Google “Corp SSL”

    View Slide

  20. https://github.com/briansmith/ring

    View Slide

  21. Advantages of ring
    • Easy-to-use (hard-to-misuse) API
    • Fast and mature ASM implementations where available
    • Well-tested and well-curated implementations
    • Suitable for embedded use (#![no_std] compatible)
    • Coming (soon?): formal verification of correctness

    View Slide

  22. Algorithms supported by ring
    • AEAD (Encryption)
    • AES-GCM
    • ChaCha20Poly1305
    • ECDH Key Agreement
    • NIST P-256/P-384
    • X25519
    • Hash Functions
    • SHA1
    • SHA-256
    • SHA-384
    • SHA-512
    • Key Derivation
    • HKDF
    • Message Authentication
    • HMAC
    • Password Hashing
    • PBKDF2
    • Random Number Generation
    • Signatures
    • ECDSA w\ P-256/P-384 (verification only)
    • Ed25519
    • RSA (PKCS#1v1.5 and PSS)

    View Slide

  23. https://github.com/cryptosphere/ring-pwhash

    View Slide

  24. Fast Ed25519 signatures:
    ed25519-dalek

    View Slide

  25. View Slide

  26. https://github.com/isislovecruft/ed25519-dalek

    View Slide

  27. Alternative Ethereum client:
    Parity

    View Slide

  28. https://github.com/ethcore/parity

    View Slide

  29. $ cloc parity
    2136 text files.
    2060 unique files.
    197 files ignored.
    github.com/AlDanial/cloc v 1.70 T=8.35 s (232.6 files/s, 35801.7 lines/s)
    -------------------------------------------------------------------------------
    Language files blank comment code
    -------------------------------------------------------------------------------
    Rust 636 18975 19234 95407
    JavaScript 1022 16541 12958 65940
    JSON 54 6 0 57127
    CSS 182 1184 2865 5588
    Markdown 13 267 0 658
    YAML 5 1 3 647
    Bourne Shell 19 81 55 311
    C++ 1 51 24 285
    Swift 2 46 26 215
    HTML 5 2 0 133
    C 1 22 28 127
    C/C++ Header 1 3 3 2
    -------------------------------------------------------------------------------
    SUM: 1941 37179 35196 226440
    -------------------------------------------------------------------------------

    View Slide

  30. Another project of mine:
    ithos

    View Slide

  31. https://github.com/cryptosphere/ithos/

    View Slide

  32. Macaroons

    View Slide

  33. Most authorization systems
    ARE TERRIBLE!

    View Slide

  34. What makes authorization
    so hard?

    View Slide

  35. Ambient authority
    R=y,E=y,S=y setuid(x) setuid(y)
    R=y,E=x,S=y
    setuid(y)
    setuid(x) R=y,E=y,S=x setuid(y)
    R=y,E=x,S=x
    setuid(x) setuid(y)
    setuid(x)
    R=x,E=y,S=x setuid(y)
    R=x,E=x,S=x
    setuid(x)
    setuid(x) setuid(y)
    R=x,E=y,S=y setuid(y)
    R=x,E=x,S=y
    setuid(x) setuid(y)
    setuid(x)
    Figure 6: A finite state automaton describing the setuid system call in Linux. This FSA considers only two distinct
    non-root user ID values
    x
    and
    y
    . Ellipses represent states of the FSA, where a notation like “R=x,E=y,S=x” indicates
    that euid =
    y
    and ruid = suid =
    x
    . Each transition is labelled with the system call it corresponds to.
    R=y,E=x,S=y setuid(0) setuid(x)
    R=y,E=y,S=y
    setuid(y)
    setuid(0) setuid(x) setuid(y)
    R=y,E=y,S=x setuid(0) setuid(y)
    R=y,E=x,S=x
    setuid(x) setuid(y)
    setuid(0) setuid(x)
    R=y,E=y,S=0 setuid(x) setuid(y)
    R=y,E=0,S=0
    setuid(0)
    setuid(y) R=0,E=0,S=0
    setuid(0)
    R=x,E=x,S=x
    setuid(x)
    R=y,E=x,S=0
    setuid(y)
    setuid(0)
    setuid(x)
    R=y,E=0,S=y
    setuid(y)
    setuid(0)
    setuid(x)
    setuid(y)
    setuid(0)
    setuid(x)
    setuid(0) setuid(x) setuid(y)
    R=y,E=0,S=x
    setuid(y)
    setuid(0)
    setuid(x) R=x,E=y,S=x
    setuid(x)
    setuid(0) setuid(y)
    R=x,E=y,S=0 setuid(y)
    R=x,E=0,S=0
    setuid(0) R=x,E=x,S=0
    setuid(x)
    setuid(y)
    setuid(0)
    setuid(x)
    setuid(0)
    setuid(x) setuid(y)
    R=x,E=y,S=y setuid(0) setuid(y)
    R=x,E=x,S=y
    setuid(x) setuid(y)
    setuid(0) setuid(x)
    R=x,E=0,S=y
    setuid(y)
    setuid(0)
    setuid(x)
    R=x,E=0,S=x
    setuid(y)
    setuid(0)
    setuid(x)
    R=0,E=y,S=x setuid(y)
    R=0,E=0,S=x
    setuid(0) R=0,E=x,S=x
    setuid(x)
    setuid(y)
    setuid(0)
    setuid(x)
    setuid(0)
    setuid(x) setuid(y)
    R=0,E=y,S=0
    setuid(0)
    setuid(x) setuid(y)
    R=0,E=y,S=y setuid(x) setuid(y)
    R=0,E=0,S=y
    setuid(0)
    setuid(y)
    setuid(0)
    setuid(x)
    R=0,E=x,S=y
    setuid(y)
    setuid(0)
    setuid(x)
    R=0,E=x,S=0
    setuid(0)
    setuid(x) setuid(y)
    Figure 7: A finite state automaton describing the setuid system call in Linux. This FSA considers three user ID values:
    the root user ID and two distinct non-root user ID values
    x
    and
    y
    . Ellipses represent states of the FSA, where a notation
    like “R=0,E=x,S=y” indicates that ruid = 0, euid =
    x
    and suid =
    y
    . Each transition is labelled with the system call it
    corresponds to.
    A critical requirement is that the operating system must
    behave deterministically given the equivalence class of
    the current state. More precisely, if
    s
    c
    t
    and
    s
    0 c0
    u
    where (
    s, c
    ) ⌘OS
    (
    s
    0
    , c
    0), then we require
    t
    ⌘S u
    . The
    intuition is that the behavior of the operating system will
    depend only on which equivalence class we are in, and
    not on any other information about the state. For in-
    stance, the behavior of the operating system cannot de-
    pend on any global variables that don’t appear in the state
    s
    (the implementation may freely choose one). Finally,
    the GETALLSTATES() function must return a pair (
    S, C
    )
    so that
    S
    contains at least one representative from each
    equivalence class of ⌘S and so that every equivalence
    class of ⌘OS contains some element (
    s, c
    ) with
    c
    2
    C
    .
    When these general requirements are satisfied, the
    BUILDMODEL() algorithm from Figure 3 will correctly
    infer a valid finite-state model for the underlying oper-

    View Slide

  36. An absence of logic
    A Comprehensive Formal Security Analysis of OAuth 2.0
    Daniel Fett
    University of Trier, Germany
    [email protected]
    Ralf Küsters
    University of Trier, Germany
    [email protected]
    Guido Schmitz
    University of Trier, Germany
    [email protected]
    ABSTRACT
    The OAuth 2.0 protocol is one of the most widely deployed au-
    thorization/single sign-on (SSO) protocols and also serves as the
    foundation for the new SSO standard OpenID Connect. Despite the
    popularity of OAuth, so far analysis efforts were mostly targeted at
    finding bugs in specific implementations and were based on formal
    models which abstract from many web features or did not provide
    a formal treatment at all.
    In this paper, we carry out the first extensive formal analysis of
    the OAuth 2.0 standard in an expressive web model. Our analy-
    sis aims at establishing strong authorization, authentication, and
    session integrity guarantees, for which we provide formal defini-
    tions. In our formal analysis, all four OAuth grant types (autho-
    rization code grant, implicit grant, resource owner password cre-
    dentials grant, and the client credentials grant) are covered. They
    may even run simultaneously in the same and different relying par-
    ties and identity providers, where malicious relying parties, identity
    providers, and browsers are considered as well. Our modeling and
    analysis of the OAuth 2.0 standard assumes that security recommen-
    dations and best practices are followed in order to avoid obvious
    and known attacks.
    When proving the security of OAuth in our model, we discovered
    four attacks which break the security of OAuth. The vulnerabilities
    can be exploited in practice and are present also in OpenID Connect.
    We propose fixes for the identified vulnerabilities, and then, for
    the first time, actually prove the security of OAuth in an expressive
    web model. In particular, we show that the fixed version of OAuth
    (with security recommendations and best practices in place) pro-
    vides the authorization, authentication, and session integrity proper-
    ties we specify.
    1. INTRODUCTION
    The OAuth 2.0 authorization framework [20] defines a web-based
    protocol that allows a user to grant web sites access to her resources
    (data or services) at other web sites (authorization). The former
    web sites are called relying parties (RP) and the latter are called
    Permission to make digital or hard copies of all or part of this work for personal or
    classroom use is granted without fee provided that copies are not made or distributed
    for profit or commercial advantage and that copies bear this notice and the full citation
    identity providers (IdP).1 In practice, OAuth 2.0 is often used for
    authentication as well. That is, a user can log in at an RP using her
    identity managed by an IdP (single sign-on, SSO).
    Authorization and SSO solutions have found widespread adop-
    tion in the web over the last years, with OAuth 2.0 being one of the
    most popular frameworks. OAuth 2.0, in the following often sim-
    ply called OAuth,2 is used by identity providers such as Amazon,
    Facebook, Google, Microsoft, Yahoo, GitHub, LinkedIn, StackEx-
    change, and Dropbox. This enables billions of users to log in at
    millions of RPs or share their data with these [35], making OAuth
    one of the most used single sign-on systems on the web.
    OAuth is also the foundation for the new single sign-on protocol
    OpenID Connect, which is already in use and actively supported
    by PayPal (“Log In with PayPal”), Google, and Microsoft, among
    others. Considering the broad industry support for OpenID Connect,
    a widespread adoption of OpenID Connect in the next years seems
    likely. OpenID Connect builds upon OAuth and provides clearly
    defined interfaces for user authentication and additional (optional)
    features, such as dynamic identity provider discovery and relying
    party registration, signing and encryption of messages, and logout.
    In OAuth, the interactions between the user and her browser,
    the RP, and the IdP can be performed in four different flows, or
    grant types: authorization code grant, implicit grant, resource owner
    password credentials grant, and the client credentials grant (we refer
    to these as modes in the following). In addition, all of these modes
    provide further options.
    The goal of this work is to provide an in-depth security analysis
    of OAuth. Analyzing the security of OAuth is a challenging task,
    on the one hand due to the various modes and options that OAuth
    provides, and on the other hand due to the inherent complexity of
    the web.
    So far, most analysis efforts regarding the security of OAuth were
    targeted towards finding errors in specific implementations [6, 10,
    25, 33, 34, 36, 38], rather than the comprehensive analysis of the
    standard itself. Probably the most detailed formal analysis carried
    out on OAuth so far is the one in [6]. However, none of the existing
    analysis efforts of OAuth account for all modes of OAuth running
    simultaneously, which may potentially introduce new security risks.
    In fact, many existing approaches analyze only the authorization
    code mode and the implicit mode of OAuth. Also, importantly,
    there are no analysis efforts that are based on a comprehensive
    formal web model (see below), which, however, is essential to rule

    View Slide

  37. Ignoring the past…

    View Slide

  38. …and never learning from it
    Logic in Access Control
    Mart´
    ın Abadi
    University of California at Santa Cruz
    [email protected]
    Abstract
    Access control is central to security in computer systems.
    Over the years, there have been many efforts to explain and
    to improve access control, sometimes with logical ideas and
    tools. This paper is a partial survey and discussion of the
    role of logic in access control. It considers logical founda-
    tions for access control and their applications, in particular
    in languages for programming security policies.
    1 Introduction
    Access control consists in deciding whether the agent
    that issues a request should be trusted on this request. For
    example, the agent may be a process running on behalf of
    a user, and the request may be a command to read a par-
    ticular file. In this example, the access control machinery
    would be charged with deciding whether the read should
    be permitted. This authorization decision may, in the sim-
    plest case, rely on consulting an access control matrix that
    would map the user’s name and the file name to a set of al-
    lowed operations [23]. The matrix may be implemented in
    terms of access control lists (ACLs), attached to objects, or
    in terms of capabilities, held by principals. Typically, how-
    ever, the authorization decision is considerably more com-
    plex. It may depend, for example, on the user’s membership
    in a group, and on a digitally signed credential that certifies
    this membership.
    Access control is central to security and it is pervasive in
    computer systems. It appears (with peculiar features and
    flaws) in many applications, virtual machines, operating
    systems, and firewalls. Physical protection for facilities and
    for hardware components are other forms of access control.
    Although access control may sometimes seem concep-
    tually straightforward, it is both complex and error-prone in
    practice. The many mechanisms for access control are often
    broken or circumvented.
    would provide a simple, solid, and general foundation for
    access control, as well as methods for designing, imple-
    menting, and validating particular access control mecha-
    nisms. In fact, although logic is not a panacea, its applica-
    tions in access control have been substantial and beneficial.
    This short paper is a partial, informal survey and dis-
    cussion of the role of logic in access control. It consid-
    ers logical formulations of access control and their appli-
    cations, emphasizing recent languages for programming se-
    curity policies in distributed systems. It does not however
    aim to be a complete overview. It deliberately neglects sev-
    eral relevant topics that have been the subjects of significant
    bodies of work. These include:
    • Decidability results for problems related to access con-
    trol (e.g., [17, 26, 28]).
    • Logical approaches for authorizing code execution,
    such as those based on proof-carrying code (e.g., [29]).
    • Formal verification of security properties (e.g., [32]).
    The next section introduces some logical constructs that
    have been employed in connection with access control. The
    following section then describes languages for access con-
    trol, focusing on the Binder language. It is partly based
    on a recent note [2], which also explores an analogy with
    languages for data integration such as the Mediator Specifi-
    cation Language of the Tsimmis system [12, 30].
    2. Logics
    From matrices to logics
    An access control matrix may be viewed as a descrip-
    tion of a ternary relation, may-access. With this inter-
    pretation, may-access(p,o,r) would hold whenever
    the matrix gives principal p the right r on object o. Thus,
    we may obtain a first logic of access control by represent-
    ing a global access control matrix with the predicate symbol

    View Slide

  39. Can we do better?
    terms of access control lists (ACLs), attached to objects, or
    in terms of capabilities, held by principals. Typically, how-
    ever, the authorization decision is considerably more com-
    plex. It may depend, for example, on the user’s membership
    in a group, and on a digitally signed credential that certifies
    this membership.
    Access control is central to security and it is pervasive in
    computer systems. It appears (with peculiar features and
    flaws) in many applications, virtual machines, operating
    systems, and firewalls. Physical protection for facilities and
    for hardware components are other forms of access control.
    Although access control may sometimes seem concep-
    tually straightforward, it is both complex and error-prone in
    practice. The many mechanisms for access control are often
    broken or circumvented.
    Over the years, there have been many efforts to explain
    and to improve access control. Some of those efforts have
    relied on logical ideas and tools. One may hope that logic
    on a
    langu
    catio
    2. L
    From
    A
    tion
    preta
    the m
    we m
    ing a
    may
    lus.
    enab

    View Slide

  40. Maybe?

    View Slide

  41. View Slide

  42. The core problem:
    Delegation

    View Slide

  43. ACLs don’t
    Tyler Close
    Hewlett-Packard Labs
    Palo Alto, CA
    Email: [email protected]
    Abstract
    The ACL model is unable to make correct access
    decisions for interactions involving more than two
    principals, since required information is not retained
    across message sends. Though this deficiency has long
    been documented in the published literature, it is
    not widely understood. This logic error in the ACL
    model is exploited by both the clickjacking and Cross-
    Site Request Forgery attacks that affect many Web
    applications.
    1. Introduction
    In the last few years, increasing attention has been
    devoted to attacks which are distinctly different in
    nature from the major vulnerabilities discussed in the
    past. Previously, buffer overflow, SQL injection and
    Cross-Site Scripting (XSS) garnered the most attention.
    Neither attack requ
    attacker into the vic
    use the victim’s exi
    ends. Using messag
    ventions expected f
    makes use of resour
    cording to the applic
    in a CSRF attack,
    a buy request to a
    though no one but
    to be allowed to d
    an attacker may st
    no one but the co
    allowed to do that.
    may correctly imple
    (ACLs), somehow
    resources that are
    does so without m
    program logic.

    View Slide

  44. Then what does?

    View Slide

  45. Object Capabilities
    The KeyKOS® Nanokernel Architecture
    Alan C. Bomberger Norman Hardy
    A. Peri Frantz Charles R. Landau
    William S. Frantz Jonathan S. Shapiro
    Ann C. Hardy
    ABSTRACT
    The KeyKOS nanokernel is a capability-based object-oriented operating system that has been in
    production use since 1983. Its original implementation was motivated by the need to provide
    security, reliability, and 24-hour availability for applications on the Tymnet® hosts.
    Requirements included the ability to run multiple instantiations of several operating systems on a
    single hardware system. KeyKOS was implemented on the System/370, and has since been
    ported to the 680x0 and 88x00 processor families. Implementations of EDX, RPS, VM, MVS,
    and UNIX have been constructed. The nanokernel is approximately 20,000 lines of C code,
    including capability, checkpoint, and virtual memory support. The nanokernel itself can run in
    less than 100 Kilobytes of memory.
    KeyKOS is characterized by a small set of powerful and highly optimized primitives that allow it
    to achieve performance competitive with the macrokernel operating systems that it replaces.
    Objects are exclusively invoked through protected capabilities, supporting high levels of security
    and intervals between failures in excess of one year. Messages between agents may contain both
    capabilities and data. Checkpoints at tunable intervals provide system-wide backup, fail-over
    support, and system restart times typically less than 30 seconds. In addition, a journaling
    mechanism provides support for high-performance transaction processing. On restart, all
    processes are restored to their exact state at the time of checkpoint, including registers and
    virtual memory.
    This paper describes the KeyKOS architecture, and the binary compatible UNIX implementation
    that it supports.
    1. Introduction

    View Slide

  46. Authorization Logic
    Syntax:
    Compound principals A, B ::= P | k | A ^ B | b
    Formulas , ::= valid | true
    | p | X | 8X.
    | ^ | _ |
    | A says | A ) B
    Axioms:
    All the axioms of propositional constructive logic [PROP]
    ` (A says ( )) (A says A says ) [DISTRIBUTION]
    ` (A says B ) A) B ) A [HANDOFF]
    ` A ^ A ⌘ A [CONJ1]
    ` A ^ B ⌘ B ^ A [CONJ2]
    ` (A ^ B) ^ C ⌘ A ^ (B ^ C) [CONJ3]
    ` (A ^ B says ) ⌘ (A says ) ^ (B says ) [CONJ4]
    ` A ) B ⌘ (A ^ B = A) [SPEAKS-FOR]
    ` (TR says ) (b says valid) [PPRIN]
    Rules: ` `
    `
    [MODUS-PONENS]
    `
    ` A says
    [NECESSITATION]
    Fig. 11. The syntax, axioms and rules for an authorization logic suitable for
    macaroons. Here,
    TR
    and b are request and predicate principals, respectively,
    P
    2
    Prncs
    ,
    k
    2
    Keys
    , and
    X
    is a variable in a proposition
    p
    2
    PropCavs
    .
    Request principals and predicate principals: A request
    principal
    TR
    is a special principal that makes the strongest
    possible assertion—using propositions from
    PropCavs
    —that
    a target service can see to be true for the context of a request.
    Such principals are completely controlled by the target service.
    the macaroon signatures verify using this
    all embedded caveat predicates are satisfied
    defining macaroon formulas, it’s worth givin
    Consider a macaroon
    M1
    := macaroon@
    is minted from root key
    k0
    without any cave
    M1
    represents a complete delegation from
    empty caveat principal d
    true, which considers
    Thus,
    M1
    is modeled by the formula
    k0 sa
    A macaroon
    M2
    := macaroon@L
    h
    kId,
    can be obtained by extending
    M1
    with a
    whose predicate is , to represent a delega
    key
    k0
    to the caveat principal b. This macaro
    by the formula
    k0 says
    b )
    k0
    .
    Finally, the macaroon
    M2
    can be exten
    party caveat whose root key is
    cK
    , to obta
    M3
    := macaroon@L
    h
    kId,
    [cav@>
    h
    ,
    0i
    ,
    cav
    This macaroon
    M3
    represents a delegation
    k0
    to the conjunction of the
    cK
    and b pr
    k0
    says that a request is valid only if both
    Thus,
    M3
    is modeled by the formula
    k0 sa
    The formula for an arbitrary macaroon
    M
    ca
    Definition 1 (Macaroon formulas): A m
    root key is
    k0
    , embedding first-party caveats
    are 1, . . . , m
    , and embedding third-party c
    keys are
    cK1, . . . , cKn
    , is modeled using t

    (
    M
    ) :=
    k0 says
    (c
    1
    ^
    . . .
    ^ c
    m
    ^
    cK1
    ^
    For a set M, the formulas are

    (M) := {

    View Slide

  47. Macaroon Delegation
    TS
    IS
    C
    TS
    IS
    C
    TS
    IS
    C
    Proxy Re-minted Macaroon
    restrictions restrictions restrictions
    Fig. 2. Three ways for an intermediary service IS to give a client C limited
    access to a target service TS: by proxying requests, by having TS mint new,
    restricted credentials for C, or by IS deriving new macaroons for C. Arrows
    show credential passing and doubled arrows indicate access.
    In their expressiveness, and in aspects of their construction,
    macaroons are related to cascaded proxy certificates [44], re-
    stricted delegation [33], active certificates [12], proof-carrying
    authentication [6], and Grid computing [22], as well as systems
    for limiting resource consumption [23] and access to net-
    predicate that must hold
    that the derived macaroon
    with that predicate evaluat
    of each particular request
    adding caveats, new, mor
    can be directly derived
    requests to the target ser
    from it. Thus, macaroon
    overhead, loss of transpar
    by the proxying and cred
    used in the today’s Cloud
    For example, every m
    more validity-period cave
    (at the target service) duri
    requests; similarly, each m
    restrict the arguments per
    have multiple caveats on
    which case all the cavea
    context of requests.

    View Slide

  48. What is a
    Macaroon?

    View Slide

  49. Macaroons: Cookies with Contextual Caveats
    for Decentralized Authorization in the Cloud
    Arnar Birgisson
    Chalmers University of Technology
    [email protected]
    Joe Gibbs Politz
    Brown University
    [email protected]
    ´
    Ulfar Erlingsson, Ankur Taly,
    Michael Vrable, and Mark Lentczner
    Google Inc
    {ulfar,ataly,mvrable,mzero}@google.com
    Abstract
    —Controlled sharing is fundamental to distributed
    systems; yet, on the Web, and in the Cloud, sharing is still
    based on rudimentary mechanisms. More flexible, decentralized
    cryptographic authorization credentials have not been adopted,
    largely because their mechanisms have not been incrementally
    deployable, simple enough, or efficient enough to implement
    across the relevant systems and devices.
    This paper introduces
    macaroons
    : flexible authorization cre-
    dentials for Cloud services that support
    decentralized delegation
    between principals. Macaroons are based on a construction that
    uses nested, chained MACs (e.g., HMACs [43]) in a manner that
    is highly efficient, easy to deploy, and widely applicable.
    Although macaroons are bearer credentials, like Web cookies,
    macaroons embed
    caveats
    that
    attenuate
    and
    contextually confine
    when, where, by who, and for what purpose a target service
    should authorize requests. This paper describes macaroons and
    motivates their design, compares them to other credential systems,
    such as cookies and SPKI/SDSI [14], evaluates and measures a
    prototype implementation, and discusses practical security and
    application considerations. In particular, it is considered how
    macaroons can enable more fine-grained authorization in the
    Cloud, e.g., by strengthening mechanisms like OAuth2 [17], and
    a formalization of macaroons is given in authorization logic.
    I. INTRODUCTION
    Macaroons are authorization credentials that provide flexible
    support for controlled sharing in decentralized, distributed
    systems. Macaroons are widely applicable since they are a
    form of bearer credentials—much like commonly-used cookies
    on the Web—and have an efficient construction based on keyed
    cryptographic message digests [43].
    Macaroons are designed for the Web, mobile devices, and
    the related distributed systems collectively known as the Cloud.
    Such modern software is often constructed as a decentralized
    graph of collaborative, loosely-coupled services. Those ser-
    vices comprise different protection domains, communication
    channels, execution environments, and implementations—with
    each service reflecting the characteristics and interests of the
    different underlying stakeholders. Thus, security and access
    control are of critical concern, especially as the Cloud is
    commonly used for sharing private, sensitive end-user data,
    e.g., through email or social networking applications.
    Unfortunately, controlled sharing in the Cloud is founded
    on basic, rudimentary authorization mechanisms, such HTTP
    cookies that carry pure bearer tokens [21, 54]. Thus, today, it
    is practically impossible for the owner of a private, sensitive
    image stored at one Cloud service to email a URL link to that
    image, safely—given the many opportunities for impersonation
    and eavesdropping—such that the image can be seen only
    by logged-in members of a group of users that the owner
    maintains at another, unrelated Cloud service. Currently, this
    use case is possible only if the image, access group, and users
    are all at a single service, or if two Cloud services keep special,
    pairwise ties using custom, proprietary mechanisms (e.g., as
    done by Dropbox and Facebook [55]).
    Of course, the ubiquitous use of bearer tokens is due to
    advantages—such as simplicity and ease of adoption—that
    cannot be overlooked. For example, bearer tokens can easily
    authorize access for unregistered users (e.g., to the shopping
    cart of a first-time visitor to a Cloud service) or from unnamed,
    transient contexts (e.g., from a pop-up window shown during
    private, incognito Web browsing). Such dynamic and short-
    lived principals arise naturally in distributed systems, like the
    Cloud and the “Grid” [47]. In comparison, most authorization
    mechanisms based on public-key certificates are not directly
    suited to the Cloud, since they are based on more expensive
    primitives that can be difficult to deploy, and define long-lived,
    linkable identities, which may impact end-user privacy [21].
    Even so, the inflexibility of current Cloud authorization is
    quite unsatisfactory. Most users will have first-hand experience
    of the resulting frustrations—for example, because they have
    clicked on a shared URL, only to be redirected to a page
    requesting account creation or sharing of their existing online
    identity. Similarly, many users will have uncomfortably surren-
    dered their passwords to use some Cloud service functionality,
    such as to populate an address book (e.g., on LinkedIn.com)
    or to aggregate their financial data (e.g., on mint.com).
    Macaroons aim to combine the best aspects of using
    bearer tokens and using flexible, public-key certificates for
    authorization, by providing (i) the wide applicability, ease-
    of-use, and privacy benefits of bearer credentials based on
    fast cryptographic primitives, (ii) the expressiveness of truly
    decentralized credentials based on authorization logic, like
    SPKI/SDSI [14], and (iii) general, precise restrictions on how,
    where, and when credentials may be used.
    Permission to freely reproduce all or part of this paper for noncommercial
    purposes is granted provided that copies bear this notice and the full citation
    on the first page. Reproduction for commercial purposes is strictly prohibited
    without the prior written consent of the Internet Society, the first-named author
    (for reproduction of an entire paper only), and the author’s employer if the
    paper was prepared within the scope of employment.
    NDSS ’14, 23-26 February 2014, San Diego, CA, USA
    Copyright 2014 Internet Society, ISBN 1-891562-35-5
    http://dx.doi.org/doi-info-to-be-provided-later

    View Slide

  50. Macaroons timeline
    • 2014: Macaroons paper from Google
    • 2015: libmacaroons released, ported to over a dozen
    different languages (including Rust)
    • 2016: Macaroons v2 format released

    View Slide

  51. Distributed Authorization in Vanadium
    Ankur Taly1 and Asim Shankar1
    Google Inc.
    Abstract. In this tutorial, we present an authorization model for dis-
    tributed systems that operate with limited internet connectivity. Reliable
    internet access remains a luxury for a majority of the world’s population.
    Even for those who can a↵ord it, a dependence on internet connectivity
    may lead to sub-optimal user experiences. With a focus on decentral-
    ized deployment, we present an authorization model that is suitable for
    scenarios where devices right next to each other (such as a sensor or
    a friend’s phone) should be able to communicate securely in a peer-to-
    peer manner. The model has been deployed as part of an open-source
    distributed application framework called Vanadium. As part of this tuto-
    rial, we survey some of the key ideas and techniques used in distributed
    authorization, and explain how they are combined in the design of our
    model.
    1 Introduction
    Authorization is a fundamental problem in computer security that deals with
    whether a request to access a resource must be granted. The decision is made
    by a reference monitor guarding the resource. Authorization is fairly straightfor-
    ward in closed systems where all resources of interest are held on a small set of
    devices, and reference monitors have pre-existing relationships with all autho-
    rized principals. In these systems, authorizing a request involves identifying the
    principal making the request, and then verifying that this identity is allowed by
    the resource’s access control policy. The former is called
    authentication
    , and the
    latter is called
    access control
    .
    Authorization in distributed systems is significantly more complex as the
    resources are spread across a network of devices under di↵erent administrative
    domains [22]. Moreover, not all devices and principals in the system may know
    each other beforehand, making even authentication complicated. For instance,
    consider the fairly common scenario of a user Alice trying to play a movie from
    her internet video service on her television (TV). It involves the TV authorizing
    the request from Alice to play a movie, and the video service authorizing the
    request from the TV to access Alice’s account. The video service may recognize
    only Alice, and not her TV. The TV must convince the video service that it is
    acting on Alice’s behalf.
    With the advent of the Internet of Things (IoT), various physical devices that
    we commonly interact with in our daily lives are controllable over the network,
    and are thus part of a large distributed system. These devices range from tiny

    View Slide

  52. Bearer Credentials

    View Slide

  53. Caveats

    View Slide

  54. Redundant Caveats

    View Slide

  55. Overlapping Caveats

    View Slide

  56. Contextual Caveats

    View Slide

  57. Contextual Caveats

    View Slide

  58. Example use case:
    Delegating to bots

    View Slide

  59. bf3cc12…

    View Slide

  60. bf3cc12…

    View Slide

  61. bf3cc12… bf3cc12…

    View Slide

  62. bf3cc12… bf3cc12…

    View Slide

  63. How can we delegate
    securely?

    View Slide

  64. $ cargo owner --add homu

    View Slide

  65. $ git notes add -m "token='bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYWQh'"

    View Slide

  66. bf3cc12…

    View Slide

  67. bf3cc12…
    identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYWQh
    cid expires 2017-02-10T03:51:50Z
    cid crates-io-publisher homu
    cid crates-io-crate widget
    cid crates-io-version 1.2.3
    cid crates-io-sha256 bf3cc129e674180ddc6243901…

    View Slide

  68. bf3cc12…
    $ git notes add -m “macaroon=' . . . '"
    cid crates-io-publisher homu
    identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYWQh
    cid expires 2017-02-10T03:51:50Z
    cid crates-io-crate widget
    cid crates-io-version 1.2.3
    cid crates-io-sha256 bf3cc129e674180ddc6243901…

    View Slide

  69. bf3cc12…

    View Slide

  70. bf3cc12… bf3cc12…

    View Slide

  71. bf3cc12… bf3cc12…
    homu

    View Slide

  72. bf3cc12… bf3cc12…
    homu
    cid crates-io-publisher homu
    identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYWQh
    cid expires 2017-02-10T03:51:50Z
    cid crates-io-crate widget
    cid crates-io-version 1.2.3
    cid crates-io-sha256 bf3cc129e674180ddc6243901…

    View Slide

  73. tag = HMAC(key, message)

    View Slide

  74. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW
    Macaroon Structure
    Nonce

    View Slide

  75. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW
    cid expires 2017-02-10T03:51:50Z
    Adding Caveats

    View Slide

  76. HMAC
    identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW
    cid expires 2017-02-10T03:51:50Z
    Adding Caveats

    View Slide

  77. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW
    cid expires 2017-02-10T03:51:50Z
    Adding Caveats

    View Slide

  78. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW
    cid expires 2017-02-10T03:51:50Z
    cid crates-io-publisher homu HMAC
    Adding Caveats

    View Slide

  79. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW
    cid expires 2017-02-10T03:51:50Z
    cid crates-io-publisher homu
    Adding Caveats
    A
    t
    t
    e
    n
    u
    a
    t
    i
    o
    n

    View Slide

  80. https://github.com/cryptosphere/macaroons-rs

    View Slide

  81. extern crate macaroons;
    use macaroons::caveat::Caveat;
    use macaroons::token::Token;
    use macaroons::v1::V1Token;
    use macaroons::verifier::Func;
    fn make_macaroon(key: &[u8], id: &[u8]) -> V1Token {
    let macaroon = V1Token::new(key, id, None);
    macroon.add_caveat(&Caveat::first_party(b"expires 2017-02-10T03:51:50Z".to_vec()));
    macroon.add_caveat(&Caveat::first_party(b"cid crates-io-publisher homu".to_vec()));
    macaroon
    }
    fn verify_caveat(predicate: &[u8]) -> bool {
    ...
    }
    fn verify_macaroon(key: &[u8], macaroon: V1Token) -> bool {
    macaroon.verify(&example_key(), &Func(verify_caveat)).is_ok()
    }
    Example

    View Slide

  82. Involving additional services:
    Third-party caveats

    View Slide

  83. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW
    cid expires 2017-02-10T03:51:50Z
    cid crates-io-sha256 bf3cc129e674180ddc6243901…
    cid [email protected]
    Third-Party Caveats

    View Slide

  84. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW
    cid expires 2017-02-10T03:51:50Z
    cid crates-io-sha256 bf3cc129e674180ddc6243901…
    cid [email protected]
    Third-Party Caveats

    View Slide

  85. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW
    cid expires 2017-02-10T03:51:50Z
    cid crates-io-sha256 bf3cc129e674180ddc6243901…
    cid [email protected]
    Third-Party Caveats

    View Slide

  86. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW
    cid expires 2017-02-10T03:51:50Z
    cid crates-io-sha256 bf3cc129e674180ddc6243901…
    cid [email protected]
    3rd Party Key
    Third-Party Caveats

    View Slide

  87. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW
    cid expires 2017-02-10T03:51:50Z
    cid crates-io-sha256 bf3cc129e674180ddc6243901…
    cid [email protected]
    Third-Party Caveats

    View Slide

  88. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW
    cid expires 2017-02-10T03:51:50Z
    cid crates-io-sha256 bf3cc129e674180ddc6243901…
    cid [email protected]
    Third-Party Caveats

    View Slide

  89. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW
    cid expires 2017-02-10T03:51:50Z
    cid crates-io-sha256 bf3cc129e674180ddc6243901…
    cid [email protected]
    github.com
    Third-Party Caveats
    homu

    View Slide

  90. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW
    cid expires 2017-02-10T03:51:50Z
    cid crates-io-sha256 bf3cc129e674180ddc6243901…
    cid [email protected]
    github.com
    cid expires 2017-02-10T01:15:42Z
    Third-Party Caveats

    View Slide

  91. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW
    cid expires 2017-02-10T03:51:50Z
    cid crates-io-sha256 bf3cc129e674180ddc6243901…
    cid [email protected]
    github.com
    cid expires 2017-02-10T01:15:42Z
    Discharge Macaroon
    Third-Party Caveats

    View Slide

  92. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW
    cid expires 2017-02-10T03:51:50Z
    cid crates-io-sha256 bf3cc129e674180ddc6243901…
    cid [email protected]
    github.com
    cid expires 2017-02-10T01:15:42Z
    Third-Party Caveats

    View Slide

  93. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW
    cid expires 2017-02-10T03:51:50Z
    cid crates-io-sha256 bf3cc129e674180ddc6243901…
    cid [email protected]
    github.com
    cid expires 2017-02-10T01:15:42Z
    Third-Party Caveats

    View Slide

  94. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW
    cid expires 2017-02-10T03:51:50Z
    cid crates-io-sha256 bf3cc129e674180ddc6243901…
    cid [email protected]
    github.com
    cid expires 2017-02-10T01:15:42Z
    Third-Party Caveats

    View Slide

  95. Cryptographically bound credentials:
    Holder-of-key proof

    View Slide

  96. Nested Third-Party Caveats

    View Slide

  97. extern crate macaroons;
    use macaroons::caveat::Caveat;
    use macaroons::token::Token;
    use macaroons::v1::V1Token;
    fn make_macaroon(key: &[u8], third_party_key: &[u8]) -> V1Token {
    let macaroon = V1Token::new(key, id, None);
    let caveat = Caveat::third_party(third_party_key,
    b"github-user homu",
    b"https://github.com/discharge");
    macroon.add_caveat(&Caveat::third_party(caveat));
    macaroon
    }
    Third-Party Caveat Example

    View Slide

  98. View Slide

  99. Coming soon:
    Discharging third-party Macaroons

    View Slide

  100. One more thing…

    View Slide

  101. RUSTSEC

    View Slide

  102. View Slide

  103. View Slide

  104. RustSec: Crate Vulnerability Database
    • File vulnerabilities with cargo advisory
    • Check for vulnerable crates with cargo audit
    • Vulnerability database stored on GitHub
    • Indexed using Distributed Weakness Filing (DWF)

    View Slide

  105. https://github.com/rustsec

    View Slide

  106. IRC: irc.mozilla.org:6697
    • #rustsec - RustSec vulnerability database
    • #rust-crypto - Rust cryptography discussion

    View Slide

  107. Thanks!
    – @bascule

    View Slide