ASSIGNMENT OF BACHELOR’S THESIS

Title: Security analysis of Cryptomator Student: Anton Titkov Supervisor: Ing. Josef Kokeš Study Programme: Informatics Study Branch: Computer Security and Information technology Department: Department of Computer Systems Validity: Until the end of summer semester 2020/21

Instructions

1) Research the field of a disk and file encryption. 2) Study the tool Cryptomator (https://cryptomator.org). Describe its capabilities, compare its features and limitations to other disk or file-encryption software. 3) Analyze the user interface and available documentation of Cryptomator, evaluate these areas for threats. 4) Based on the results from the previous analysis, choose promising application components and analyze their source code for security, with a focus on cryptographic primitives. 5) Verify the documented crypto specifications by reimplementing Cryptomator's key functions using an independent cryptographic library. 6) Discuss the results. References

Will be provided by the supervisor.

prof. Ing. Pavel Tvrdík, CSc. doc. RNDr. Ing. Marcel Jiřina, Ph.D. Head of Department Dean

Prague February 13, 2020

Bachelor’s thesis

Security analysis of Cryptomator

Anton Titkov

Department of Computer Systems Supervisor: Ing. Josef Kokeš

July 30, 2020

Acknowledgements

I would like to thank my supervisor Ing. Josef Kokeš for his crucial help, guidance, and invaluable experience. Special thanks to Olya for being there when needed most. I would especially like to thank my family for supporting me during my studies.

Declaration

I hereby declare that the presented thesis is my own work and that I have cited all sources of information in accordance with the Guideline for adhering to ethical principles when elaborating an academic final thesis. I acknowledge that my thesis is subject to the rights and obligations stip- ulated by the Act No. 121/2000 Coll., the Copyright Act, as amended, in particular that the Czech Technical University in Prague has the right to con- clude a license agreement on the utilization of this thesis as a school work under the provisions of Article 60 (1) of the Act.

In Prague on July 30, 2020 ...... Czech Technical University in Prague Faculty of Information Technology c 2020 Anton Titkov. All rights reserved. © This thesis is school work as defined by Copyright Act of the Czech Republic. It has been submitted at Czech Technical University in Prague, Faculty of Information Technology. The thesis is protected by the Copyright Act and its usage without author’s permission is prohibited (with exceptions defined by the Copyright Act).

Citation of this thesis Titkov, Anton. Security analysis of Cryptomator. Bachelor’s thesis. Czech Technical University in Prague, Faculty of Information Technology, 2020. Abstract

This thesis deals with the issue of storage encryption and data safety. It provides a brief overview of technologies and software for storage encryption currently available to users. The work provides a security analysis of Cryptomator, an open-source application for encrypting files in cloud storage. Potential risk areas are further explored and evaluated. Some of the possible attacks are shown.

Keywords cryptography, security, Cryptomator, encryption, scrypt, AES

vii Abstrakt

Tato práce se zabývá problematikou šifrování datového úložiště a bezpečnosti dat. Poskytuje stručný přehled technologií a softwaru pro šifrování úložiště, které jsou aktuálně dostupné uživatelům. Práce poskytuje bezpečnostní analýzu Cryptomator, open-source aplikace pro šifrování souborů v cloudovém úložišti. Potenciální rizikové oblasti jsou dále prozkoumány a hodnoceny. Jsou uvedeny některé možné útoky.

Klíčová slova kryptografie, bezpečnost, Cryptomator, šifrování, scrypt, AES

viii Contents

Introduction 1

1 Storage Security 3 1.1 File and File System ...... 3 1.2 Encryption technologies ...... 5 1.3 Comparison of encryption methods ...... 8 1.4 Existing tools for encryption ...... 8

2 Cryptomator 11 2.1 Features of Cryptomator ...... 11 2.2 Architecture ...... 11 2.3 Cryptography ...... 16

3 Existing audits 23 3.1 Audit by Tim McLean ...... 23 3.2 Audit by Cure53 ...... 24

4 Security Analysis Approach 25 4.1 Standards and Recommendations ...... 25 4.2 Vulnerability Evaluation ...... 27

5 UI Analysis 29 5.1 Main Screen ...... 29 5.2 Vault Management ...... 30 5.3 Summary ...... 31

6 Source Code Analysis 33 6.1 Potential areas from the UI analysis ...... 33 6.2 Cryptographic Functions ...... 35 6.3 Threats Discussion ...... 35

ix 6.4 Summary ...... 38

7 Implementation 39 7.1 Language ...... 39 7.2 Compatibility ...... 39 7.3 Dependencies ...... 40 7.4 Functionality ...... 40 7.5 Verification of correspondence ...... 40

8 Update 41

Conclusion 43

Bibliography 45

A Acronyms 51

B Contents of enclosed SD 53

x List of Figures

1.1 Example of a hierarchical directory system ...... 4 1.2 Boot Sequence with FDE technology ...... 5

2.1 KEK derivation using the scrypt KDF ...... 13 2.2 Process of key initialization ...... 13 2.3 Process of file/folder name encryption ...... 14 2.4 An example of FS structure transformation ...... 15 2.5 Process of file content encryption ...... 16 2.6 Encryption and decryption with CTR mode ...... 18

5.1 Main screen with Settings pane ...... 29 5.2 Vault management options ...... 30 5.3 Password input when creating a Vault ...... 30

6.1 PasswordStrengthUtil ...... 34 6.2 changePassphrase method ...... 34 6.3 Example of the masterkey replay attack ...... 37

7.1 Cryptomator working with a Vault created by the reimplementation 40

8.1 UI in version 1.5.0 ...... 41

xi

List of Tables

1.1 Comparison of encryption methods ...... 8

2.1 Layout of the file header ...... 15 2.2 Layout of the file chunk ...... 16

4.1 CVSS v3.1 Severity Rating Scale ...... 27

xiii

Introduction

Today, more and more people and companies around the globe are using cloud storage, which is becoming one of the most popular types of data storage [1]. Cloud storage is an online repository for various data (such as photos and documents) that allows access to the said data from any device. Since cloud storage providers do not store any data on the user’s local storage, an internet connection is required to upload, modify, or share data. Even though privacy is a fundamental human right, most cloud storages do not provide adequate security for the data stored in the cloud [2, 3]. When an account or a cloud provider is hacked, attackers may gain access to all stored data. Government and law enforcement-issued secret surveillance programs and backdoors are also a threat. [3, 4] Anyone who has unauthorized access to an account can use the data for personal gain and wrongdoing. Encryption helps protect the confidentiality of the data stored on computer systems or transmitted through a network. Encryption is the process of transforming data, such as a text message or photo, into a ciphertext – data unreadable by a human without using a corresponding encryption algorithm and a valid key, so even if our computer is lost or stolen, that data is safe. When appropriately implemented, encryption provides close to unbreakable protection of our data. Hence, reliable encryption methods are needed for reliable cloud storage. The issue of data encryption is continually evolving, and different methods and programs were created for this purpose. One of these programs is discussed in this thesis. For this security analysis, Cryptomator, a tool for disk encryption, has been chosen. The thesis consists of two parts; theoretical and practical. The first part of the thesis aims to introduce the reader to the problem of storage security and commonly used technologies to achieve such a goal. The encryption techniques described there relate solely to the data that is stored (on disk or in memory), not to the transmitted data. The opening section describes files and file systems; the next one provides

1 Introduction an overview of the encryption methods themselves – encrypting the entire disk, virtual disks, volumes, and encrypting individual files or folders. Finally, all the above methods are compared. The last section provides readers with a brief overview of the current options of storage encryption software, their features, and capabilities. The practical part consists of Chapters 2 to 7. Chapter 2 describes in detail the selected application, its advantages, disadvantages, and the differences from other disk encryption software. It presents the architecture and technologies used in Cryptomator. Chapter 3 introduces two existing audits to the reader and outlines prob- lems found during these audits, while Chapter 4 defines the methods and practices used in this security analysis. Chapters 5 and 6 summarize the UI and source code analyses, found prob- lems with possible solutions. Chapter 7 focuses on verifying the documented specifications by reimplementing Cryptomator’s critical functions by using in- dependent cryptographic libraries.

2 Chapter 1

Storage Security

In today’s digital life, it is essential to think about the security of data that is potentially put in risk not necessarily by intentional threats; the user himself often causes the damage unintentionally. [5] So the question is, how can our data be protected? Achieving data safety is possible by using various encryption and authentication (identity verification) techniques. Data can be encrypted individually by files, but also in bulk (all stored data). The effectiveness of a given method is affected by many factors. You can also choose encryption for a single user (where others do not have access to encrypted data) or multiple users. User authorization may require a password, a PIN, or a biometric data. Regular file backups are also recommended. [5] Before the introduction of each encryption method, it is necessary to define basic terms such as file or file system.

1.1 File and File System

This section aims to introduce the reader to fundamental terms, like file or file system. Both definitions are essential when talking about storage systems and storage encryption. Section 1.1.1 defines a file, a basic unit for data storage. Section 1.1.2 presents a systematic way for grouping files.

1.1.1 File A file can be defined as a set of grouped information, with each file having its unique name. From the end-user perspective, there are two basic types of files – data files, executables, and system files needed for OS functionality. A data file can be a text, an image, audio, but also video, compressed data. The user accesses the data files directly, while the operating system mainly handles the system files. The specific file type is determined by its extension or a magic number that is stored inside the file. [5, 6]

3 1. Storage Security

1.1.2 File System A file system defines the way files are stored and managed. Files are stored in a file system in folders that are used to organize them. Many operations can be done on a file system (such as folder creation, moving files between folders, or changing access rights). Different file systems use different folder structures. Modern file systems use a hierarchical directory system, depicted in Figure 1.1. [5, 6]

User directories and subdirectories

User files D

Figure 1.1: Example of a hierarchical directory system

The file system includes [6, 7]:

Space management – organization of files and folders and their as- • signed physical space on the storage device; fragmentation can occur when data on the storage is fragmented; it is better to ensure that their positions are contiguous

Folders – folders help keep track of files in the files system, allowing • the user to store data in a hierarchical order. This approach enables grouping files in a systematic way, for example, when there are multiple users in the system, and each user can have its own root directory

File/Folder names – naming helps distinct FS objects from each other. • There may be restrictions on using certain characters or words in the name

Metadata – contains information about files and folders; such as type, • name, size, creation date, modification date, ownership, and access rights

4 1.2. Encryption technologies

Access control – access rights and permissions; these can be assigned to • a specific user or group of users. For most users, this method of control is sufficient, but it is not resistant to advanced attacks (for example, privilege escalation, when a SUID executable or a kernel is exploited)

Storages also contain information about already deleted or temporary files (residual data). The deleted file is not physically deleted from the storage, only the place where it is located is marked as free by the file system and can be overwritten. Therefore, even a free space can contain sensitive data. [5]

1.2 Encryption technologies

Stored data can be encrypted using different technologies. The most com- monly used encryption methods are described in the following sections.

1.2.1 Full Disk Encryption Full Disk Encryption (FDE) encrypts all data on the hard disk, including the operating system and all applications with user data, so that the files can only be accessed after authentication through the FDE component. The technology can be implemented either in software or hardware. A partition table is a sector on media that serves as a part of the first sector on a storage device. It stores information about the storage partition scheme and decides which operating system to run (usually referring to the primary OS). The FDE software redirects the partition table to a special pre-boot environment (PBE) to verify the user’s identity. Verification can be done using an access name and password, an encryp- tion key stored on a USB, tokens generating a one-time password, a fingerprint reader, and the like. Subsequently, FDE decrypts the OS boot sector, which starts to boot. The FDE software gradually decrypts the files in memory on-the-fly as needed by the user. This also applies to stored data that is de- crypted.

Figure 1.2 shows a boot sequence on a storage with FDE.

Pre Boot Encrypted Boot Encrypted System Partition Table Environment Sector Volume

Figure 1.2: Boot Sequence with FDE technology [5]

However, the process of continually encrypting and decrypting data can slow down computer’s work, which should only be noticeable with larger files. A delay of seconds also occurs when the computer is turned on or off, or when the computer enters/exits sleep mode. Other disadvantages of FDE may be

5 1. Storage Security due to a change in the way the operating system boots, where modifying the partition table can cause problems with the correct startup of the computer, and there is also a risk of conflict with disk management software tools. [5] In addition to the software solution, FDE can also be solved in hardware, where FDE is part of the hard disk controller. Also, in this case, authentication is required before loading the operating system, but the encryption code is stored directly in the firmware which is stored in ROM. There is no way to remove the FDE from it without destroying the device. Although the whole disk encryption method can be considered secure, there are also some security risks in the form of password leakage, encryption key stored on USB (accessible), theft of a laptop with an already decrypted OS, and last but not least it also stores the encryption key in the memory of the running system (for example, in DRAM, where it is still available for some time after shutdown). By cooling the DRAM, this time can be extended, and the encryption key obtained. This type of attack is called a cold boot attack. [5, 8]

1.2.2 Virtual Disk Encryption The method of virtual disk encryption (VDE) creates a special file on the disk, which at first glance looks like one unit – the so-called container that holds folders and files. A virtual disk represents the container. Access to the virtual disk requires software that runs under the operating system and evaluates all requests to read from or write to the container. Only after identity verification (and it can be in similar ways as in the previous case – for example, by entering a password) is the virtual disk, including the data on it, accessible. The required files are decrypted and encrypted on-the-fly based on the current requirements. There is also a variant where the virtual disk is automatically made available after successful user authorization. The virtual disk can be copied without the need to decrypt it, so it is portable and usable on other media, which makes it easier to backup. Here again, an authentication process is required to decrypt the content. Further- more, it is appropriate to consider the configuration of the operating system, i.e., whether it is allowed for the user to write files only to the encrypted virtual disk or not. [5]

1.2.3 Volume Encryption Volume Encryption works on a similar principle to VDE, but instead of a virtual disk, only a logical volume, which is typically located on an internal storage device or removable storage media (such as a USB flash drive), is encrypted. Access to the information on the volume is possible again after the authentication process. Again, the software is needed that controls access to

6 1.2. Encryption technologies the volume and, based on successful user identification, decrypts and encrypts the data on the volume that the user wants to read or write. In addition to regular data, system or boot volumes can also be encrypted. Here, like in FDE, the possibility of SSO can be used, where encrypted volumes are automatically made available to an authorized user. [5]

1.2.4 File and Folder Encryption File Encryption ensures that individual files in memory or on disk are pro- tected, as in previous cases, by the authentication process. A user can encrypt files as well as entire folders (Folder Encryption) – and while it can be said that the principle is the same, folder encryption must also manage the en- cryption of metadata related to the folder contents. Encryption is possible at the operating system level, but a number of third-party programs are also available. [5] At first look, it appears that the method of encrypting folders is similar to the method of encrypting virtual disks, which can also contain a number of files (as well as a folder), but there is a difference. The contents of the virtual disk are not visible without the necessary user authentication, so those who have not been authorized cannot see what specific folders or files are on it. On the other hand, the files in the folder that is encrypted are visible (their names or even metadata can be displayed), only it is not possible to access their contents. This encryption method applies to any type of storage media. [5] The decryption process is the same as in the previous cases – after success- ful user authentication, the file gets decrypted and opened. Because individual files get decrypted, this form of security has minimal effect on their speed of opening. There are several options when encrypting files and folders. Firstly, it is up to the user to decide which files or folders he wants to encrypt; the ad- ministrator can specify automatic encryption of the contents of specific folders. It is also possible to encrypt only specific file types (based on their extension or magic number), you can automatically encrypt all files that are created by specific software, and finally, any files that the user creates. [5] This method has one indisputable advantage: if the entire disk is encrypted and data and software on it are made available, the individual files may be not protected. This can be solved by encrypting files or folders. However, there is also the option to set up automatic decryption of all specified files after the authentication of a user. When encrypting files, keep in mind that the file may not be completely protected, as the residual data described in Section 1.1.2 may also be associ- ated with it, and it is not protected. An additional issue with this method can be that before using a file, it must be decrypted, which is not on-the-fly opera- tion and may take some time. It can also lead to residual data creation. [5, 8]

7 1. Storage Security

1.3 Comparison of encryption methods

When picking data encryption technologies, it must be considered how each technique will change the end-user devices and infrastructure. A comparison of these data encryption methods is provided in Table 1.1, which is based on the information provided by the NIST Special Publication 800-111. [5]

Encryption technology

Characteristic Full Disk Encryption Virtual Disk Encryption Volume Encryption File/Folder Encryption

Desktop machines, Supported Devices Desktop machines All types of devices removable storage All types of devices devices

All data on storage All data in container All data in container (user/system files, Scope of protected data (user data, metadata, and (user data, metadata, and Specific files/folders metadata, and residual residual data) residual data) data)

All data in volume is lost, Potential data loss in case All encrypted files/folders All data on device is lost All data in container is lost may damage storage of a storage failure are lost functionality

Encrypted data portability Portable Portable Portable Portable

Table 1.1: Comparison of encryption methods

1.4 Existing tools for encryption

Nowadays, a relatively large amount of software that offers secured access to data can be found on the market. In addition to data encryption, the other most implemented functionalities, among others, are generating random passwords, password recovery options, hardware token support, and a choice of various encryption algorithms. The following sections briefly describe some of the alternatives for data encryption available for users on computer machines.

1.4.1 BestCrypt BestCrypt is a commercial disk encryption software developed by Jetico. BestCrypt offers two variants: Container Encryption and Volume Encryp-

8 1.4. Existing tools for encryption tion. BestCrypt works with a wide range of encryption algorithms, including DES/Triple DES, AES, Serpent, Blowfish, Twofish with support of CBC, XTS, and LRW modes of operation. It is worth noting the support of hardware to- kens, such as YubiKey and SafeNet eToken. [9]

1.4.2 FileVault 2 FileVault 2 is a built-in macOS software made by Apple for whole-disk en- cryption that protects all data on a Mac and prohibits illegal access without the decryption key or the valid credential. FileVault 2 uses XTS-AES-128 and an encryption key with a size of 256 bits in compliance with NIST Special Publication 800-38E. FileVault 2 provides several password recovery options as well as an easy-to-use user interface. [10, 11]

1.4.3 LUKS Linux Unified Key Setup (LUKS) is a disk encryption format standard, aimed initially at use in OSes based on the Linux kernel. The primary goal was to provide a user-friendly, standardized way of managing decryption keys. One of the features of the standard is the support of several encryption keys used on an equal basis with each other to access a single encrypted medium, with the possibility of adding and removing them at the user’s demand. The LUKS1 and LUKS2 specifications define platform-independent stan- dards that are available in the cryptsetup tool. It uses the dm-crypt tool as a backend for a disk encryption. [12]

1.4.4 VeraCrypt VeraCrypt is a free, open-source storage encryption software. VeraCrypt orig- inated as a fork of the discontinued TrueCrypt project. [13] VeraCrypt provides the ability to use FDE (only on Windows), VDE as well as volume encryption. It also has the option for an encrypted outer volume to have an additional volume hidden inside. It is possible to have a hidden OS in such volume. VeraCrypt supports multiple encryption algorithms such as AES, Camel- lia, Serpent. Cascade variants of these algorithms are available. Cascade encryption is a method of encryption when multiple (mostly two or three) different algorithms are used with different encryption keys. [14] VeraCrypt mainly uses the XTS mode for encryption. Hardware tokens can be used as a keyfile provider. [15]

9

Chapter 2

Cryptomator

Cryptomator is an open-source disk encryption software specifically designed to work with cloud storage. Cryptomator is available for free on most desktop platforms. On mobile platforms, however, it costs a one-time fee with no extra microtransactions. [16, 17]

2.1 Features of Cryptomator

Multiplatform – Cryptomator supports popular modern platforms: • macOS, Windows, Linux, iOS, Android

Open-source – Cryptomator for desktop is written in Java, and its • source code is available for download and further study on GitHub [18]

Cloud storages support – Cryptomator works with different cloud • storages, such as Dropbox, iCloud Drive, Google Drive, One Drive

Modern encryption – Cryptomator uses the latest standards for all • encryption operations, including file/folder name encryption [19]

Multiple vaults support – Cryptomator allows the user to use as • many vaults as the user needs

File contents integrity checks – Cryptomator architecture allows • checking all encrypted content for integrity

2.2 Architecture

This section introduces the principles and technologies Cryptomator is de- signed upon. All encryption algorithms, their respected operation modes, and hash functions described in the following sections are discussed in Section 2.3, Cryptography.

11 2. Cryptomator

2.2.1 Virtual File System

The main unit for storing encrypted user data is called a Vault. Vault is stored physically as a special folder consisting of a special file called mas- terkey.cryptomator and two inner folders d and m, d contains the actual en- crypted user data. In contrast, m contains metadata related to user data from the d folder. Internally the Vault is implemented as a virtual drive by using one of the three frontends available to the user: FUSE (macOS or Linux), Dokany (Windows), and WebDAV as a fallback if the other two are not avail- able. All the user-initiated operations (such as reading or writing a file) are made using this virtual drive. [19]

2.2.2 Masterkey File

Masterkey is a file unique to each Vault. It contains all information required for Cryptomator to work correctly with the Vault. At the moment of writing this thesis, the current version of the Masterkey file is version 6. Masterkey file is a JSON object, containing [19]:

scryptSalt – a Base64 string representing a salt data used for the scrypt • key derivation function (KDF)

version – a number representing a Masterkey version, in this case, it • equals 6

scryptCostParam – a constant used in the scrypt KDF. Equals to • 16384. Used for CPU and memory optimizations.

scryptBlockSize – a constant used in the scrypt KDF. Equals to 8 •

primaryMasterKey – a Base64 string representing an encryption mas- • ter key encrypted using the AES Key Wrap algorithm (RFC 3394)

hmacMasterKey – a Base64 string representing a MAC master key • encrypted using the AES Key Wrap algorithm (RFC 3394)

versionMac – a Base64 string representing a HMAC-256 of the version • value to stop Masterkey version downgrade attacks

12 2.2. Architecture

2.2.3 Keys Initialization When the user creates a Vault, and the structure described in Section 2.2.1 gets generated, a master key is initialized. First, a pair of encryption and MAC master keys is generated by a cryptographically secure pseudorandom number generator (CSPRNG). In this case, SHA1PRNG is used. The use of CSPRNG ensures the strength of the underlying cryptographic primitives, due to the unpredictability of generated bits. [20] After that, both keys get enrypted using the AES Key Wrap algorithm. A key encryption key (KEK) is used for this operation. KEK is derived from a password entered by the user with the scrypt KDF. [19]

User Password Salt

scrypt

Key Encryption Key

Figure 2.1: KEK derivation using the scrypt KDF

Both keys are then written into a Masterkey file, described in the previous section, for later use in operations with the Vault. The whole process of keys initialization is depicted in Figure 2.2.

CSPRNG

Encryption Key MAC Key

AES AES Key Encryption Key Key Wrap Key Wrap

Wrapped Wrapped Encryption Key MAC Key

Masterkey File

Figure 2.2: Process of key initialization

13 2. Cryptomator

2.2.4 File/Folder Name Encryption

One of the key Cryptomator features is a file name encryption and folder structure obfuscation. In order to achieve that, both file and folder names are encrypted using AES with SIV mode of operation is used. For each folder, a unique ID is assigned. The root directory is an exception, with the unique ID equal to a zero bytes string. A file name is passed to the algorithm as is. AES-SIV uses the encryption and MAC key for encryption and IV synthesis, respectively. The parent folder’s unique ID is also passed as associated data to the IV synthesis function; this mitigates unauthorized changes to the VFS structure. If it is a directory, a zero is then added at the begging of the encrypted name. [19]

Encryption Key

Plaintext Name AES-SIV Base32 Encoding Ciphertext Name

MAC Key Parent folder UID

Figure 2.3: Process of file/folder name encryption [19]

For example, with the encryption key set to:

5313A6E4 A100478E FF85F7A2 35BC374D 4FB5954D 9235B99D 529132F3 2BCF6F3C and the MAC key equal to:

F1930AD7 528568E1 DA5417F4 626A1224 F9816261 3D3B7A67 C7315B57 CAE55E64 ,

the following folder structure would look like this:

14 2.2. Architecture

FolderA 6D FolderB 6ENGVYTJLO4O3WPYTZSLS2GI4CCKRD fileB 42BOEK4V3JT2W6JTGVYIBZMP4MXWPYQMIM======fileC JJNDXZZXMQXZNDH3WOSPXYKDCZ35EI243M======fileA 6U FolderC WCTP2WEROWSCSKYXOG4UXA77PIOCYK fileD 0ZB65B2QALGTK23KKJWA6JJGFOHVLSK6Y5FLTY=== YZAPSMLXWWN4PFEKOBFD3X7KNU63XLZDNM======KP FJJRP2B26QUDW42GQ6YJOZ3NCZ2I22 0RZADXKVDWAOHFXCW2XIQRHSBK22FXRRTJ3YV2=== 04O4G35OOG5U7GQOHFUDFCQ34PHA3VTV7HM33Y=== M5 QFUQE4QCUELJ2EPAXGUCVAIBSUHSM3 WLCOPAZZ4OHCMCPAYUTGW2IZUF5YCNS7PM======

(a) VFS structure (b) Vault physical representation

Figure 2.4: An example of FS structure transformation

2.2.5 File Header Encryption

This section describes the construction of a file header that contains metadata needed for decryption of the file content. First, a random nonce is generated. It is unique for each file and later used for the File Content Key (FCK) encryption and the integrity checks of data chunks. The File Content Key consists of 32 bytes of random data and is encrypted with 8 bytes set to 1’s (0xFF 8) using AES-CTR. After that, a × HMAC-SHA256 of the nonce and encrypted FCK is calculated and placed at the end of the header. [19] The table below shows the layout of a file header.

offset size description Random nonce used as IV for the header encryption 0 16 and the file integrity checks AES-CTR of: 16 40 8 bytes filled with 1 (0xFF 8) + 256 bit File Content Key × 56 32 HMAC-SHA256 of the previous 56 bytes

Table 2.1: Layout of the file header

The total size of the header is 88 bytes.

15 2. Cryptomator

2.2.6 File Content Encryption

Before the actual encryption happens, the file data gets split down into chunks of up to 32KiB. Each chunk also has an additional data of 48 bytes required for the encryption process and the integrity checks. The whole process of a file data encryption is depicted in Figure 2.5. [19] The table below shows the layout of a file chunk.

offset size description Random nonce used as IV for the chunk encryption 0 16 and the integrity checks 16 N Up to 32KiB of the chunk data, encrypted with AES-CTR HMAC-SHA256 of the file header nonce, the chunk index, 16+N 32 the chunk nonce, and the encrypted data

Table 2.2: Layout of the file chunk

File Content Key Chunk nonce

Plaintext AES-CTR Encrypted Encrypted File chunks chunks File split join

File header nonce + Chunk index + Chunk nonce

MAC Key HMAC-SHA256

Figure 2.5: Process of file content encryption [19]

2.3 Cryptography

This section defines the AES cipher, various modes of operation, and cryp- tographic hash functions used in Cryptomator. Algorithm descriptions are provided for each cryptographic primitive.

16 2.3. Cryptography

2.3.1 AES Currently, only the AES cipher is supported. Developed by Vincent Rijmen and Joan Daemen, AES is a symmetric block cipher with a block length of 128 bits and a key size of 128, 192, or 256 bits. [21] Cryptomator supports only AES-256, which means a key size must equal 256 bits. AES-256 is described in the pseudo-code below. Algorithm 1: AES-256 [21] Input: key K, data D Result: Encrypted D using AES-256 begin noOfRounds 14; ← state D; ← expKey KeyExpansion(K); ← state AddRoundKey(state, expKey, 0); ← /* first 13 rounds */ for i = 1; i < noOfRounds; i++ do state SubBytes(state); ← state ShiftRows(state); ← state MixColumns(state); ← state AddRoundKey(state, expKey, round); ← end /* last round */ state SubBytes(state); ← state ShiftRows(state); ← state AddRoundKey(state, expKey, round); ← return state end

KeyExpansion is a function for generating round keys from the en- • cryption key [21]

AddRoundKey is a function that adds a round key to the state by • using XOR operation [21]

SubBytes is a function for a non-linear byte substitution operating • separately per byte using the S-box table [21]

ShiftRows is a function that processes the state, cyclically shifting the • last three rows of the state by different values [21]

MixColumns is a function that takes all the state columns and mixes • their values (individually) to get new columns [21]

17 2. Cryptomator

2.3.2 Modes Of Operation

Cryptomator uses only two modes of operation: CTR and SIV. CTR mode is used for file’s content encryption, while SIV is needed for file/folder name encryption. The following sections describe both of these modes.

2.3.2.1 CTR

CTR mode turns AES into a stream cipher. It generates the keystream block by encrypting the sequential values of the so-called counter. A counter can be any function that produces a sequence that is guaranteed not to repeat for a long time. The encrypted value is then XOR’ed with a plaintext block to get ciphertext. [22]

Counter Counter

Encryption Key Cipher Encryption Key Cipher

Plaintext + Ciphertext +

Ciphertext Plaintext

Figure 2.6: Encryption and decryption with CTR mode

2.3.2.2 SIV

SIV is an authenticated mode of operation for AES. It combines the CTR mode with AES-CMAC for integrity protection. SIV takes a key, a plaintext, and optional associated data (AD) that is used for authentication. The result is a synthetic initialization vector (SIV) and a ciphertext with the same length as the plaintext. [23]

18 2.3. Cryptography

Listings below describe the operation of the mode.

Algorithm 2: AES-SIV [23] Input: Encryption key KE, MAC key KM , plaintext P , data S1, ..., Sn Result: Ciphertext with SIV begin IV S2V (K , S , ..., S , P ); ← M 1 n /* || is concatenation */ C IV & (164 || 01 || 131 || 01 || 131); /* counter */ ← X AES-CTR(K , IV, C, P ); ← E return IV || X; end

Algorithm 3: S2V [23] Input: MAC key KM , data S1, ..., Sn Result: Synthetic IV begin if n = 0 then /* || is concatenation */ 127 1 return AES-CMAC(KM , 0 || 1 ); end D AES-CMAC(K , 0128); ← M for i = 1; i < n; i++ do D dbl(D) AES-CMAC(K , S ); ← ⊕ M i end if length(S ) 128 then n ≥ T S D; ← n ⊕ else T dbl(D) pad(S ); ← ⊕ n end return AES-CMAC(KM , T) end

19 2. Cryptomator

2.3.3 scrypt

In cryptography, password-based key derivation functions are used for deriving secret keys from a secret value, in this case, a password.

scrypt is a key derivation function developed by Colin Percival. Designed to be resistant to brute force and custom hardware attacks, it uses memory- hard functions to achieve that goal. [24]

Under the hood, scrypt uses the well-known PBKDF2 (with HMAC-SHA256) created by RSA Laboratories and Salsa20/8.

Algorithm 4: scrypt [24] Input: passphrase P , salt S, cost factor N, block size factor r, parallelization factor p, key length l Result: key derived from P begin blockSize 128 * r ; /* in bytes */ ← B P BKDF 2(P , S, 1, blockSize * p); ← for i = 0; i < p; i++ do B ROMix(B , N); i ← i end /* || is concatenation */ newSalt B0 || B1 || ... || Bp 1; ← − return P BKDF 2(P , newSalt, 1, l) end

ROMix is a sequential memory-hard function that makes the creation of custom hardware an expensive task. The function computes a large number of pseudo-random values and then stores them in RAM. [24]

More detailed explanation of the scrypt KDF can be found in the white paper written by the author of the algorithm. [24]

2.3.4 HMAC

HMAC is a message authentication mechanism using cryptographic hash func- tions. Any cryptographic hash function with iterative nature (such as SHA-1, SHA-256, SHA-512) can be used in HMAC. The strength of HMAC directly depends on the strength of the used hash function. [25].

20 2.3. Cryptography

Algorithm 5: HMAC-SHA256 [25] Input: key K, data D Result: HMAC-SHA256 of D begin blockSize 64; /* in bytes */ ← hashSize 256; /* in bits */ ← ipad 0x36 * blockSize; /* inner padding intialization */ ← opad 0x5C * blockSize; /* outer padding intialization */ ← if length(K) > blockSize then K SHA-256(K); ← end for i = 0; i < length(K); i++ do ipad[i] ipad[i] K[i]; ← ⊕ opad[i] opad[i] K[i]; ← ⊕ end /* || is concatenation */ return SHA-256(opad || SHA-256(ipad || D)) end

In the case of Cryptomator, SHA-256 is used for calculating HMAC. SHA-256 is built on the Merkle–Damgård structure. After the padding, the plaintext is split into blocks, each block into 16 words. The algorithm passes each block of the message through a cycle with 64 rounds. At each iteration, 2 words are transformed; the remaining words define the transfor- mation function. The processing results of each block are added; the resulting sum is the value of the hash function. [26]

21

Chapter 3

Existing audits

This chapter aims to introduce the reader to the security audits conducted by other independent researchers. A review of past analyzes is important as it allows to learn about previous security issues and developer responses to these findings. Both audits were aimed at examining the library responsible for the SIV mode implementation.

3.1 Audit by Tim McLean

Tim McLean released the report on November 4th, 2016. It focuses on siv-mode library – Cryptomator’s implementation of the SIV mode of op- eration. The version of the library at the moment of the report was 1.0.8. The audit identified two medium-severity vulnerabilities, four low-risk areas, and provided several recommendations for secure usage of the mode. Both vulnerabilities were fixed in version 1.1.0. They are discussed in the following sections. [27]

3.1.1 No boundary checks for the number of AD elements

It was noticed that the implementation of S2V function lacks boundary checks for the total size of input components passed to the function, making it possible for an attacker to forge inputs that bypass authentication protections of the SIV mode. [27] According to the mode’s specification, the security of S2V function de- scribed in Algorithm 3 is only proven when the number of elements provided as S1...Sn is equal to N-1, where N is a block size of the underlying algorithm, which in this case is AES, and its block size is 128 bits. Consequently, the maximum number of components passed to the function must be 127 or less, including the plaintext. [23]

23 3. Existing audits

3.1.2 Side-channel attack on AES Before version 1.1.0, siv-mode was using Bouncy Castle’s implementation of AES as the default one. Unfortunately, this implementation is susceptible to a cache-timing attack, allowing an attacker to gather information about the memory’s internals and reconstruct both SIV keys. [27] The problem lies in the implementation of T-tables in AES: the lookup in the table is not a constant-time operation; thus, it is vulnerable to the side-channel attack. [28] The first real-world attack on Bouncy Castle’s Java implementation was demonstrated in 2016 by researchers from the Institute of Applied Information Processing and Communications (IAIK). [29] As a result, the library now works with the JCE AES implementation by default, which uses AES-NI when possible and is immune to that kind of attack. [30]

3.2 Audit by Cure53

Conducted in 2017, the audit did not detect critical vulnerabilities in the library code itself. However, a problem was identified with the Github repos- itory, in which the private key for signing releases was stored.[31] Even though this is a critical problem, according to the developers, the key was protected with a password of 30 characters (from the alphabet of 96 characters), which was salted and iterated using SHA-1 through 20971520 iterations. [32] It was also noted that when initializing the JceAesBlockCipher class, AES- ECB without padding is indicated as the used cipher. [31] As explained by the developers, this is not a problem since it is the only way to obtain a Cipher instance without using any mode of operation. In future uses of the class, the mode is not actually used by the library. [31, 32]

24 Chapter 4

Security Analysis Approach

The analysis was conducted on macOS Catalina using Cryptomator version 1.4.17 (which was the latest version at that time) and iCloud Drive as the cloud storage provider. It consists of three consecutive parts. In the first part, the analysis of the user interface (UI), the application is examined from the perspective of everyday usage. The goal is to find areas that play a crucial role in the application’s security and do not comply with proper security principles, pose a security risk, or are not sufficiently clear to the user, which usually leads to weaker security. All suspicious areas are marked as Sx for later examination during the source code analysis. The second part of the security analysis deals with the source code of the application. It emphasizes suspicious places selected during the UI analysis and the study of the program’s architecture. Vulnerabilities discovered dur- ing this analysis, together with the severity score and advised solutions, are described at the end of the corresponding section. The last part of the analysis is an independent reimplementation of the program. It is necessary to ensure that Cryptomator is implemented accord- ing to its specification and does not perform any malicious operations in the background.

4.1 Standards and Recommendations

The most recent standards published by NIST and Microsoft are used in this analysis. Specifically, Cryptomator is compared against NIST SP 800-63B and the Password policy recommendations publication from Microsoft. [33, 34] The following sections outline some of the recommendations mentioned earlier.

25 4. Security Analysis Approach

4.1.1 UX recommendations The standards outline some recommendations regarding the UX when man- aging user identities and authentication.

When entering a password, the program should present information • about the strength of the password, to guide the user to choose a strong enough password

The user should be able to show/hide password while typing. Giving • this option helps the user make fewer mistakes in the password, which is important due to the lack of the password recovery options

It must be taken into consideration that a user might use a password • manager, so the program should not disallow pasting a password into the password field

Password hints and recovery questions must be avoided. These options • are highly vulnerable to social engineering attacks

It is an accepted practice to provide additional or an alternative method • of authentication and recovery options, such as hardware tokens or bio- metrics

4.1.2 Password A password must be of adequate complexity and length to make it difficult for an attacker to guess, but it must also be easy for the user to memorize. One of the basic indicators of password strength is the entropy of this password. Entropy is expressed in bits and estimates the password complexity. Entropy H of a randomly chosen password of length l using a character set of N characters can be calculated using this formula [35]:

l H = log2(N )

Usage of this formula can confirm that a randomly chosen password of eight characters (recommended by the standard) generated using a set of 94 printable ASCII characters (excluding space) provides entropy equal to 52.7 bits. It is twice as high entropy as the password in the same characters set with a length of four characters, and 1.4 times higher entropy than a password consisting of six characters. [35] However, it should be noted that user-created passwords have a dramat- ically lower entropy than randomly chosen passwords, so other parameters, such as the password composition, should be taken into account when as- sessing the complexity of the password. Therefore, it is recommended to use software designed for measuring password complexity.

26 4.2. Vulnerability Evaluation

A password should be salted and hashed using an approved KDF. The goal is to make each guessing trial expensive and increase the cost of the brute force attack. Because the hash’s size does not depend on the input’s length, there should not be a limitation on a maximum password length.

4.2 Vulnerability Evaluation

This section describes the Common Vulnerability Scoring System (CVSS) Ver- sion 3.1 used for the evaluation. The CVSS attempts to standardize the vulnerability severity assessment making it is possible to prioritize fixes by examining the risks of individual vul- nerabilities. Three benchmark groups form the system – the Base, Temporal, and Environmental.

Rating CVSS score None 0.0 Low 0.1 – 3.9 Medium 4.0 – 6.9 High 7.0 – 8.9 Critical 9.0 – 10.0

Table 4.1: CVSS v3.1 Severity Rating Scale [36]

The Base group is a required metric. It represents the fundamental prop- erties of a vulnerability that are persistent across different conditions. It gives a score from 0 to 10 which reflects the severity of a vulnerability by assum- ing the worst-case impact. The group consists of 2 categories (Exploitability and Impact), and a special Scope metric that defines whether a vulnerability impacts resources outside of the original security scope.

4.2.1 Exploitability metrics These metrics describe the characteristics of the vulnerable component.

Attack Vector Attack Vector describes the way in which it is possible to exploit the vulner- ability. Possible values: Network/Adjacent/Local/Physical

Attack Complexity Attack Complexity represents the difficulty of the discovered vulnerability exploitation. Possible values: Low/High

27 4. Security Analysis Approach

Privileges Required Privileges Required represents the level of privileges an attacker needs to have prior to exploiting the vulnerability. Possible values: None/Low/High

User Interaction User Interaction defines if a user (other than the attacker) must perform spe- cific actions, or if it is possible to exploit the vulnerability solely by the at- tacker’s actions. Possible values: None/Required

4.2.2 Impact metrics These metrics describe the effects of a successful attack on a vulnerable com- ponent.

Confidentiality Impact Confidentiality represents the impact on the data confidentiality managed by the vulnerable system. Possible values: None/Low/High

Integrity Impact Integrity represents the impact on the trustworthiness of the vulnerable sys- tem. Possible values: None/Low/High

Availability Impact Availability represents the impact on the vulnerable system’s availability. Pos- sible values: None/Low/High

4.2.3 Scope metric This metric defines whether a vulnerability impacts resources outside of the original security scope.

The two remaining groups (Temporal and Environmental) are optional and can modify this score. The Temporal group reflects the current state of exploit availability, the existence of any patches, or the confidence in a threat. The Environmental group outlines the aspects of a threat that are unique to a specific context. [36] All scores are calculated using the calculator provided by the National Vulnerability Database. [37]

28 Chapter 5

UI Analysis

This chapter describes the UI of Cryptomator, the Vault creation process, password managing, and potential security problems discovered while studying the UI. Although the interface looks simple and not bloated with unnecessary details, it does not guarantee the absence of security problems.

5.1 Main Screen

Figure 5.1: Main screen with Settings pane

When Cryptomator is launched, a user is presented with a welcome screen. The main window has a list of Vaults on the left side, while the right side pane changes depending on the context. By pressing the cog button, Settings

29 5. UI Analysis pane (Figure 8.1) shows up. The settings pane allows users to choose pre- ferred frontend for the VFS (as well as some configurations for the selected frontend, e.g., WebDAV port if WebDAV is selected), enable automatic check for updates, and debug mode. By enabling debug mode, Cryptomator creates additional log files with useful information for solving problems with a Vault.

5.2 Vault Management

Figure 5.2: Vault management options

By pressing the ”+” button, two options are presented: create a new Vault, or add already existing Vault.

5.2.1 Vault Creation A pane where the user can enter the Vault password is displayed when creating a new Vault.

Figure 5.3: Password input when creating a Vault

The password input interface consists of two protected fields with a pass- word strength meter, and a warning saying that password recovery options do not exist. There are no additional authentication options, such as hardware tokens support. It is also not possible to show/hide a password while typing.

30 5.3. Summary

The interface does not impose any limitation on the password length or com- plexity, allowing to create a password of one character. One can notice that this interface violates the guidelines described in Section 4.1. Thus, marker S1 is assigned to the area and will be further investigated during the source code analysis. When confirming a Vault’s creation, a new masterkey file is created at the location of the Vault. There’s no way to change that behavior and save the masterkey at an arbitrary location.

5.2.2 Vault Unlock Process The next part of the analysis studies the behavior when performing operations on an existing Vault. To unlock and use a Vault, the user must provide a valid password. There’s also an option to save the password into the system’s keychain for unlocking without a password. Again, since the program does not allow any other authentication type, such an option is missing when opening a Vault. After successfully entering the password, the integrity of the structure of the Vault and the files contained in it are checked. The change password option is missing from the unlock screen. It’s hidden and hard to access without knowing where to look. While, at first sight, this area does not expose any serious security impli- cations, it must be examined how the program handles integrity checks and change password process. A marker S2 is assigned to this area.

5.3 Summary

When studying the UI, several problems and disparities with the NIST stan- dard [34] were discovered:

In accordance with the standard’s recommendations, the minimum pass- • word length selected by the user must be at least eight characters. There is no minimum password length requirement enforced by Cryptomator

When confirming the password, there is no additional confirmation layer • when using a weak password

It is also recommended to provide a function of unhiding a password so • that the user can verify the entered password’s correctness. Cryptomator does not provide this functionality

There is no way to create a recovery key when the password is forgotten • No option to use a different authentication type • 31 5. UI Analysis

It was also noted the absence of the option for saving a masterkey file to an arbitrary location. While these flaws are not severe, they indirectly reduce the safety of the user data. In the next chapter, the discovered problems will be examined in detail at the source code level. It will also provide evaluation and possible solutions to these problems.

32 Chapter 6

Source Code Analysis

After studying the application’s UI, it was concluded to focus during the source code analysis on the file integrity checks, password handling, and other related operations. All found threats allow attacker access only to Cryptomator data, making the Scope metric Unchanged. Program functionality and availability remain not endangered, so the Availability Impact is set to None for all threats described in this chapter.

6.1 Potential areas from the UI analysis

This section talks about the analysis of the source code related to the suspi- cious areas found during the UI analysis.

6.1.1 S1 – Vault Creation All secure fields during the process are implemented using the SecPassword- Field class, which allows to securely clear the data after use. However, some parts of the codebase use the String type. The Java Cryptography Architec- ture Reference Guide declares that this type is insecure because it is immutable and cannot be cleared or overwritten with zeros to hide sensitive data. [38] That leads to passwords remaining in the RAM even after they are no longer needed. Section 6.3.1 talks more about the problem. PasswordStrengthUtil class is responsible for the password strength calcu- lation. It relies on Dropbox’s Zxcvbn algorithm. In this class, of particular interest is the constructor and the computeRate method, which takes a password as a parameter and returns an integer value from -1 to 4, where -1 means an empty password, and 0-4 determines the strength of the password (4 is the best score). Before calling zxcvbn.measure the password gets truncated to 100 characters. While at this password length, it may not present a security problem, it may confuse the user with unexpected behavior.

33 6. Source Code Analysis

For example, if the password is set to A * 50 + B * 50 + ABC#@$ASASFSASDASDASFAFSDGFDGSBTRVRV5% PasswordStrengthUtil would give significantly different results depending on wheter we truncate the password or not. In the first case, the score will be ”Weak” (internally mapped to 1), the other case would give score ”Very strong” (mapped to 4).

Figure 6.1: PasswordStrengthUtil class with internals of computeRate method, used for the password strength calculation

A detailed study of this algorithm and its comparison to other similar algo- rithms was made by Xavier de Carné de Carnavalet and Mohammad Mannan. [39]

6.1.2 S2 – Unlock and Change Password Change password routine After the user clicks the ”Change Password” button, method didClickChangePass- wordButton of ChangePasswordController is called, which later calls changePassphrase method. The code is provided in the figure below. [40, 41]

Figure 6.2: Internals of changePassphrase method, showing that only KEK is changed during the process

34 6.2. Cryptographic Functions

It was noticed that a backup masterkey with the old password is created at the very end of the method. When the password is changed, only the KEK used for key wrapping is updated, while the actual keys used to encrypt data and verify its integrity remain unchanged. It allows an attacker to get full access to encrypted data by having a masterkey backup file with a weak (or leaked) password. The possible attack and solution are described in Section 6.3.2

File integrity checks While studying the architecture of Cryptomator and its source code, it was noticed that when checking the integrity, there is no check of the dependence of the file contents on its name. This allows you to swap the contents of two files and mislead the user. An example and assessment of this problem is given in Section 6.3.3.

6.2 Cryptographic Functions

Part of the source code analysis is checking the implemented cryptographic primitives for deviations from the corresponding specifications. It is also cru- cial to make sure that they are used correctly, since the proper implementation of the algorithm does not guarantee security if they are used incorrectly. Cryptomator implements two cryptographic elements: the SIV mode of operation and script KDF, which are located in the siv-mode and cryptolib libraries, respectively. The implementation of the SIV mode has been checked agains RFC 5297 with the output checked against the test vectors provided by the standard. [23] No differences were found. The implementation of the scrypt KDF has been checked agains the white paper provided by the author of scrypt. [24] The outputs were also checked against the test vectors provided by this paper. Like in the previous case, no differences were found. All outlined cryptographic primitives are used correctly and accordingly to their respective specifications.

6.3 Threats Discussion

This section discusses vulnerabilities found during the analysis, their evalua- tion and possible solutions.

6.3.1 Password persistence in RAM As discussed earlier, the Vault’s password may remain in RAM even after clos- ing this Vault. In some cases, password information can be found in memory

35 6. Source Code Analysis even after the program is closed. This weakness can be exploited by using a cold boot or DMA attack. [42, 43]

Evaluation For this attack, access to a system running Cryptomator is required, due to this reason, the Attack Vector metric is set to Local. Most of the OSes require the highest rights to perform a memory dump, thus the Privileges Required metric is set to High. Since it is required that the user must enter a valid password, the User Interactivity is set to Required. Attack Complexity is set to High because it requires a specific set of tools and knowledge to perform this attack. This attack gives the attacker access to the Vault’s passwod, due to that reason both Confidentiality and Integrity Impact are set to High. The overall CVSS score of 5.6 falls into the Medium severity category.

Possible solution A possible solution to the problem is to move away from using the String data type in favor of Character arrays, which can be easily cleared of unnecessary information. Another solution would be providing an option to encrypt RAM sections as VeraCrypt does. [15] At the same time, RAM encryption is not a complete solution to the problem, since RAM encryption raises another question: how to protect the encryption key stored in an unencrypted memory area? In order to secure the key, it can be stored safely in a TPM chip or similar hardware (such as T2 Security Chip).

6.3.2 Masterkey Replay Attack One of the problems found during the analysis was that changing a Vault password would only change the respective KEK and would not change the Vault’s encryption key, making it an easy target for a master key replay attack. Given that Cryptomator is intended for use with cloud storage, an attacker, who has access to the user’s cloud storage, can quickly recover an older version of the master key with a weak password and use it for unlocking the newly updated Vault. The example of this potential attack is depicted in Figure 6.3. For an example of this attack, let us assume that an attacker uses the man-in-the-middle technique to get data uploaded to the cloud, at the moment when the user wants to change a weak password to a stronger one, a backup of the masterkey will be created and uploaded to the cloud, after that an attacker will take possession of a copy of the backup and will be able to perform an offline attack, for example, a brute force attack, and decrypt files stored in the Vault.

36 6.3. Threats Discussion

MasterKey with a new stronger password

user Vault in a cloud storage updates password the Vault is updated

uploads the Vault with a weak password

Weak Master Key

attacker Gains access to the master key

Uses the old MasterKey to access the Vault

Copy of the MasterKey

Figure 6.3: Example of the masterkey replay attack

Evaluation For this attack, access to a Vault files is required, due to this reason, the Attack Vector metric is set to Local, the Privileges Required metric is set to Low. It is possible to perform the attack in a zero-click manner, in order for the master key backup to be created, the user must perform specific actions, so the User Interactivity is set to Required. Due to the simplicity of exploitation, Attack Complexity is set to Low. Since this attack gives the attacker full access to the masterkey, and eventually to data stored in the Vault, both Confidentiality and Integrity Impact are set to High. The resulting CVSS score of 6.6 falls into the Medium severity category.

Possible solution Currently, the only effective way to change a password without threatening data would be to create a new Vault from scratch. One way to solve this problem is to re-generate the encryption keys and sequentially re-encrypt the whole storage with a new key. This will lead to a degradation in the program performance, when the Vault size is too big.

6.3.3 File Contents Swap In this example, let us assume there are two different files in the same folder. Because the filename isn’t linked to the file content (see Section 2.2.4), those two files’ contents can be swapped. For example, swapping contents of a "readme" file and a private key would result in a fatal loss of data.

37 6. Source Code Analysis

Hence an attacker can change the files’ contents, hoping for the user to publish decrypted versions of secret files accidentally.

Evaluation For this attack, again, the Attack Vector metric is set to Local, the Privileges Required metric is set to Low. This kind of attack requires no user interaction, so the User Interactivity is set to None. Due to the simplicity of this attack, Attack Complexity is set to Low. This attack may potentially give access to decrypted sensitive Vault data, so the Confidentiality Impact is High. On of the main goals of this attack is to break data integrity, setting the Integrity Impact metric to High. The resulting CVSS score of 7.1 falls into the High severity category.

Possible solution A solution to this problem would be enforcing integrity checks for the file’s name and its content.

6.4 Summary

After examining crucial parts of the code, three potential vulnerabilities were found. Nevertheless, the studied cryptographic primitives are implemented correctly and in accordance with the relevant standards.

Password persistence in RAM – residual data, containing Vault • passwords, may remain in RAM

Masterkey Replay Attack – when changing a password, only KEK • is updated, leaving data vulnerable to a replay attack

File Contents Swap – file integrity checks are insufficient •

38 Chapter 7

Implementation

This chapter focuses on the reimplementation of the core functionalities of Cryptomator. The purpose of this implementation was to check whether the source code and executables provided by the Cryptomator team adhere to the program’s documentation and if there are any deviations in the program functioning. It was also useful for a better understanding of the architecture of the program and its functioning. An additional benefit of an independent implementation is giving the community a way to access their data in case Cryptomator ceases functioning.

7.1 Language

Swift language was used to verify the implementation. Swift is an open-source, cross-platform programming language developed by Apple. Swift is designed for safety and tries to eliminate some common programming mistakes at compile time: memory bugs like NULL pointer dereference, and integer overflows. Pointer and unsafe pointer operation are not exposed in Swift by default, making it easier to avoid memory-related problems.

7.2 Compatibility

At the moment of writing this thesis, the code is compatible with the latest versions of OSes provided by Apple: macOS, iOS, iPadOS, tvOS, and watchOS with more than 1.4 billion active devices. After making some alterations (like using Linux version of scrypt library), it would also be possible to compile the reimplementation on Linux distributions and Android. In this state, only CLI is supported, but making a GUI version, if needed, should not present a problem.

39 7. Implementation

7.3 Dependencies

Standard libraries provided by Apple were chosen for this reimplementation due to the open-source nature of Swift and Apple system libraries. [44, 45] libscrypt-kdf by Colin Percival was used for a password-based KDF scrypt.[24] No other third-party dependency is required to compile the code. Due to the nature of the reimplementation, a version of the SIV mode of operation needed to be written. It was done accordingly to the RFC specification with a test unit provided for testing against vectors provided by the document.

7.4 Functionality

Currently, the Vault version 6 is implemented with all functionality required for performing the basic operations: Vault creation, basic VFS operations: reading VFS structure, adding new files, and decrypting existing data.

7.5 Verification of correspondence

During the verification process, all critical operations, such as Vault creation, Vault unlocking with the Vault structure parsing, file/folder encryption, and decryption, were tested successfully. All Vaults created and managed by Cryp- tomator were accessible with the reimplementation and vice versa. Based on the results of the implementation testing, it is clear that Cryp- tomator conforms to its documentation. A total number of 50 different tests were conducted.

Figure 7.1: Cryptomator working with a Vault created by the reimplementa- tion

40 Chapter 8

Update

Just before the security analysis was completed, the Cryptomator team re- leased a new update, version 1.5.0. The new version features a revamp of the UI. After examination it was noticed that it fixes some of the issues found during the analysis described in Chapter 5 and Chapter 6. These fixes include: Minimum length of a password is set to eight • Added the ability to show password when typing • It is now possible to create a recovery key in the case when the password • is lost It is now easier to change a password • Zxcvbn library is updated and allows usage of CharSequence. This par- • tially solves the problem with passwords remaining in RAM

Figure 8.1: UI in version 1.5.0

41

Conclusion

This thesis aims to introduce the reader to the issue of storage encryption and the Cryptomator tool, including its security analysis. During the study of Cryptomator, I learned how encryption software works and expanded my knowledge of cryptography. The first chapter describs storage encryption theory. The commonly used methods and their comparison have also been described in this chapter. The most popular software was outlined at the end of the chapter. The purpose of the second chapter is to describe Cryptomator, its capabil- ities, and its architecture. The cryptographic primitives used in Cryptomator are defined later in the chapter. The third chapter presents the results of the two independent security audits. The first report conducted by Tim McLean discovered two medium- severity vulnerabilities in implementations of the SIV mode of operation and AES cipher. The other report did not uncover any major issues within Cryp- tomator. The last chapters deal with the analysis of program security from differ- ent angles: the UI, analysis of the essential parts of the source code, and verification of compliance between the Cryptomator’s documentation and its implementation. During the analysis, several problems were found in different parts of the program and described in this thesis. One of these problems is weak password strength checks and recommendations that violate ones provided by related standards. Problems with the password change functionality and file integrity checks were discovered. Own re-implementation using the provided documen- tation did not reveal any inconsistencies with the Cryptomator’s implementa- tion and the provided documentation. The more complex a system becomes, the more difficult it is to make it safer, so it is vital to conduct security analyzes on a continuing basis. [46] In the future, it might be possible to expand the thesis with a more comprehensive analysis of future updates and a closer examination of the source code.

43

Bibliography

[1] As the cloud’s popularity grows, so does the risk to sensi- tive data. Help Net Security, 2018, [Accessed: 15.06.2020]. Avail- able from: https://www.helpnetsecurity.com/2018/01/16/cloud- popularity-sensitive-data-risk/ [2] 43% of cloud databases are currently unencrypted. Help Net Security, 2020, [Accessed: 15.06.2020]. Available from: https://www.helpnetsecurity.com/2020/02/07/cloud-databases- unencrypted/ [3] Ruiz, D. There is No Middle Ground on Encryption. Electronic Frontier Foundation (EFF), 2018, [Accessed: 15.06.2020]. Available from: https://www.eff.org/deeplinks/2018/05/there-no-middle- ground-encryption [4] Galperin, E.; Kayyali, N.; et al. Dear NSA, Privacy is a fun- damental right, not reasonable suspicion. Electronic Frontier Foundation (EFF), 2014, [Accessed: 15.06.2020]. Available from: https://www.eff.org/deeplinks/2014/07/dear-nsa-privacy- fundamental-right-not-reasonable-suspicion [5] Scarfone, K.; Souppaya, M.; et al. Guide to storage encryption technolo- gies for end user devices. NIST Special Publication, volume 800, 2007: p. 111, [Accessed: 15.06.2020]. Available from: https://nvlpubs.nist.gov/ nistpubs/Legacy/SP/nistspecialpublication800-111.pdf [6] Stallings, W. Operating Systems: Internals and Design Principles. Pear- son Education, 2018.

[7] Tanenbaum, A. S.; Bos, H. Modern operating systems. Pearson, 2015.

[8] Rubens, P. Full Disk Encryption Buyer’s Guide. eSecurity Planet, 2012, [Accessed: 15.06.2020]. Available from: https:

45 Bibliography

//www.esecurityplanet.com/mobile-security/buyers-guide-to- full-disk-encryption.html

[9] Data Encryption | Jetico. 2020, [Accessed: 15.06.2020]. Available from: https://www.jetico.com/data-encryption

[10] Use FileVault to encrypt the startup disk on your Mac. Apple Support, 2018, [Accessed: 15.06.2020]. Available from: https:// support.apple.com/HT204837

[11] Best Practices for Deploying FileVault 2. Apple Technical White Paper, 2012.

[12] cryptsetup / cryptsetup GitLab. GitLab, 2020, [Accessed: 15.06.2020]. · Available from: https://gitlab.com/cryptsetup/cryptsetup/

[13] VeraCrypt - Free Open source disk encryption with strong security for the Paranoid. 2020, [Accessed: 15.06.2020]. Available from: https:// www.veracrypt.fr/en/Home.html

[14] Gaži, P.; Maurer, U. Cascade Encryption Revisited. [Accessed: 15.06.2020]. Available from: https://www.iacr.org/archive/ asiacrypt2009/59120035/59120035.pdf

[15] VeraCrypt - Free Open source disk encryption with strong security for the Paranoid. 2020, [Accessed: 15.06.2020]. Available from: https:// www.veracrypt.fr/en/Documentation.html

[16] Cryptomator - Free Cloud Encryption for Dropbox & Co. Cryptomator, 2020, [Accessed: 15.06.2020]. Available from: http://cryptomator.org

[17] FAQ. Cryptomator, 2020, [Accessed: 15.06.2020]. Available from: http: //cryptomator.org/faq/

[18] Cryptomator GitHub. GitHub, 2020, [Accessed: 15.06.2020]. Available · from: https://github.com/cryptomator/

[19] Architecture - Cryptomator. Cryptomator, 2020, [Accessed: 15.06.2020]. Available from: https://docs.cryptomator.org/en/1.4/security/ architecture/

[20] Aumasson, J.-P. Serious cryptography: a practical introduction to modern encryption. No Starch Press, 2017.

[21] Announcing the ADVANCED ENCRYPTION STANDARD (AES). Fed- eral Information Processing Standards Publication, volume 197, 2001, [Accessed: 15.06.2020]. Available from: https://nvlpubs.nist.gov/ nistpubs/FIPS/NIST.FIPS.197.pdf

46 Bibliography

[22] Dworkin, M. Recommendation for Block Cipher Modes of Op- eration: Methods and Techniques. NIST Special Publication, volume 800, 2001: p. 38A, [Accessed: 15.06.2020]. Avail- able from: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/ nistspecialpublication800-38a.pdf

[23] Harkins, D. Synthetic Initialization Vector (SIV) Authenticated Encryp- tion Using the Advanced Encryption Standard (AES). Request for Com- ments: 5297, 2008, [Accessed: 15.06.2020]. Available from: https: //tools.ietf.org/html/rfc5297

[24] Percival, C. STRONGER KEY DERIVATION VIA SEQUENTIAL MEMORY-HARD FUNCTIONS. 2009, [Accessed: 15.06.2020]. Available from: http://www.tarsnap.com/scrypt/scrypt.pdf

[25] Krawczyk, H.; Bellare, M.; et al. HMAC: Keyed-Hashing for Message Au- thentication. Request for Comments: 2104, 1997, [Accessed: 15.06.2020]. Available from: https://tools.ietf.org/html/rfc2104

[26] Secure Hash Standard (SHS). FIPS PUB 180-4, 2015, [Accessed: 15.06.2020]. Available from: https://nvlpubs.nist.gov/nistpubs/ FIPS/NIST.FIPS.180-4.pdf

[27] McLean, T. SIV Encryption Security Assessment. 2016, [Ac- cessed: 15.06.2020]. Available from: https://www.chosenplaintext.ca/ publications/20161104-siv-mode-report.pdf

[28] AES vulnerable to timing attacks. 2015, [Accessed: 15.06.2020]. Available from: http://www.bouncycastle.org/jira/browse/BJA-555

[29] Lipp, M.; Gruss, D.; et al. ARMageddon: Cache Attacks on Mobile De- vices. 2016, [Accessed: 15.06.2020]. Available from: https://arxiv.org/ pdf/1511.04897.pdf

[30] Securing the Enterprise with Intel R AES-NI. 2010, [Accessed: © 15.06.2020]. Available from: https://www.intel.com/content/dam/ doc/white-paper/enterprise-security-aes-ni-white-paper.pdf

[31] Heiderich, M.; Kobeissi, N. Pentest-Report Tresor Application Crypto. Cure53, 2017, [Accessed: 15.06.2020]. Available from: https:// cryptomator.org/audits/2017-11-27%20crypto%20cure53.pdf

[32] GitHub - cryptomator/siv-mode: RFC 5297 SIV mode of operation in Java. GitHub, 2020, [Accessed: 15.06.2020]. Available from: https:// github.com/cryptomator/siv-mode

47 Bibliography

[33] Password policy recommendations. Microsoft, 2020, [Accessed: 15.06.2020]. Available from: https://docs.microsoft.com/en-us/ microsoft-365/admin/misc/password-policy-recommendations

[34] Grassi, P.; Fenton, J.; et al. Digital Identity Guidelines: Authenti- cation and Lifecycle Management. NIST Special Publication, volume 800, 2020: p. 63B, [Accessed: 15.06.2020]. Available from: https: //pages.nist.gov/800-63-3/sp800-63b.html

[35] Grassi, P.; Fenton, J.; et al. Digital Identity Guidelines. NIST Special Publication, volume 800, 2020: pp. 63–3, [Accessed: 15.06.2020]. Available from: https://pages.nist.gov/800-63-3/sp800-63-3.html

[36] Common Vulnerability Scoring System version 3.1. FIRST — Fo- rum of Incident Response and Security Teams, 2019, [Accessed: 15.06.2020]. Available from: https://www.first.org/cvss/v3-1/cvss- v31-specification_r1.pdf

[37] NVD - CVSS v3 Calculator. NATIONAL VULNERABIL- ITY DATABASE, 2019, [Accessed: 15.06.2020]. Available from: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator

[38] Java Cryptography Architecture (JCA) Reference Guide. Oracle, 2020, [Accessed: 15.06.2020]. Available from: https://docs.oracle.com/en/ java/javase/11/security/java-cryptography-architecture-jca- reference-guide.html

[39] de Carné de Carnavalet, X.; Mannan, M. From very weak to very strong: Analyzing password-strength meters. In Network and Distributed System Security Symposium (NDSS 2014), Internet Society, 2014, [Ac- cessed: 15.06.2020]. Available from: https://www.ndss-symposium.org/ wp-content/uploads/2017/09/06_3_1.pdf

[40] GitHub - cryptomator/cryptolib: Cryptomator Crypto Library. GitHub, 2020, [Accessed: 15.06.2020]. Available from: https://github.com/ cryptomator/cryptolib

[41] GitHub - cryptomator/cryptomator: Cryptomator. GitHub, 2020, [Ac- cessed: 15.06.2020]. Available from: https://github.com/cryptomator/ cryptolib

[42] Pilkey, A. The Chilling Reality of Cold Boot Attacks. 2018, [Accessed: 15.06.2020]. Available from: https://blog.f-secure.com/cold-boot- attacks/

[43] Blocking the SBP-2 driver and Thunderbolt controllers to reduce 1394 DMA and Thunderbolt DMA threats to BitLocker. 2018, [Accessed:

48 Bibliography

15.06.2020]. Available from: https://support.microsoft.com/en- gb/help/2516445/blocking-the-sbp-2-driver-and-thunderbolt- controllers-to-reduce-1394-d

[44] Apple GitHub. GitHub, 2020, [Accessed: 15.06.2020]. Available from: · https://github.com/apple/

[45] Apple Open Source. Apple, 2020, [Accessed: 15.06.2020]. Available from: https://opensource.apple.com

[46] Schneier, B. A Plea for Simplicity. Schneier on Security, 1999, [Accessed: 15.06.2020]. Available from: https://www.schneier.com/ essays/archives/1999/11/a_plea_for_simplicit.html

49

Appendix A

Acronyms

AD Associated Data

AES Advanced Encryption Standard

ASCII American Standard Code for Information Interchange

CMAC Cipher-Based Message Authentication Code

CTR Counter mode of operation

CSPRNG Cryptographically Secure Pseudorandom Number Generator

DES Data Encryption Standard

DMA Direct Memory Access

DRAM Dynamic Random-Access Memory

FCK File Content Key

FDE Full Disk Encryption

GPT GUID Partition Table

HMAC Hash-Based Message Authentication Code

IV Initialization Vector

JSON JavaScript Object Notation

KDF Key Derivation Function

KEK Key Encryption Key

LUKS Linux Unified Key Setup

MAC Message authentication code

51 A. Acronyms

NIST National Institute of Standards and Technology

OS Operating System

PBE Pre-Boot Environment

PIN Personal Identification Number

PRNG Pseudorandom Number Generator

RAM Random Access Memory

ROM Read Only Memory

RFC Request For Comments

SIV Synthetic Initialization Vector

SSD Solid-State Drive

SSO Single Sing-On

UI User Interface

UID Unique Identifier

USB Universal Serial Bus

VDE Virtual Disk Encryption

VFS Virtual File System

52 Appendix B

Contents of enclosed SD

readme.txt...... the file with SD contents description exe ...... the directory with executables src...... the directory of source codes bp-cryptomator ...... implementation sources thesis...... the directory of LATEX source codes of the thesis text...... the thesis text directory thesis.pdf...... the thesis text in PDF format

53