Macaroons for Rust

Rust Bay Area Meetup - Mozilla SF

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

Transcript

1. Macaroons A better kind of cookie Tony Arcieri · Rust Bay Area Meetup · February 9th, 2017
3. Today’s Talk • Mini: Rust Cryptography Retrospective • Main: Macaroons • One more thing…
4. What’s been happening in Rust Cryptography?
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
6. Core Rust Crypto RFCs
9. https://cryptocoding.net/index.php/Coding_rules#Clean_memory_of_secret_data Drop, right?
11. RustCrypto GitHub org: Modularizing rust-crypto
13. https://github.com/RustCrypto
15. Safe, fast, small crypto: ring
16. OpenSSL
17. OpenSSL BoringSSL Google “Corp SSL” BoringSSL
18. SSL ring OpenSSL BoringSSL Google “Corp SSL” Bo
19. ring OpenSSL BoringSSL Google “Corp SSL”
20. https://github.com/briansmith/ring
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
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)
23. https://github.com/cryptosphere/ring-pwhash
24. Fast Ed25519 signatures: ed25519-dalek
26. https://github.com/isislovecruft/ed25519-dalek
27. Alternative Ethereum client: Parity
28. https://github.com/ethcore/parity
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 -------------------------------------------------------------------------------
30. Another project of mine: ithos
31. https://github.com/cryptosphere/ithos/
32. Macaroons
33. Most authorization systems ARE TERRIBLE!
34. What makes authorization so hard?
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-
36. An absence of logic A Comprehensive Formal Security Analysis of OAuth 2.0 Daniel Fett University of Trier, Germany fett@uni-trier.de Ralf Küsters University of Trier, Germany kuesters@uni-trier.de Guido Schmitz University of Trier, Germany schmitzg@uni-trier.de 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
37. Ignoring the past…
38. …and never learning from it Logic in Access Control Mart´ ın Abadi University of California at Santa Cruz abadi@cs.ucsc.edu 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
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
40. Maybe?
42. The core problem: Delegation
43. ACLs don’t Tyler Close Hewlett-Packard Labs Palo Alto, CA Email: tyler.close@hp.com 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.
44. Then what does?
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
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) := { ↵
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.
48. What is a Macaroon?
49. Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud Arnar Birgisson Chalmers University of Technology arnarbi@gmail.com Joe Gibbs Politz Brown University joe@cs.brown.edu ´ 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
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
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
52. Bearer Credentials
53. Caveats
54. Redundant Caveats
55. Overlapping Caveats
56. Contextual Caveats
57. Contextual Caveats
58. Example use case: Delegating to bots
59. bf3cc12…
60. bf3cc12…
61. bf3cc12… bf3cc12…
62. bf3cc12… bf3cc12…
63. How can we delegate securely?
64. $ cargo owner --add homu
65. $ git notes add -m "token='bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYWQh'"
66. bf3cc12…
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…
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…
69. bf3cc12…
70. bf3cc12… bf3cc12…
71. bf3cc12… bf3cc12… homu
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…
73. tag = HMAC(key, message)
74. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW Macaroon Structure Nonce
75. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW cid expires 2017-02-10T03:51:50Z Adding Caveats
76. HMAC identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW cid expires 2017-02-10T03:51:50Z Adding Caveats
77. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW cid expires 2017-02-10T03:51:50Z Adding Caveats
78. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW cid expires 2017-02-10T03:51:50Z cid crates-io-publisher homu HMAC Adding Caveats
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
80. https://github.com/cryptosphere/macaroons-rs
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
82. Involving additional services: Third-party caveats
83. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW cid expires 2017-02-10T03:51:50Z cid crates-io-sha256 bf3cc129e674180ddc6243901… cid homu@github.com Third-Party Caveats
84. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW cid expires 2017-02-10T03:51:50Z cid crates-io-sha256 bf3cc129e674180ddc6243901… cid homu@github.com Third-Party Caveats
85. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW cid expires 2017-02-10T03:51:50Z cid crates-io-sha256 bf3cc129e674180ddc6243901… cid homu@github.com Third-Party Caveats
86. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW cid expires 2017-02-10T03:51:50Z cid crates-io-sha256 bf3cc129e674180ddc6243901… cid homu@github.com 3rd Party Key Third-Party Caveats
87. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW cid expires 2017-02-10T03:51:50Z cid crates-io-sha256 bf3cc129e674180ddc6243901… cid homu@github.com Third-Party Caveats
88. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW cid expires 2017-02-10T03:51:50Z cid crates-io-sha256 bf3cc129e674180ddc6243901… cid homu@github.com Third-Party Caveats
89. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW cid expires 2017-02-10T03:51:50Z cid crates-io-sha256 bf3cc129e674180ddc6243901… cid homu@github.com github.com Third-Party Caveats homu
90. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW cid expires 2017-02-10T03:51:50Z cid crates-io-sha256 bf3cc129e674180ddc6243901… cid homu@github.com github.com cid expires 2017-02-10T01:15:42Z Third-Party Caveats
91. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW cid expires 2017-02-10T03:51:50Z cid crates-io-sha256 bf3cc129e674180ddc6243901… cid homu@github.com github.com cid expires 2017-02-10T01:15:42Z Discharge Macaroon Third-Party Caveats
92. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW cid expires 2017-02-10T03:51:50Z cid crates-io-sha256 bf3cc129e674180ddc6243901… cid homu@github.com github.com cid expires 2017-02-10T01:15:42Z Third-Party Caveats
93. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW cid expires 2017-02-10T03:51:50Z cid crates-io-sha256 bf3cc129e674180ddc6243901… cid homu@github.com github.com cid expires 2017-02-10T01:15:42Z Third-Party Caveats
94. identifier bXkgb3BzZWMgaXNuJ3QgdGhhdCBiYW cid expires 2017-02-10T03:51:50Z cid crates-io-sha256 bf3cc129e674180ddc6243901… cid homu@github.com github.com cid expires 2017-02-10T01:15:42Z Third-Party Caveats
95. Cryptographically bound credentials: Holder-of-key proof
96. Nested Third-Party Caveats
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
99. Coming soon: Discharging third-party Macaroons
100. One more thing…
101. RUSTSEC
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)
105. https://github.com/rustsec
106. IRC: irc.mozilla.org:6697 • #rustsec - RustSec vulnerability database • #rust-crypto - Rust cryptography discussion
107. Thanks! – @bascule