1
Cryptographically Verified Design and Implementation of a Distributed Key Manager
Tolga Acar∗,Cedric´ Fournet†,Dan Shumow∗ ∗ Microsoft Research, One Microsoft Way, Redmond, WA 98052, USA {tolga,danshu}@microsoft.com † Microsoft Research, 7 J J Thomson Ave, Cambridge CB3 0FB, UK [email protected]
Abstract Enterprise IT departments used to assume that data We present DKM, a distributed key management system on the company intranet was secure as long as it was with a cryptographically verified code base. hidden behind firewalls and VPNs, Cloud computing DKM implements a new data protection API. It clearly invalidates this naive assumption: in outsourced manages keys and policies on behalf of groups of infrastructures, data security necessarily involves cryp- users that share data. To ensure long-term protection, tography. However, encrypted storage requires users to DKM supports cryptographic agility: algorithms, keys, manage their keys. Thus, cryptography shifts the burden and policies can evolve for protecting fresh data while from protecting data to protecting keys in distributed preserving access to old data. DKM is written in C# and systems. Managing cryptographic keys remains one currently used by several large data-center applications. of the hard problems in applied cryptography. With- To verify our design and implementation, we also out proper key management, an otherwise theoretically write a lightweight reference implementation of DKM secure system is in reality quite vulnerable. For ex- in F#. This code closes the gap between formal crypto- ample, TLS and IPsec are insecure without a proper graphic models and production code: PKI [15, 19, 20], and SSH is vulnerable to man-in- • Formally, the F# code is a very precise model of the-middle attacks without trusted public keys [29]. DKM: we automatically verify its security against Similarly, NIST identified several difficulties for storage active adversaries, using a refinement type-checker encryption [28]: managing access to keys in storage, coupled with an SMT solver and new symbolic cryptographic algorithm and key length selection, and libraries for cryptographic agility. notably, the ease of solution updates as stronger algo- • Concretely, the F# code closely mirrors our produc- rithms and keys become available. tion code, and we automatically test that the cor- To address the increasing demand for secure per- responding C# and F# fragments can be swapped sisted data in distributed environments, we develop without affecting the runtime behavior of DKM. a Distributed Key Manager (DKM). DKM operations rely on cryptographic keys, policies, and access control To the best of our knowledge, this is the largest information, stored in a distributed repository. Our goal cryptographically-verified implementation to date. We is not to create a new authentication mechanism or also describe several problems we uncovered and fixed a secure key repository. On the contrary, we build as part of this joint design, implementation, and verifi- on existing authentication, authorization, and storage cation process. methods, such as Active Directory and SQL. The verified DKM implementation is far from being I. Introduction an academic exercise. DKM has been integrated into several large products and services of a large software Securing data at rest is a challenging problem that company; some of them are data center applications that has become increasingly important. While numerous implement underpinnings of the now-pervasive “cloud” protocols are routinely deployed to protect data in where flexible cryptographic policies are required to transit over networks, such as SSL/TLS, IPsec, and service the diverse needs of customers. Multiple busi- SSH [15, 19, 20, 29], security for stored data, especially ness groups have shipped DKM in boxed products and shared stored data in large and distributed systems, is deployed them in large data centers in various hosted much less advanced. service environments. We describe three such real-life 2 scenarios in Section II. concrete production code, by applying verification tools Data Protection APIs. The Windows operating sys- on a large scale, early in the design and implementa- tem features a 10-year-old interface (DPAPI) providing tion process. Our method relies on developing verified local data protection services to user and system pro- reference implementations [6, 18, 11], also known as cesses [26]. DPAPI does not share keys across users executable specifications, using general-purpose pro- or machines—a severe restriction for data centers. We gramming languages (rather than, say, rewriting rules or design DKM to provide a similar service to multiple process calculi). Thus, we obtain a very precise formal users across multiple machines. specification of the product, shared between developers, security experts, and automated verification tools. DKM is not a cryptographic API, such as CAPI [24], CNG [25], PKCS#11 [27] or KeyCzar [14]. CAPI, Compared with abstract models distilled from infor- CNG, and PKCS#11 are APIs exposing cryptographic mal specifications, reference implementations also ben- primitives through well-defined interfaces. KeyCzar efit from existing software tools, such as programming tackles cryptographic misuse by hiding details such environments, compilers, typecheckers, debuggers, and as key lengths and algorithms, and by providing safe test harnesses. Pragmatically, the functional properties defaults through a simple interface. Unlike DKM, Key- of the model can be automatically tested against produc- Czar does not automatically manage keys or provide tion code. Conversely, when there is an ambiguity, one agility. By design, DKM does not expose cryptography: can quickly assemble new security tests from the refer- it provides a data protection interface. Various cryp- ence code, run them against production code, observe tographic parameter decisions, key management and the result, and fix one of the two. sharing across users and machines, and key lifecycle We implement DKM in C# and F# (a variant of management are abstracted away from the user [2]. We ML). The production code is entirely written in C#. describe the DKM architecture in Sections II and V. Additional F# code covers the security-critical parts of the implementation, rewritten in a more functional Cryptographic Agility. Over time, cryptographic algo- style to enable its automated cryptographic verification rithms become obsolete and keys become too short for using F7 [8], a refinement typechecker coupled with a desired security level. For example, DES [17] was Z3 [13], an SMT solver. We obtain in particular a the primary encryption algorithm a couple of decades full-fledged, verified reference implementation of DKM. ago. It was later replaced by 3DES and eventually (Other software verification tools independently apply AES. MD5 and SHA1 were the primary hash algorithms to C# production code; they check simple safety prop- until major vulnerabilities were disclosed [32, 31], and erties, for instance excluding out-of-range access to an industry-wide effort started to replace them with arrays, or dereference on null objects; However, they SHA2. However, retiring a cryptographic algorithm is do not handle the security properties verified in this easier said than done. Disabling weak algorithms may paper, which involve active adversaries, concurrency, improve security in theory, but may also cause data loss and cryptography.) We describe our C# and F# code and renders real-life systems unusable, an unacceptable in Sections V and VI. trade-off for many products. Very few large cryptographically-verified reference We design DKM to be cryptographically agile: inse- implementations exist, notably for subsets of TLS [7] cure algorithms can be replaced easily while maintain- and CardSpace [9]. Their code was developed with ing backwards compatibility. DKM can generate and specific verification tools in mind, independently of the distribute fresh keys upon each algorithm change, and original protocol design and implementation, so they provides support for data re-encryption; this is recom- treat prior production code as black boxes for basic mended, but often not tenable in practice: keys may be interoperability testing. In contrast, we advocate a close derived from unalterable hardware-provided secrets or collaboration between designers, developers and secu- from re-usable passwords; key distribution may be slow rity reviewers, and we use a single code base for the two or expensive; besides, operational oversights may lead implementations. We take advantage of the fine-grained to accidental key re-use. Thus, DKM embeds defensive integration of C# and F# within the .NET framework key-derivation mechanisms to support (apparent) key to compose them at the level of individual methods: we re-use across algorithms, even broken algorithms. We precisely align each fragment of (formally verified) F# present our cryptographic constructions in Section III. code to the corresponding fragment of (production) C# Verifying DKM design and implementation. Despite code. Both implementations share the same structure, their technical merits, formal tools for cryptography along with the same typed interfaces. This complicates are seldom applied to the design and implementation verification, but also yields stronger guarantees for the of new protocols and APIs. Our formal work shows production code. Indeed, this task involves a careful how to close the gap between cryptographic models and code review, driven from the elaboration of a verified 3 model, with numerous automated verifications and tests ‘blob’ can then be persisted in untrusted storage. Con- between the two. In our experience, it led to the dis- versely, Unprotect verifies and decrypts a given blob, covery of ambiguities in the DKM design, of delicate and then returns the plaintext data to the user, or fails low-level issues in its implementation, and of a few with a ‘corrupted data’ error. If the user does not belong serious vulnerabilities. Overall, we improved DKM and to the named group, both calls fail with an ‘access gained more confidence in its security, with a reasonable denied’ error. verification overhead: we wrote 5% additional F# code, Each DKM group relies on a small amount of trusted and automated verification runs faster than our test suite. data kept in the repository, essentially a collection of Main Contributions. To our knowledge, this is the first keys and a cryptographic policy. Repository access, time automated cryptographic verification is integrated effective cryptographic policy determination, and all in the design and production of a new security com- cryptographic operations are hidden behind the DKM ponent deployed in large-scale commercial products. interface. The repository has client (requestor) and Also, to the best of our knowledge, this is the largest server (responder) components; it is used as a black- cryptographically-verified implementation to date. box by DKM on behalf of each user. Authorization is We verify the design and implementations of DKM at group granularity and is enforced by the repository. for a threat model that covers (in particular) our key Some users, called group administrators, can also add deployed scenarios. We obtain formal security guar- members or change its policy. This requires write access antees for F# reference code tightly linked to our C# to the repository. Conversely, the untrusted stores are production code. We discuss problems discovered as directly managed by the users; they may consist of file part of this hybrid verification process, as well as their systems, SQL servers, or any other storage medium. We describe two cloud scenarios with data-center fixes. We highlight that our efforts have a direct impact servers acting as DKM users. These scenarios are sim- in the security of real products. plified from real life deployed products that use DKM. Contents. Section II presents DKM using a few de- Scenario 1. Hosted E-Mail Server. Consider a cloud ployment scenarios. Section III specifies its main cryp- e-mail service hosted on multiple servers. The e-mail tographic constructions and discusses cryptographic servers share the same set of keys for protecting mailbox agility. Section IV defines its security goals (precisely, contents. They offer offer message aggregation, fetching but informally). Section V gives selected C# imple- mail from third-party service providers on behalf of mentation details. Section VI presents the reference F# their users, and storing them in user mail boxes. Third- implementation. Section VII evaluates our approach, party services require a user name and password for discusses several weaknesses we identified and fixed, authentication, so it is necessary for the e-mail servers and concludes. For readers interested in the details to have access to these credentials. The data center hosts of our formal verification we have provided appen- e-mail for multiple tenants. Each tenant has an e-mail dices. Appendix A reviews our verification method. administrator to remotely manage that tenant’s e-mail Appendix A gives selected modeling details. This paper settings. One threat is that these e-mail administrators presents only selected code excerpts and omits many may attempt to steal a user’s plaintext credentials. details. The entire F# and F7 source code used for Another threat is the data center personnel who may verification is available from http://research.microsoft. access a user’s plaintext credentials. ∼ com/ fournet/dkm. To address these threats, a data center administrator creates a DKM group to protect e-mail credentials and II. Distributed Key Manager grants read/write access only to the e-mail servers. The DKM repository denies e-mail users, e-mail adminis- DKM involves three roles: users, a trusted repository, trators, and data center operations personnel access to and untrusted stores; it operates on data organized into DKM groups with the exception of a few trusted data named groups of users that share the data. DKM is a center administrators. The typical e-mail fetch workflow library that runs on the users’ machines, on their behalf, starts with an e-mail server reading a user’s encrypted with their authenticated identity. As it reads and writes credentials (labeled (1) on Figure 1). The e-mail server data, each user may call the DKM API to carry out sends a decryption request to DKM and receives the Protect and Unprotect operations, of the form below: user’s plaintext credentials. In step (3), the e-mail server authenticates to the external server. blob := Protect (group, data) data := Unprotect (group, blob) Scenario 2. Offloading Web Server State. In a large scale deployment with thousands of servers, sometimes Intuitively, Protect applies some authenticated encryp- spread across multiple data centers, any server affinity tion algorithm to the user data. The resulting ciphertext to session states is a huge impediment to scalability 4
Tenant 1 Manage Tenant 1 Tenant 2 settings Repository No Access Admin 1 Settings Settings DKM Keys No Access User 1 Access Mailbox Store Mailbox User’s Mailbox User’s Mailbox
Internet User’s DKM User’s DKM encrypted encrypted Tenant 2 password password
Admin 2 2 1 E-Mail Servers Mail Server E-Mail Servers can retrieve mail from the ISP on behalf (Hotmail, Yahoo, User 2 DKM 3 of the user Gmail, etc)
Fig. 2. Web server state offloading scenario.
Fig. 1. DKM hosted e-mail scenario. initially proposed by Acar et al. [1]. Cryptographic Algorithms. DKM policies are param- and reliability. A common approach is to make the eterized by two kinds of symmetric-key algorithms. servers stateless, and instead pass any session state back and forth between the client and the server. The • We let E range over encryption algorithms, and session state may contain user credentials, such as write D for the corresponding decryption algo- forms-based authentication data, as well as data-center- rithm. We currently use AES in CBC mode. specific sensitive information. This state must also be Similarly, we let Eae range over authenticated preserved across multiple requests serviced by different encryption algorithms and a proper Dae for an servers. The threat is that a client may read and modify authenticated decryption algorithm. We currently his session state, or even the session state of other use AES-GCM [23]. clients. Figure 2 depicts the data flow with two requests • We let H and Hd independently range over keyed where session state 1 is created on one server, and is hash algorithms. We currently use HMAC [4, 3] read and modified to session state 2 on another server. with either SHA-256 or SHA-512. TLS provides adequate security to session state trans- Each algorithm has a fixed key length, written |E|, mitted over the network. However, the session state must |Eae|, |H|, and |Hd|, respectively. Each algorithm also not be disclosed to the user and must not be modified has a global, unambiguous algorithm identifier, written by the user. Naive attempts to use CBC encryption hEi, hEaei, hHi, and hHdi. In our implementation, have been proved vulnerable in theory and in real we use DER (Distinguished Encoding Rules) encoded life [30, 21]. Our solution uses DKM on data center object identifiers. servers to protect session states. Thus, any server that To provide secure and flexible cryptographic algo- belongs to the DKM group associated with the service rithm support, DKM is parameterized by a whitelist can authenticate, encrypt, and decrypt the state, while of cryptographic algorithms that meet target security any client (presumably not member of the group) are properties. The algorithm list can be adapted in future unable to read or modifiy it. This approach has been implementations to allow new or custom algorithms. successfully implemented in a large hosted services DKM Construction. Let es = (Kges, Kdes, Ences, offering and contributed to better server utilization. Deces) represent an authenticated encryption scheme that consists of a key generator Kges, a key derivation function Kdes, and authenticated encryption and decryp- III. Cryptographic Agility tion algorithms Ences and Deces. The algorithms Ences and Deces provide authenticated We define cryptographic agility as the capability to encryption. We use the term authentication method securely use different sets of algorithms with the same to describe a particular construction DKM supports: keys. Securing persisted data highlights the need for Encrypt-then-Mac, Mac-Then-Encrypt, or an authenti- agility, as the data may outlive the actual security of cated encryption mode AES-GCM. While we prefer the any cryptographic algorithms and keys. Cryptographic less frequently fielded AES-GCM as an authenticated agility in DKM keeps the long-term key secure even encryption algorithm, the CBC and HMAC based meth- if one or more of the algorithms that used the key ods are necessary to attain a much larger deployment are compromised: a critical property we implement and base. The scheme is parameterized by a cryptographic formally verify. Our constructions are based on those policy p that determines the method to use and its 5 algorithms: either an authenticated encryption algorithm to configure the cryptographic policy and update the Eae, or a block cipher in CBC mode composed with key as needed. The Protect operation unambiguously HMAC, using two algorithms E and H. Additionally, encodes the cryptographic policy and the key identi- the cryptographic policy indicates which hash algorithm fier in the ciphertext. We use DER-encoded OIDs to Hd to use with the key derivation function. represent algorithms and Guid to represent the key The key derivation function KDF uses a pseudo- identifier in the encoded ciphertext blob. The Unprotect random function in a prescribed construction [22]. In operation first decodes and validates the algorithms this implementation, KDF is the SP800-108 KDF in and parameters from the ciphertext, then fetches the counter mode [12] and the pseudo-random function is authenticated-decryption key from the repository. This an HMAC, specified as algorithm Hd in the policy and decoded policy may differ from the latest policy stored keyed with a group key k. in the repository. Section VII-A describes a problem We write k for a DKM key generated as k = with agile encoding found by this verification effort. Kges(Lk), where Lk indicates the length of k and is Crypto-Agile DKM. With these necessary building a function of the policy: blocks, we present the DKM functions for authenticated ( encryption (called Protect) and decryption (called Un- max(|Hd|, |Eae|) when using Eae Lk = protect): max(|H |, |E|, |H|) when using E and H d • Protect. If the user has at least read access to the (1) DKM group, the current group key k and policy
When using Eae, we write kes = kae for the authenti- p are read from the repository. An Les bits long cated encryption key. When using E and H, we write ke authenticated encryption key kes is derived from and km for the encryption and MAC keys, respectively, the key k. Figure 3 gives the encryption steps and let kes = ke|km be their concatenation. The to produce C. Finally, the formatted ciphertext is authenticated encryption key length Les is a function given by the equation of the policy: blob = V |hpi|Gk|R|IV |LH |LC |C (4) ( |Eae| when using Eae where | is concatenation, V is a 32-bit version Les = (2) |E| + |H| when using E and H number, hpi = Mes|hHdi|Ies is the unambiguously encoded policy, hHdi is the key-derivation PRF The key derivation function KDF yields a key kes algorithm identifier, Gk is the 128-bit DKM key of length Les identifier, R is the random nonce, IV is the ini-
kes = KDF (Hd,Les, k, R, Mes|Ies) (3) tialization vector for encryption, LH is the MAC length, and LC is the length of |C| in Figure 3. where k is the DKM key, R is a fresh random nonce, The values Gk, R, and IV are DER-encoded to Mes is the authentication method, and Ies is an un- allow variable lengths. ambiguous DER encoding of the algorithm identifiers • Unprotect. The protected blob is parsed as blob in the policy: Ies is either hEaei or hEi|hHi. (We (Equation (4)) and validated: in addition to var- will show the motivation for including Mes in the key ious length and buffer overflow length checks derivation.) that include LH and LC , the algorithms Hd, E, Achieving Agility. To achieve cryptographic agility, the and H are validated against the list of accepted finite set of algorithms must “fit together”, a notion algorithms. The G, R, and IV lengths are also formally introduced in [1]. One example of a condition validated: |IV | must match the blocksize of E, “fitting together” is that the encryption scheme es must and |R| must match |Hd|. The decoded policy may have a unique encoding. We “fit together” our scheme differ from the current policy (e.g. when unpro- with a small set of authenticated encryption algorithms tecting an old ciphertext) and is a priori untrusted. chosen from an agile set and a fixed PRF (Pseudo Only after a successful validation, the decryption is Random Function) constructed from HMAC with SHA- carried out and the decrypted message is returned if 256 and SHA-512. Since there are more authenticated the MAC verifies. The key identifier Gk is used to encryption algorithms than PRFs in practice, this is not fetch the DKM group key k from the repository. a severe restriction. If a key is found, it is fed to the key derivation Agile Encoding. How do we represent the set of and decryption algorithms to calculate the plaintext algorithms and parameters in an agile implementation? message M and return it to the user. To provide cryptographic agility at encryption time, our Security Challenge. There are two main paths to verify implementation relies on a cryptographic policy and a as regards cryptographic agility: encryption and decryp- key stored in the repository. This allows an administrator tion. The encryption uses algorithms in the policy and Policy p Derivation from key k and R Operations 6
EncryptThenMAC(Hd ,E,H) ke|km = KDF (Hd ,Les, k, R, Mes|Ies) Ce = E(ke,IV, text) mac = H(km,IV |Ce) C = Ce|mac MACThenEncrypt(Hd ,E,H) ke|km = KDF (Hd ,Les, k, R, Mes|Ies) mac = H(km, text) C = E(ke,IV, text|mac) GCM(Hd ,Eae) kae = KDF (Hd ,Les, k, R, Mes|Ies) C = Eae(kae,IV, text) Fig. 3. DKM key derivations and encryption methods.
must derive a new kes with KDF from k, a fresh R, and For each group, they control whether a user can read Ies. At decryption time, Ies and R are decoded from and write keys and policies, or manage other users, as the ciphertext. In both cases, Ies is compared against detailed below. known set of algorithms (the white list) to prevent 1)N O ACCESS. This is the default for all users. an insecure algorithm from being used. Verification 2)R EAD ONLY. Users with read-only access to the must thus account for algorithmic choices. To this end, DKM group in the repository can read its cryptog- our formal model defines two logical predicates on raphy policy and its keys; thus, they can use DKM policies, Authentic(p) and Confidential(p), that explicitly both for reading (unprotect) and writing (protect) state sufficient security conditions on their algorithms group data. (within our symbolic model) to ensure authenticity and 3)R EAD/WRITE. Users that also have write access confidentiality, respectively, for any data protected with to the group can additionally update the crypto- a correctly generated group key that remains secret. graphic policy, create new keys, delete existing (The next sections also deals with key compromises.) keys, and delete the group. For example, paraphrasing its logical definition, the 4)O WNER. Users that own a DKM group (also predicate Authentic(p) says that, in policy p, Hd is a known as group administrators) have full access pseudo-random function; and, if p selects authenti- to the group. They can additionally change user cated encryption, then Eae is a secure authenticated access levels. encryption algorithm, otherwise, H is a hash function DKM also provides an interface for managing keys resistant to existential forgery chosen-message-attack and policies. For policies, for instance, a user may read and, moreover, if p selects Encrypt-then-MAC, then E and write a DKM group policy using calls of the form is at least functionally correct (that is, it correctly de- crypts any correctly-encrypted message, to prevent data policy := ReadPolicy(group) corruption after authentication). We refer to Section A WritePolicy(group, policy) for additional modelling details. In addition, after any successful call to Unprotect, a user can read the policy that is part of the blob and used IV. Security for unprotecting it. We call this policy the unprotect policy. As explained below, the user can inspect this We give a precise but informal descriptions of our ver- policy to obtain finer authentication guarantees in case ified security properties and attacker model for DKM. weak algorithms may have been used. The formal counterpart is discussed in Section A. Adversary Model. We now define our active adver- Goals and Non-goals. DKM provides data integrity, saries for DKM, to reflect our threat model for the data secrecy, and authentication for the group name purpose of verification. Our adversaries can: and the key policy. On the other hand, DKM does not • Read and write any protected blob. (We assume attempt to protect privacy information associated with that a protected blob is stored in untrusted media group membership or policies, or with traffic analysis accessible by adversaries.) (e.g. the number and size of encrypted blobs). • Perform arbitrary computations using our (sym- Our verification effort concerns only security prop- bolic) cryptographic interface. Unprotect erties. For instance, we do not verify that • Control users, asking them to protect plaintexts of always succeeds on the output of Protect when both their choice, to unprotect blobs of its choice, to users have access to the group (although we believe create new groups, to manage groups, etc; to renew that our model could be extended accordingly). a key; or to change a policy. Access Levels. DKM distinguishes four access levels • Corrupt users, thereby gaining their repository ac- and provides an interface to manipulate them. These cess and their capabilities (that is, depending on levels are enforced by the repository implementation. group membership, read any group key, or even 7 inject arbitrary values for group keys and policies secret; or (b) the current group policy does not have the into the repository). “Confidential” property; or (c) there is a corrupted user In our model, “control” accounts for the unknown who had read access to that group, or (d) there is a user behavior of the service built on top of DKM. In the who had read access to that group that leaks plaintexts. properties below, if the adversary asks a user to pro- Example. Our property statements cover partial- com- tect some text, this is formally recorded as a genuine promise scenarios with dynamic group memberships plaintext for the group. In contrast, conversely, “corrupt” and policies. As a simple common case for illustrating accounts for the potential partial compromise of the our results, consider a group whose owner uses the group users. If the adversary directly reads a key and default policy and remains the single user. Our security runs the protect algorithm on some plaintext on its own, guarantees boil down to: Unless the owner is compro- then the resulting blob is treated as a forgery. mised, any unprotected value is a previously-protected Conversely, our adversaries cannot: value, and their secrecy is preserved. • Corrupt the repository: they have to comply with Limitations (Modeling). We do not capture some tem- its access control policy. We thus entirely trust the poral properties of access control: our properties are repository and its secure channel facilities. conservatively stated in terms of users having access • Introduce their own broken crypto primitives— in the past, so for example they do not state sufficient however, our model features a fixed collection of conditions to render a group secure again once corrupt “broken” primitives to formally let the adversary users have been expelled and new keys generated. We build insecure policies. do not model group deletion, and may not entirely account for group creation—in our model, whoever first Authentication. We now express the precise logical creates a group owns that group. Thus, we differentiate authentication guarantee we verified on DKM. (This between initial deployment and run-time operations and guarantee can be simplified by making additional as- focus on run-time aspects. However, we observe that sumptions, for instance by excluding the compromise of the creation of a DKM group requires write access to any group member, or assuming that all cryptographic the DKM container in the repository, which in practice algorithms are secure, to obtain corollaries of our main is typically restricted to a small set of trusted network verification results.) administrators. For any run of DKM with any number of users and groups, and for any adversary, if a user a successfully unprotects a blob for a given group, then we have all V. Modular Software Architecture the properties below. Next, we outline the structure of the DKM implemen- 1) user a had read access to the group; tation, with a selection of details relevant for the rest 2) the unprotect policy uses algorithms in the DKM of the paper. Our production code is written in C# whitelist; and distributed as a single DLL deployed with user 3) one of the following holds: either (a) the resulting applications. It was coded partly before our verification plaintext was protected by a user who had read effort—we have released 5 minor revisions of DKM so access to the group, using this unprotect policy; far. or (b) a corrupted user had read access to the Figure 4 describes the modular structure of DKM as group; or (c) the unprotect policy does not have a UML class diagram. The API consists of a single the “Authentic” property. public interface, named IDKM. DKM also uses internal The “Authentic” property is defined from the security interfaces, such as IRepository and IAuthEncrypt, and assumptions on the three security algorithms in the internal classes, such as KeyPolicy and Key. It relies on policy. Moreover, if a user a successfully protects a system libraries for all cryptographic algorithms [25] plaintext for a given group, then we have (omitted in the figure). 1) user a had read access to the group. IDKM. The two main methods of the DKM API, 2) the protect policy use algorithms in the DKM outlined in Section II, are declared as follows: whitelist; 3) either the protect policy and key k have been public interface IDKM { (...) proposed and correctly generated by a user who MemoryStream Protect(MemoryStream plaintext); had write access to the group, or there is a MemoryStream Unprotect(MemoryStream ciphertext); corrupted user who had write access to the group. KeyPolicy DecodedPolicy { get; }} Secrecy. If a user protects a plaintext for a given group, To access data, the user first creates an instance of DKM then one of the following holds: (a) the plaintext remains for a given group name. To store sensitive data, the 8
Fig. 4. DKM main interfaces (in green) and classes (in blue) user writes to a plaintext stream, calls Protect to obtain IRepository, based respectively on Microsoft Active Di- a protected ciphertext stream, and then directs this rectory, on Microsoft SQL Server, on NTFS/SMB, and stream to untrusted storage. (Streams are the primary on a simple in-memory database. All implementations I/O mechanisms in the .NET framework; they generalize rely on the current user’s credentials for authentication the C++ ios class. The MemoryStream used in DKM and authorization purposes. For verification, we model is just a stream implemented over memory buffers.) only the in-memory repository, as we are mostly inter- Conversely, to retrieve data, the user opens a ciphertext ested in the sequences of calls through the repository stream from untrusted storage, calls Unprotect to obtain interface, rather than its implementation details. a plaintext stream, then reads data from it. In addition, IAuthEncrypt. The IAuthEncrypt interface encapsu- the user can read the DecodedPolicy property to review lates crypto-agile authenticated encryption and its state, the policy last used for unprotecting data. We omit which consists of the the policy to use, the random a description of the other methods and properties of nonce, an IV for encryption, and the derived keys. IDKM listed in the figure, which support group, policy, Three subclasses, named EncryptMAC, MACEncrypt, and key management, as well as data migration (an and GCM (one for each authentication method) provide unprotect followed by a protect with the current group different implementations of the methods Authenticat- key and policy). edEncrypt, and AuthenticatedDecrypt but share code IRepository. The IRepository interface decouples the for key derivation (DeriveKey) and for parsing and choice of a particular trusted repository from the rest formatting the protected blobs (Decode and Encode). of DKM. It has methods for accessing a secure con- Cryptographic Algorithms and Materials. The tainer associated with each group name. The container Crypto class provides all primitive cryptographic op- maintains a small amount of trusted data for the group: erations. such as block encryption and decryption and an access control list for its users, its current protect random generation. In addition, DKM defines a few policy, and a set of keys. (Keys used with earlier protect auxiliary classes: policies are usually retained to enable unprotection of • AlgorithmIdentifier objects uniquely identify algo- old data.) rithms, using the AlgorithmOid constants. In addition, an internal MemoryKeyCache class pro- • Key objects encapsulate cryptographic keys; their vides a per-process in-memory cache for keys retrieved KeyValue property yields their (otherwise in- from the repository. These cached keys are kept en- memory encrypted) key bytes; auxiliary properties crypted using a per-process ephemeral key the Windows record the key identifier and its intended algorithm. OS provides. The cache is consulted first on each key • KeyPolicy objects state a particular choice of au- read request, and is cleared before the process exits. thentication method, of cryptographic algorithms DKM currently supports four implementations of (for key derivation, encryption, and authentication) 9 and of key identifier. let k = checkKeyLength p k0 AuthEncDeriveKeys ae k Var.set dkm.DecodedPolicy p VI. Functional Implementation AuthenticatedDecrypt ae cipher plain
Our verified reference-implementation code takes ad- #if F7 vantage of the modular structure of DKM and of the #else type public DKMFsharp (repository:IRepository, fine-grain integration between C# and F# within the keyCache:IKeyCache, .NET platform. Thus, our two implementations can call authEncrypt:IAuthEncrypt) = one another and share interfaces, classes, and objects. let user = WindowsIdentity.GetCurrent().User.ToString() We do not implement primitive cryptographic oper- let dkm = CreateDkm user repository.GroupName ations in F#; instead, we just call their C# implemen- (...) IDKM tations from F# and reflect their properties using type interface with member r.GroupName with get() = dkm.GroupName annotations and logical refinement at their interface. We member r.Unprotect(cipher:MemoryStream) = end up with a hybrid C#—F# code base, with two let plainText = new MemoryStream() implementations for the main classes and interfaces, DkmUnprotect user dkm cipherText plainText and the ability to build executable code by selecting plainText implementations for each of the three main interfaces. (...) #endif The main purpose of the F# code is to bridge the gap between an imperative implementation and a functional As explained in Section III, DkmUnprotect first model. Hence, our F# implementation avoids mutable parses the blob and decodes the unprotect policy (p). fields and object oriented-features, whenever possible: This may fail, for instance if the policy proposes algo- some C# objects are coded as F# records, C# properties rithms outside the set supported by DKM. Otherwise, are coded as F# fields, and some data representations this returns an initialized instance (ae) of IAuthEncrypt. are simplified. Each F# implementation file is structured The code then reads the key (k0) referenced in the in two parts: (1) mostly-functional code, in the subset policy from the repository, checks that this key is of F# verifiable by the F7 typechecker, followed by appropriate for use with p, and finally performs authen- (2) a small object-oriented stub that implements the ticated decryption on ae (listed below). The stub for target C# interface, with implementation methods that IAuthEncrypt implements the method IDKM.Unprotect; mostly call plain F# functions. (These stubs are used, for it creates the plaintext stream then just calls DkmUnpro- instance, to leverage the existing test suites developed tect. for the C# implementation.) Next, we give selected Authenticated Encryption. Module AuthEncModel F# implementation details for the three main DKM implements crypto-agile protection depending on interfaces. Section A provides the corresponding F7 a given policy p and its fields: p.AuthEncMethod, declarations verified by typing. p.KdfMacAlgorithm, p.MacAlgorithm, and DKM. This module re-implements the core logic of p.EncryptionAlgorithm. We give the code of the the DKM base class. It uses a record to store the two main functions for encryption and decryption, group name and the last unprotect policy (instead of as described in Figure 3. These functions operate C# properties). It also turns the (implicit) authenticated on byte arrays and are parameterized by policy (p), user identity into an explicit parameter, so that it can random nonce (r), encryption IV (iv), and group be used in specification events. We give an outline of key (k); they each have three branches, depending the whole F# implementation, showing code only for on the authentication method. Decryption is also Unprotect. As explained above, part (1), above the #if parameterized by the expected lengths for ciphertext F7 conditional-compilation flag, is formally verified by and mac, previously obtained when parsing the typing; and part (2) is a stub implementing IDKM by ciphertext. This code is verified by typing, as explained calling part (1). in Section A. module DKM let authenticatedEncrypt p r iv k plaintext = (...) let ke,kh = deriveKeys p r k type Dkm = { GroupName: string; match AuthEncMethod p with DecodedPolicy : KeyPolicy Var.t } | AuthEncryptCM → let DkmUnprotect (user:principal)(dkm:Dkm) cipher plain = encrypt p.EncryptionAlgorithm iv ke plaintext let n = dkm.GroupName | EncryptThenMac → let ae = DkmDecodeProtectedBlob cipher let e = encrypt p.EncryptionAlgorithm iv ke plaintext let p = Var.get ae.Policy let v = concat iv e let keyId = KeyPolicyGetCurrentKeyGuid p assert(IsEncryptThenMac(v,k,p,r,plaintext,ke,iv,e)) let k0 = ReadKey user n keyId let m = mac p.MacAlgorithm kh v 10 concat e m • Acls implements an abstraction of access control | MacThenEncrypt → list to represent access rights; let m = mac p.MacAlgorithm kh plaintext // but not iv • Db implements an abstraction of an in-memory let v = concat plaintext m assert(IsMacThenEncrypt(v,k,p,r,plaintext,kh,m)) database; encrypt p.EncryptionAlgorithm iv ke v • Var implements a write-once variable (see Section A); let authenticatedDecrypt p r iv k ciphertext ctLn macLn = • KeyPolicyModel implements key policies as let ke,kh = deriveKeys p r k records, rather than objects. match AuthEncMethod p with | AuthEncryptCM → • CryptoModel provides functional wrappers around let pt = decrypt p.EncryptionAlgorithm iv ke .NET cryptographic primitives, and is the basis of ciphertext their formal model. pt | MacThenEncrypt → Testing. We validate our F# code by writing tests, let d = decrypt p.EncryptionAlgorithm iv ke both in F# and in C#. These tests cover a number of ciphertext DKM scenarios as well as interoperability between the let pt,ptm = split d (ctLn−macLn) macLn macVerify p.MacAlgorithm kh pt ptm two implementations. In addition to C# manual code pt reviews, this gives us high confidence that our verified | EncryptThenMac → code closely corresponds to our production code, and let ct,ctm = split ciphertext (ctLn−macLn) macLn also enables us to automatically detect any discrepancy let v = concat iv ct that may appear as the result of code changes. (So far macVerify p.MacAlgorithm kh v ctm let pt = decrypt p.EncryptionAlgorithm iv ke ct 9 minor revisions of the C# DLL have been released.) pt The C# tests make sure that the F# code interoperates with the C# code. To this end, we wrote a simple In-Memory Repository. Module RepositoryModel pro- in-memory repository also in C#, and ported the 28 vides a simple implementation of the IRepository in- existing C# tests. Those tests exercise scenarios such terface. We represent the persisted state of each DKM as initializing IDKM and IRepository implementations, group as a tuple consisting of the group name, a mutable adding groups to a repository, adding users to these list of key policies, an in-memory database of keys groups, and protecting and unprotecting various series indexed by key identifiers (Guid), and an in-memory of data. database of access rights indexed by user names. Their The F# tests take the existing 28 tests for the C# in- F# type is memory repository, and replace instances of C# DKM type StoredGroup = components with their F# counterparts. Additionally, we groupname ∗ also test using the C# IDKM implementation configured KeyPolicy list ref ∗ to use the F# in memory repository, to make sure that Db.t
Fig. 5. Lines of code in C#, F#, and F7, and verification time. itf is interface, impl is implementation.
Although this kind of logical attack is trivial to fix software. The default policy uses Encrypt-then-MAC. once identified, it is unlikely to be found by undi- So, we inquired with the early users of DKM to make rected testing. On the other hand, models written for sure that none of them changed the default Mes setting traditional formal analyses may miss implementation in their DKM configuration. Thus, an empty, but still details such as local key caches, and thus also miss this unambiguous encoding lets us be backward compatible attack. Our verification method involves systematically with all protected blobs in deployed environments, building (and checking) a correspondence between the while protecting new deployments with a modified production code and the model. Thus, it is well adapted mechanism. In practice, we do not foresee a default to detect this kind of logical attack. mechanism anything other than Encrypt-then-MAC or AES-GCM. Implicit Authentication of the Authentication Method. Our verification effort discovered a construc- Setting Key Lengths & Policy updates. We also identi- tion problem in the input of the key derivation func- fied several inconsistencies in the choice of appropriate tion. When using CBC encryption and MAC, the key key lengths for the various algorithms, to ensure that derivation algorithm KDF did not differentiate between each key has enough entropy for all algorithms it is used the encrypt-then-MAC and MAC-then-encrypt authen- for. To compute the length of the DKM key k defined tication methods, violating the unambiguous encoding in Section III, we initially included the encryption E promise stated in Section III. In other words, the algo- and MAC algorithm H key lengths but not the PRF rithms but not the method were included as parameters |Hd| key length in the key derivation function. Also, for key derivation, allowing the adversary to change this we did not systematically re-compute and re-check that method and cause the same keys to be shared between key length when using the DKM key with a decoded different methods using the same algorithms. For ex- policy, so that a key allocated for a given policy could ample, an adversary would have been able to inject be used (in principle) for another policy, even if the blobs (apparently) protected with MAC-then-encrypt later policy would mandate a longer key. Formally, and, assuming it could break this method, recover these discrepancies yield typechecking errors on the their keys and then also unprotect blobs protected with refinements of the key values. We fixed these issues encrypt-then-MAC. In contrast, our formal model re- before DKM was integrated into a product. quires resistance against chosen-ciphertext attacks only Cryptographic Policy in Unprotect. The DKM unpro- when the method is MAC-then-encrypt, which is fine as tect operation does not consult the policy in the repos- long as DKM uses separate keys for blobs (apparently) itory. Instead, DKM parses out the effective unprotect encrypted with distinct methods. We caught this vulner- policy from an protected blob, giving the adversary var- ability using our new model for cryptographic agility. ious knobs to play with. Assuming that parsing is done To remove the vulnerability, we redefined the input properly, we discovered that not all key lengths were of KDF to include the method Mes as well as its algo- verified against the decoded policy. In particular, the rithms Ies (see Equation (3) in Section III). We let Mes length of the DKM key k was not checked against the be 1 for GCM (encoded in one byte), 2 for MAC-then- authenticated encryption and key derivation algorithms encrypt (encoded in one byte), and the empty bytestring despite the checks to make sure that the derived key for Encrypt-then-MAC. One might ask why we use this were of proper lengths. ad hoc encoding instead of 3. There is a very practical The fix was straightforward: every DKM unprotect issue at work: backward compatibility with deployed operation checked that the DKM key k was at least 13 as long as the key length Lk computed from the [3] M. Bellare. New proofs for NMAC and HMAC: Security key derivation and authenticated encryption algorithms without collision-resistance. In CRYPTO 2006, volume in (1). 4117 of LNCS, pages 602–619. Springer, Berlin, Ger- many, Aug. 20–24, 2006. [4] M. Bellare, R. Canetti, and H. Krawczyk. Keying hash B. Limitations of F7 functions for message authentication. In N. Koblitz, editor, CRYPTO’96, volume 1109 of LNCS, pages 1–15, Our case study also reveals limitations of the verifi- Santa Barbara, CA, USA, Aug. 18–22, 1996. Springer, cation tools we used. Although F7 can handle complex Berlin, Germany. logical models at the level of details of production code, [5] J. Bengtson, K. Bhargavan, C. Fournet, A. D. Gordon, it lacks support for many imperative and object-oriented and S. Maffeis. Refinement types for secure implementa- tions. Technical Report MSR–TR–2008–118, Microsoft programming patterns. In principle, our model could be Research, 2008. A preliminary, abridged version appears checked directly against the C# codebase, but this would in the proceedings of CSF’08. involve engineering beyond the scope of our case study. [6] K. Bhargavan, C. Fournet, and A. D. Gordon. A Our verification effort also stress the need for better semantics for web services authentication. In ACM error messages for logical debugging and for a local Symposium on Principles of Programming Languages (POPL’04), pages 198–209, 2004. An extended version refinement-type inference while developing the model. appears as Technical Report MSR–TR–2003–83. In terms of cryptographic verification, our method [7] K. Bhargavan, C. Fournet, R. Corin, and E. Zalinescu. relies on symbolic assumptions on the underlying prim- Cryptographically verified implementations for TLS. In itives. In future work, it would be revealing to formally ACM Conference on Computer and Communications validate these assumptions against more concrete cryp- Security, pages 459–468, Alexandria, VA, USA, 2008. ACM Press. tographic hypotheses, such as those for agility [1]. [8] K. Bhargavan, C. Fournet, and A. D. Gordon. F7: refinement types for F#, Sept. 2008. Available from C. Conclusions http://research.microsoft.com/F7/. [9] K. Bhargavan, C. Fournet, A. D. Gordon, and N. Swamy. In modern distributed systems persisted data requires Verified implementations of the Information Card fed- flexible key management and cryptographically agile erated identity-management protocol. In Proceedings policies to achieve long-term security and availability. of the ACM Symposium on Information, Computer and This need is not only theoretical; it is identified in Communications Security (ASIACCS’08), pages 123– 135, Tokyo, Japan, 2008. ACM Press. numerous actual software products and forms a basis [10] K. Bhargavan, C. Fournet, and A. D. Gordon. Modular for our effort. As a response, we design, implement, and verification of security protocol code by typing. In ACM verify DKM, a new security component that solves this Symposium on Principles of Programming Languages problem and keeps cryptographic complexity behind a (POPL’10), Jan. 2010. simple, high-level API for services that require data [11] S. Chaki and A. Datta. ASPIER: An automated frame- work for verifying security protocol implementations. protection. In IEEE Computer Security Foundations Symposium, As part of the development cycle of this new security pages 172–185, Port Jefferson, NY, USA, 2009. IEEE component we build, verify, and maintain a reference Computer Society. implementation. This yields security guarantees beyond [12] L. Chen. NIST Special Publication 800-108: Rec- those obtainable by independent verification efforts on ommendation for Key Derivation Using Pseudorandom Functions. Information Technology Laboratory, National simplified formal models. In our experience with DKM, Institute of Standards and Technology, Gaithersburg, MD this approach significantly improved our design and 20899-8900, Oct. 2009. understanding, and helped us identify and fix several [13] L. de Moura and N. Bjørner. Z3: An efficient SMT vulnerabilities early in its development cycle, avoiding solver. In Tools and Algorithms for the Construction costly post-deployment updates. Taking advantage of and Analysis of Systems (TACAS’08), volume 4963 of LNCS, pages 337–340. Springer, 2008. recent advances in automated tools for cryptography, [14] A. Dey and S. Weis. KeyCzar: A Cryptographic Toolkit. this was achieved at a reasonable cost: a 15% overhead Google, Inc., Aug. 2008. http://keyczar.googlecode.com/ in code size including new verification libraries. files/keyczar05b.pdf. [15] T. Dierks and E. Rescorla. RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2. IETF, Aug. References 2008. http://www.ietf.org/rfc/rfc5246.txt. [16] D. Dolev and A. Yao. On the security of public key [1] T. Acar, M. Belenkiy, M. Bellare, and D. Cash. Cryp- protocols. IEEE Transactions on Information Theory, tographic agility and its relation to circular encryption. IT–29(2):198–208, 1983. In EUROCRYPT 2010, LNCS, pages 403–422. Springer, [17] W. Ehrsam, C. Meyer, R. Powers, J. Smith, and W. Tuch- Berlin, Germany, May 2010. man. Product Block Cipher System for Data Security. [2] T. Acar, M. Belenkiy, L. Nguyen, and C. Ellison. Key International Business Machines, Feb. 1975. management in distributed systems. Technical Report [18] J. Goubault-Larrecq and F. Parrennes. Cryptographic MSR–TR–2010–78, Microsoft Research, June 2010. 14 protocol analysis on real C code. In VMCAI’05, pages ses on the interface of the cryptographic-algorithm 363–379, 2005. libraries. In the absence of formal security proofs on [19] D. Harkins and D. Carrel. RFC 2409, The Internet Key the concrete design and implementation of the core Exchange (IKE). IETF, Nov. 1998. http://www.ietf.org/ rfc/rfc2409.txt. primitives, we rely instead on dual, non-standard im- [20] RFC 4306, The Internet Key Exchange (IKEv2). IETF, plementation of these libraries, which embody the target Dec. 2005. http://www.ietf.org/rfc/rfc4306.txt. security properties in some more abstract programming [21] J.Rizzo and T.Duong. Practical padding oracle attacks. model, as initially proposed by Dolev and Yao [16]. In Black Hat Europe, Barcelona, Spain, Apr. 2010. Hence, we obtain theorems about the security of pro- [22] H. Krawczyk. Cryptographic extraction and key derivation: The HKDF scheme. In T. Rabin, editor, tocol implementations linked against symbolic crypto- CRYPTO 2010, volume 6223 of LNCS, pages 631–648, graphic libraries, against all adversaries with access to Santa Barbara, CA, USA, Aug. 15–19, 2010. Springer, selected protocol and library interfaces, and we can Berlin, Germany. independently review whether those symbolic libraries [23] D. A. McGrew and J. Viega. The security and per- adequately reflect the strengths and known weaknesses formance of the Galois/counter mode (GCM) of op- eration. In A. Canteaut and K. Viswanathan, editors, of the underlying cryptography. We refer to Bengtson INDOCRYPT 2004, volume 3348 of LNCS, pages 343– et al. [5] and Bhargavan et al. [10] for a detailed descrip- 355, Chennai, India, Dec. 20–22, 2004. Springer, Berlin, tion and security analysis of two large cryptographic Germany. libraries using F# and F7. Section A also illustrates [24] Cryptography. Microsoft, Mar. 2010. http://msdn. our approach on the interface for keyed cryptographic microsoft.com/en-us/library/aa380255(VS.85).aspx. [25] Cryptography API: Next Generation. Microsoft, hashes. Mar. 2010. http://msdn.microsoft.com/en-us/library/ Refinement Typechecking. Our main verification tool aa376210(VS.85).aspx. is F7, a refinement type checker developed for the Windows Data [26] NAI Labs, Network Associates, Inc. purpose of verifying protocol implementations [5]. F7 Protection. Microsoft, Oct. 2001. http://msdn.microsoft. com/en-us/library/ms995355.aspx. supplements F# with much-richer types carrying first- [27] PKCS#11 v2.30: Cryptographic Token Interface Stan- order-logic formulas that can specify properties of the dard. RSA Laboratories, Apr. 2009. http://www.rsa. values that have those types. These formulas are verified com/rsalabs/node.asp?id=2133. during type-checking, by calling an automated theorem [28] K. Scarfone, M. Souppaya, and M. Sexton. NIST Special Publication 800-111: Guide to Storage Encryp- prover. (In our case, we rely on Z3, an SMT solver.) tion Technologies for End User Devices. Information After typechecking, these formulas are erased, and we Technology Laboratory, National Institute of Standards are left with ordinary F# programs with plain .NET and Technology, Gaithersburg, MD 20899-8900, Nov. types. 2007. [29] T.Ylonen and C.Lonvick. RFC 4251, The Secure Shell Sample Refinements. For example, let ‘bytes’ be the (SSH) Protocol Architecture. IETF, Jan. 2006. http:// type of byte arrays (byte[] in C#) and suppose we www.ietf.org/rfc/rfc4251.txt. use bytes to represent cryptographic key values. For [30] S. Vaudenay. Security flaws induced by CBC padding verification purposes, instead of bytes, we may use a - applications to SSL, IPSEC, WTLS ... In L. R. more precise refined type for keys, declared in F7 as Knudsen, editor, EUROCRYPT 2002, volume 2332 of LNCS, pages 534–546, Amsterdam, The Netherlands, type key = b:bytes { Length(b) = 32 ∧ SymmetricKey(b) Apr. 28 – May 2, 2002. Springer, Berlin, Germany. } [31] X. Wang and H. Yu. How to break MD5 and other hash functions. In R. Cramer, editor, EUROCRYPT 2005, This type is inhabited by values b of type ‘bytes’, volume 3494 of LNCS, pages 19–35, Aarhus, Denmark, its base type at runtime, that also meet the logical May 22–26, 2005. Springer, Berlin, Germany. refinement specified by the formula between braces. [32] X. Wang, Y. L. Yin, and H. Yu. Finding collisions in the Hence, keys are bytes such that two facts hold: (1) full SHA-1. In V. Shoup, editor, CRYPTO 2005, volume 3621 of LNCS, pages 17–36, Santa Barbara, CA, USA, the byte array has length 32, and (2) the predicate Aug. 14–18, 2005. Springer, Berlin, Germany. ‘SymmetricKey(b)’ holds, which, in our model, may indicate that the key was correctly generated by a particular algorithm. Appendix Suppose our encryption function takes a formal key parameter with type ‘key’, rather than just ‘bytes’. Then, We first review our method for verifying the security typechecking an encryption involves proving that these of code written in F#, relying on logical models type- two facts hold for the actual key passed as an argument. checked by F7. Section A explains how we apply this (Refinement formulas on arguments act as logical pre- method to DKM. conditions.) Moreover, if the key generation function Symbolic Cryptography. Formal verification relies on is the only function with a result type refined with a series of security assumptions, expressed as hypothe- the fact ‘SymmetricKey(b)’, then typechecking prevents 15 any other bytes from being treated as keys, and thus For instance, a new F7 module ‘Var’ provides a sim- well-typed programs use only correctly-generated keys ple abstraction to keep track of the values of variables for encryption. (Refinement formulas on results act as and fields that are mutable (as usual in C#) but should be logical post-conditions.) written at most once during the lifetime of the object Programs typechecked with F7 can use two special (as often in DKM code, for instance for each of the specification statements: private fields of AuthEncrypt for keys, IV, etc, which • The statement ‘assert C’ asks the typechecker to are gradually filled as the blob is processed). A variable verify that formula C holds in the current context, r of type Var.t can be written at most once and read that is, can be deduced from the current typing any number of times; both operations are typed in F7 environment. Otherwise, typechecking fails. with a logical postcondition Val(r,v) stating that v is the • Conversely, ‘assume C’ tells the typechecker that current value stored in r. Writing a second time to a formula C holds. For instance, we may use a variable triggers a run-time error (detected by testing). statement ‘assumeSymmetricKey(b)’ within the im- As a benefit, ‘Var’ can includes an F7 assumption plementation of our key-generation function, to stating that this type of variable stores at most one promote 32 freshly-generated random bytes and value (logically, !r,v,v’. Val(r,v)∧ Val(r,v’)⇒ v = v’ where give its result the type ‘key’. ! is universal quantification); this assumption is used during typechecking and enables efficient verification These statements have no effect at runtime (since of the code that depends on such variables, essentially all formulas are erased after typechecking) but they as if they were immutable. must be carefully reviewed to understand the logical properties established by typechecking. The main type- Stream-based I/O. As shown in Section V, our C# code safety theorem for F7 states that, whenever a well-typed systematically relies on I/O streams for incrementally program executes an assert C, the formula C logically reading and writing both (authentic, confidential) source follows from the conjunction of all previously-assumed bytes to be protected and (raw, public) blob bytes after formulas. protection. We now outline our verified model, highlighting some For verification, we need to distinguish between read- of its logical properties. The main novelties are (1) ers and writers, and to precisely keep track of logical the handling of imperative programming features; (2) refinements on the stream contents. To this end, we the first symbolic model for cryptographic agility—all decompose the single ‘System.IO.MemoryStream’ type crypto functions are parameterized by their algorithm into several, more precise types in F7, and we introduce and the protocol retains security properties even when functions for casting streams into input-only streams some of those algorithms are broken; and (3) a precise and output-only streams: account of access-control and group management. val newMemoryStream: unit → α Stream We describe verification in three categories: program val read only: α Stream → α InStream verification, cryptographic verification, and API verifi- val write only: α Stream → α OutStream cation. (In F#, all these types are plain memory streams, and we define let read only s = s and let write only s = s .) Input streams can be read, but not written, so they are A. Program Verification contravariant; conversely output streams are covariant. Hence, for example, in a typing context such that we Untrusted functions. Many functions implemented in have a logical implication C ⇒ C0, a stream of type (x C# are irrelevant for the security of DKM. Technically, :bytes{C})InStream can safely be passed as a stream of we verify this by declaring their types in F7 without type (x:bytes{C0}) InStream (since the latter refinement any refinement; typechecking code that uses them under is less demanding on the values read off the stream). those plain types (that is, in particular, without mak- This kind of subtyping on polarized streams is used for ing any assumption on the values returned by those instance to give different, precise types to the content functions); and implementing them in F# using calls of the plaintext stream, as it is passed from DKM to to C#. This approach enables us to safely limit our AuthEncrypt. modeling effort. For instance, the format for encoding policies into protected blobs is irrelevant for security: their model only ensures that encoding and decoding B. Cryptographic Verification functions operate on public bytes. Core Cryptographic Model. We refer to Bhargavan Mutable Objects. Our executable model is more con- et al. [10] for a general description of modeling crypto- crete and imperative than those previously verified with graphic libraries as refined F7 modules. We develop our F7, so we extend its verification libraries accordingly. own libraries to account for cryptographic agility: all 16 primitives take an extra ‘algorithm identifier’ parameter, { (IsMACKey(k) ∨ Pub(k.value)) ∧ k.oid = a } and all symbolic security properties are conditioned → v:bytes → m:bytes → unit { IsMAC(m,k,v) } by special predicates that specify our cryptographic assume !m,k,v. assumptions on these algorithms. (This is illustrated IsMAC(m,k,v) ∧ CMA(k.oid) ⇒ MACSays(k,v) ∨ Pub(k. below for keyed hash functions.) value) Our formal model includes a few sample algorithms In these refinement types, for each kind of cryptographic primitive. In contrast • the preconditions for both functions demand that k with production code, it also deliberately includes one be a MAC key, using the fact IsMACKey(k) whose “broken” algorithm of each kind to accurately reflect algorithm identifier matches the one passed as potential attacks when using poor policies. Formally, we parameter (using the equality k.oid = a). Thus, for do not assume anything about those algorithms. Thus, instance, any erroneous code that may potentially when those algorithms are run, we can pessimistically call macVerify with a key derived for another give full control of their behavior to the adversary: the algorithm would trigger a type error during its adversary receives all their arguments (including the verification. key!) and sends back any bytes to be used as the result • The predicate MACSays logically specifies the of the algorithm. This enable us to verify, for instance, meaning of an “authentic” value for a given key. that plaintexts protected with strong algorithms remain It is a precondition of mac, and a (conditional) secure, even if some other plaintexts within the same postcondition of macVerify. group are (poorly) protected using broken algorithms. • The predicate Pub tracks the knowledge of the type oid = adversary, that is, public and potentially tainted | Aes128CBC (∗ sample encryption algorithm ∗) values. For instance, Pub(v)⇒ Pub(m) in the mac | Aes128GCM (∗ sample authenticated−encryption algorithm ∗) postcondition says that the MAC of m is pub- | WeakEncryption (∗ sample bad encryption algorithm ∗) lic, and can thus be written to untrusted storage, | Sha256 (∗ sample hash algorithm ∗) provided that the MACed value v is also public; | WeakHash (∗ sample bad hash algorithm ∗) otherwise the MAC may leak information on v. | NoAlgo (∗ no algorithm (null in C#) ∗) • The fact CMA(k.oid) records a security assumption type security assumptions = stating that the algorithm with identifier k.oid pro- | PRF of oid (∗ ok for key derivation ∗) tects integrity against chosen-message attacks, that | CPA of oid (∗ ok for encrypting authenticated data ∗) is, even if the adversary can influence the values | CCA of oid (∗ ok for encrypting any data ∗) being MACed. This fact is not a precondition for | CMA of oid (∗ ok for authenticating data (MACs) ∗) calling our two functions, but is required to deduce | CCM of oid (∗ ok for authenticated encryption ∗) MACSays after calling macVerify. We also use different refinements on the raw “bytes” • The fact Pub(k.value) models the potential use of datatype to check the consistency of the algorithms compromised keys. Its use here reflects the pos- used, for instance, for generating keys and IVs versus sibility that the group key has been leaked, or those used later for encryption. provided by the adversary. Sample primitive: authentication. We illustrate our • The predicate IsMAC is the postcondition of a approach for authentication primitives, which have the successful MAC verification; otherwise macVerify following plain types in F#: throws a security exception. The assumption above val mac: oid → Key → bytes → bytes gives it logical meaning. val macVerify: oid → Key → bytes → bytes → unit Thus, following the logical definition of IsMAC, after Both functions take as parameters an algorithm identi- cryptographic verification, we only know that, if the fier a, a key k, and the bytes value v to be authenticated; algorithm is CMA, then either the verified value v is the mac function returns a MAC m, whereas macVerify authentic or the adversary knows the authentication key. takes a MAC as fourth argument, and either returns This logical property will need to be combined with nothing (if verification succeeds) or raises an exception properties of the key derivation to rule out the second (if verification fails). In F7, these two functions are alternative. given the more precise refinement types below: Sample primitive: key derivation. We give below the val mac: a:oid → k:Key → v:bytes type of our key-derivation function, and the definition of { ((IsMACKey(k) ∧ MACSays(k,v)) its first postcondition IsDerivedMACKey. We omit the ∨ (Pub(k.value) ∧ Pub(v)) ) ∧ k.oid = a } → definition of its counterpart for encryption IsDerivedEn- m:bytes { (Pub(v) ⇒ Pub(m)) ∧ IsMAC(m,k,v) } cryptionKey. val macVerify: a:oid → k:Key val deriveKeys: 17 p:KeyPolicy → n:bytes → type StoredGroup = s:Key { s.oid = p.KdfMacAlgorithm } → n: groupname ∗ ke:Key ∗ ka:Key { IsDerivedEncryptionKey(ke,p,n,s) (p:KeyPolicy{GroupPolicy(n,p)}) list ref ∗ ∧ IsDerivedMACKey(ka,p,n,s) } (guid,k:Key{GroupKey(n,k)}) Db.t ∗ (principal, right list) Db.t { ∃o. Created(o,n) } assume !ka,p,n,s. Each entry includes a list of past and present policies; a IsDerivedMACKey(ka,p,n,s) ⇒ ( ka.oid = p.MacAlgorithm list of all keys for the group; and an ACL that records ∧ ( PRF(p.KdfMacAlgorithm) ∧ CMA(p.MacAlgorithm) the access level for each user. We maintain a list of ∧ Pub(ka.value) ⇒ Pub(s.value)) the successive policies that have been stored for the ∧ ( p.AuthEncMethod = MacThenEncrypt ⇒ group, rather than just the current policy, to account for (!x. MACSays(ka,x) ⇔ Protect(s,p,x) )) weak synchronization and the possibility of protecting ∧ ( p.AuthEncMethod = EncryptThenMac ⇒ (!x. MACSays(ka,x) ⇔ a plaintext with an out-of-date policy. (∃plain,ke,iv,e. IsEncryptThenMac(x,s,p,n,plain,ke,iv The refinement formulas in the type StoredGroup ,e))))) above are essential to structure our model: to typecheck Intuitively, the assumed formula defines the specific code that stores a new policy, for instance, one has to logical properties of each kind of keys that may be prove that this policy is a valid policy for that group (this derived from group key s according to policy p. For is tracked by the predicate GroupPolicy). Conversely, example, if we use the MAC-then-encrypt method, then when typechecking code that fetches a policy from the the post-condition of deriveKeys tells us that the key ka repository, we know that this policy was valid at some matches the MAC algorithm in the policy, and that the point in the past. logical meaning of authentication with ka, defined by We give below the logical definitions of the predicates the predicate MACSays, is that the authenticated value that give a formal meaning to the statements “x had a is a DKM plaintext protected using the group key s and access to group n” (with e.g a = Read, or a = Write) policy p, as recorded by the fact Protect(s,p,plain). and “the policy p was valid at some point for group n”. These predicates are recursively defined to keep track of Authenticated Encryptions. The declared types of the delegation chains for group access (from runtime events two main functions for authenticated encryptions are: Created, Granted, and Corrupt) and of the origin of any val authenticatedEncrypt: stored policy (from runtime events Default or Assigned), p:KeyPolicy → respectively. r:bytes → iv:bytes { IsIV(iv,p.EncryptionAlgorithm) } → s:Key { s.oid = p.KdfMacAlgorithm } → assume !x,n,a. HadAccess(x,n,a) ⇔ text:bytes { Protect(s,p,text) } → blob:bytes Created(x,n) ∨ { Pub(iv) ∧ ( Confidential(p) ∨ Pub(text) ⇒ Pub(blob)) } ∃z.( HadAccess(z,n,Owner) ∧ (Granted(z,n,a,x)∨ Corrupt(z ))) val authenticatedDecrypt: p:KeyPolicy → assume !n,p. GroupPolicy(n,p) ⇔ r:pubs → iv:pubs → ∃o. Created(o,n) ∧ k:Key { k.oid = p.KdfMacAlgorithm } → ( Default(p) ∨ blob:pubs → int → int → text:bytes ( ∃z. HadAccess(z,n,Write) ∧ (Assigned(z,n,p)∨ Corrupt(z))) { Authentic(p) ⇒ (Protect(k,p,text) ∨ Pub(k.value)) } ) Their typechecked implementation is given in Sec- Main DKM Interface. Relying on logical definitions tion VI; it has specialized code for each of the three from all refined modules, we arrive at the following possible methods prescribed by the policy p. Notice that types for the two main functions of DKM: the security postconditions depend on the cryptographic properties of the policy: for instance, to deduce that val DkmProtect: id principal → dkm Dkm → the decrypted text is authentic after calling authenti- : : plaintext: catedDecrypt, we need Authentic(p) to hold, a predicate (t:bytes {CanProtect(dkm.GroupName, id, t)}) InStream defined from the security assumptions on the three → security algorithms of p. protectedData: pubs OutStream → unit
val DkmUnprotect: C. API Verification id:principal → dkm:Dkm → ciphertext: pubs InStream → Repository. Our implementation of the IRepository in- plaintext: (t: bytes { ∃p. Var.Val(dkm.DecodedPolicy,p) terface maintains mutable state for each group using ∧ Unprotected(id,dkm.GroupName,p,t) }) OutStream → an in-memory database with entries of the following unit refined type: 18 Instead of just returning a pair of a plaintext and a decoded policy, Unprotect stores the decoded policy in a variable and sends the plaintext bytes on an output stream. Accordingly, the effective postcondition of Unprotect is attached as a refinement of any bytes sent on that stream, with an existential quantifier on the content of the decoded-policy variable. The most precise property verified as a postcondition of Unprotect is defined as follows: assume !x,n,p,t. Unprotected(x,n,p,t) ⇔ ∃k,ae.( Var.Val(ae.Policy,p) ∧ Var.Val(ae.Key,k) ∧ HadAccess(x,n,Read) ∧ GroupKey(n,k) ∧ APP(k,p,t)(∗ needed just as a logic hint ∗) ∧ ( Authentic(p) ⇒ (GroupPolicy(n,p) ∧ ∃y. Protected(y,n,p,t)) ∨ (∃z. HadAccess(z,n,Read) ∧ Corrupt(z)))) where the application-specific predicate CanProtect records data protected in the group. Typechecking these properties involves delicate sub- typing, as the conditions passed from one function to another evolve from properties on users and groups to properties on keys and algorithms. (In the definition, the APP predicate is included as a hint for Z3, our underlying prover; it is logically redundant with the rest of the formula but it helps Z3 instantiate variables in the proof search; its definition is omitted.)