Spideroak's Crypton: Design and Implementation Evaluation
Leviathan recently took a critical look at a technology currently in development by SpiderOak called Crypton. Crypton, an open-source project hosted on github, aims to be a zero-knowledge, cryptographically-secure storage framework upon which zero-knowledge cloud applications can be written. Its primary functional goal is to provide assurance that data stored on the server can only be read by the client who possesses the key and cannot be read by the server or anyone else.
For the version Leviathan reviewed, Crypton was still in development, and we would characterize its readiness as “pre-alpha.” As we write this, major components are still being written while others are being rewritten. With that in mind, we were tasked with reviewing two parts of the Crypton framework: a feature called “Sharing” and Crypton’s implementation of the Secure Remote Password (SRP) protocol. Since time allowed, we also reviewed the non-SRP login procedures.
Crypton consists of a server and a client, both of which are written in Javascript. The server code, running on node-js, accepts requests from the client and stores or retrieves the appropriate information from a database. The client does most of the heavy lifting; it encrypts, decrypts, signs, and verifies all the user-supplied data. In its current form the client code is pushed to the browser from the server. SpiderOak’s true implementation target is for the client code to be in a browser extension or mobile app. An unusual part of Crypton’s threat model is that server itself is considered untrusted. That is to say, in all scenarios we anticipated that the server could be acting against the clients. As such, the clients should not trust anything the server gives them. This attribute of the system strongly shaped our assessment.
SECURE REMOTE PASSWORD (SRP)
SRP, defined by RFC 2945, is an authentication protocol whereby clients do not reveal their password to the server. SRP is also resistant to replay and man-in-the-middle attacks. We encourage readers to review the brief RFC to understand the workings of the protocol. Unfortunately, SRP is not designed to resist modern password cracking attacks – the Verifier1, as defined by the RFC, is merely two rounds of SHA1 plus a modular exponentiation; we would not describe this as robust against modern cracking techniques and tools. As a result, when we consider the scenario for Crypton where the server is malicious, the server itself could execute password cracking attacks against the verifier to gain decryption keys to a user’s information. While Crypton’s implementation used SHA256 instead of SHA1, we recommended use of bcrypt as the hash function. Bcrypt is well-known for being computationally intensive, which results in improved password cracking resistance.
PRIMARY SECURITY ISSUES
With an understanding of what Crypton intends to be and generally how it works, we examined it with a critical eye and observed places where things could go wrong. Upon successful login, the server sends the client its encrypted account information. The client then generates its master decryption key and begins decrypting its account information. Three key issues were observed.
First, the account’s public key is stored without verification that it corresponds to the decrypted private key; this could allow the server to replace it which would result in the user encrypting messages to themselves that they cannot actually decrypt.
Second, we saw the same issue with the account’s public signing key; it is not being verified against the decrypted private signing key.
Third, the containerNameHmacKey is not verified before decryption which means that the server could actually replace it with a different one that it knows by encrypting a new symmetric key to the user’s public key.
CRYPTON’S UNSOLVED PROBLEM
Every user-to-user encrypted messaging platform (including OTR, Cryptocat, and TextSecure) has authentication limitations. Users are not fully sure that they are talking to the intended party. Crypton is no different – since the server cannot be trusted, a given client cannot be sure the server is sending the correct public key when they first interact with another user. Each of the aforementioned platforms handle this problem in its own way, and we look forward to seeing what kind of innovative method Crypton implements to handle this.
TAKEAWAYS
Crypton is an ambitious and novel platform. To our knowledge, no one else has set out to create a similar framework for building future secure cloud applications. Based on the state of Crypton at the time of Leviathan's review, the groundwork seemed to be nearly complete, and the development team stated that it is working on significant improvements to the developer’s experience. In particular, the team has already figured out how to index encrypted data to allow for searchable diary entries. They are in the process of creating higher-level libraries to handle complex data structures and algorithms, all implemented atop the encrypted block storage provided by Crypton.
Throughout the review we had an ongoing conversation with Crypton’s developers about the kinds of real-world applications one might build using their technology. A particularly interesting example was that of a zero-knowledge, encrypted cloud calendaring system (which we do not believe currently exists). Crypton provides the framework for building such a system, and we are excited to see what other previously-infeasible applications creative developers will build upon the features Crypton provides.
EDIT (04/18/14): Last week we blogged about our recent security review of SpiderOak’s Crypton framework. As part of that assessment, we observed vulnerabilities within Crypton and reported them back to SpiderOak to mitigate. Included in the report was an informational finding/recommendation unrelated to the security of the framework but included as a possible optimization. Public feedback around this recommendation noted that it included technical inaccuracies such that it did not apply to Crypton. Since it did not directly relate to the security of the framework, we decided to remove it from the report. We then added the following note: ‘A previous version of this report contained a non-security finding. As this finding has no bearing on the security of the system, it has since been removed.’ We remain excited about the potential benefits of Crypton and look forward to seeing the product develop.
Download the full report here: SpiderOak-Crypton_pentest-Final_report
1 The Verifier (v) is defined as:
x = SHA(<salt> | SHA(<username> | ":" | <raw password>))
v = g^x % N