Recent Audits and Coming Improvements

We’re excited to announce that Cryptocat has received two more audits of its codebase. Maintaining our responsibility of making encrypted chat not only fun, cute, and more fuzzy, but also transparently secure and dependable, we were able to solicit two more code audits from the experts at Least Authority and iSec Partners.

The audits covered Cryptocat’s web client, and also an early, pre-release (therefore buggy) version of Cryptocat for iPhone. These audits would have not been possible without the crucial support of the Open Technology Fund. We were capable of fixing bugs in the pre-release iPhone version before release thanks in large parts to these audits. The Open Technology Fund has released a statement about this audit on their website.


Main Issues Identified

While the audits identified a variety of issues that needed to be fixed or that could be improved upon, there were two main issues that pertained to Cryptocat on a wider scope: authentication and file transfer.

Necessary Improvements to Authentication

A prevalent theme in both audits was that Cryptocat’s authentication mechanism, while not broken outright, was severely lacking. This was due to the following factors:

Ephemeral Key Identity: Cryptocat relies on completely ephemeral keys. This means that no keys are ever stored permanently, and therefore there is no permanent key identity. This provides many positive properties: no permanent identity that can be traced back to an individual, perfect forward secrecy, and the negation of the risk of physically-stored key compromise. However, this also translates into Cryptocat users having to re-authenticate every time, which can be especially taxing on group conversations with multiple participants. In the audits, it is argued that depending users to re-authenticate every time is unrealistic, and therefore a bigger risk than storing permanent keys.

No Re-Key Warning for Private Conversations: For private conversations (OTR,) the authentication interface does not warn users when an authenticated key exchange occurs resulting in a different key fingerprint. This lack of warning could effectively override a previous successful authentication, and could therefore allow a successful man in the middle attack to occur. This is a problem that can be exploited in some real-world scenarios and needs to be addressed with appropriate authentication warnings. Thanks to these audits, this issue was caught in Cryptocat for iPhone before it was released. Therefore, unlike the desktop version, Cryptocat for iPhone was never affected by this issue.

Insufficient Authentication UI: Cryptocat’s authentication interface provides access to a user’s key fingerprints and a dialog for question-based SMP authentication. While in theory this does allow users to fully authenticate, the authentication interface remains lacking in the following ways:

  1. No deeper integration into the user interface. Users can easily ignore the necessity of authentication due to the lack of visual cues and reminders regarding the current authentication status of a conversation. Since Cryptocat targets users with no prior experience in encryption, this is a particularly relevant concern.
  2. The importance and significance of authentication is not emphasized. We have no guarantee that Cryptocat’s users understand that authentication is important, or even what it means to authenticate a contact.

The combination of these issues, the minimal authentication UI, and some shortcomings in how nicknames were handled in Cryptocat can lead to the easier deception of Cryptocat users when it comes to an attacker assuming the identity of another Cryptocat conversation participant. This was demonstrated by the audits (and the discussions were also posted on GitHub here, here and here). Fixing code-layer bugs can only go so far — how are we going to address the interaction aspect involved with these authentication issues?

Cryptocat’s New Authentication Interface

In the upcoming update slated for next week, Cryptocat will show authentication icons next to every message from every users. Users that are not authenticated will have a red “!” next to their messages. Hovering over that icon will prompt a user to authenticate. Clicking it opens the new authentication dialog:

In this update, the question-based (SMP) authentication method now authenticates users for both group and private conversations. In the past, question-based authentication only affected private conversations, and the audits revealed that this could be confusing to users. The new authentication dialog also offers a “Learn more about authentication” button. Clicking it displays our new authentication tutorial, a fun cartoon slideshow explaining authentication and translated into Cryptocat’s 38 languages.

The slideshow was designed by the wonderful Ingrid Burrington, who has previously collaborated with Cryptocat on design. Finally, we also added warnings to address exceptions such as a suspicious re-keying:

While we’re very excited to roll out Cryptocat’s new authentication interface, and while we feel it helps address many of the shortcomings of authentication in Cryptocat, we’re aware that it still does not address the issue of ephemeral key identities. This is something that is still being discussed and is complicated by the open questions of secure key storage in the browser.

The relevant GitHub issues are #475, #580 and #594, with relevant commits also spread around in the commit history.

File Transfer: CTR Mode, There and Back Again

Cryptocat was the first project to have an implementation of OTR that used OTR’s extra symmetric key for encrypted file transfer. While our proposed file transfer specification was internally reviewed and was deemed likely sound, we found that implementation issues existed in Cryptocat’s file transfer features. We were hinted towards the existence of these issues many months ago, and therefore file transfer has been disabled in Cryptocat since last year.

Since Cryptocat’s file transfer specification depended on AES in CTR mode, re-keying between every file transfer is essential. While the implementation is indeed programmed to re-key between every file transfer, it was possible to circumvent the re-keying process, thereby exposing some files to the classic same-key-same-nonce vulnerability that CTR mode is known for. This could be done in several ways: sending multiple files in succession without messages in between, or by operating a malicious server that selectively dropped messages in such a way that prevented re-keying.

We’ve previously had security issues with CTR nonce re-use, as have many projects — this is a tricky vulnerability that is likely to pop up when deploying complex cryptographic systems using AES-CTR. Therefore, we’re happy to have been able to catch it early on and disable file transfer in Cryptocat at an early stage. Currently, we are moving towards implementing the OTRDATA specification in Cryptocat as an alternative that may prove more resistant to attacks. The relevant GitHub discussions for vulnerabilities in file transfer are at #575 and #576.


Smaller-Scope Issues Identified

In addition to the above issues, which involve Cryptocat in a general scope, many localized, smaller-scope issues were identified:

  1. iOS Saves Screenshots on Backgrounding: By default, iOS saves screenshots of apps on disk before switching to another app. This allows iOS to show a preview of the backgrounded app when switching back, but also means that screenshots of your private chats could be saved locally on disk. We were very glad to be alerted of this issue and fixed it before Cryptocat for iPhone was released.
  2. XMPP Connection Issues: Cryptocat for iPhone was vulnerable to StartTLS stripping, which could prevent the correct initiation of a TLS connection. Thanks to these audits, we were able to fix this issue before release.
  3. XMPP Configuration Issues: Cryptocat’s default server configuration had some suboptimal settings, such as storing a conversation’s ciphertext for a short period of time. These issues were fixed.
  4. Crashes and Miscellaneous: Malformed Cryptocat messages could sometimes cause crashes, and malformed nicknames could allow attackers to crash clients or silently view conversation ciphertext (only ciphertext, which is already accessible to the server.) The most severe of these crashes were fixed before release, while the less severe ones are being currently worked on.
  5. Other issues: The audits were quite thorough, and other, smaller issues were identified and fixed.

Since the audit concerning Cryptocat for iPhone was performed on an early, pre-release version, many of the bugs it found are overly silly (leftover debug logging of messages and keys, for example). Still, while the iPhone audit concerns a pre-release version with many typical pre-release bugs, many of the bugs described above did affect Cryptocat for iPhone, and it was thanks to these audits that we were able to catch them and fix them before Cryptocat for iPhone was released. We owe immense thanks to iSec Partners, Least Authority and the Open Technology Fund for arranging and providing this amazing opportunity to Cryptocat and its users.


On the Significance of Audits

For the past two years, Cryptocat has been open regarding security and audits to the degree that we may very well be the most transparently developed encryption project in the world. We are proud of this. We believe that there is a general reticence in the field to openly publish audits or to openly discuss fixing vulnerabilities or improving encryption and security. This reticence is damaging to the opportunity for honest evaluation, cooperation and the establishment of a realistic perception of encryption software. It also misleads users.

Since Cryptocat carries out its specification, development and auditing in an unusually transparent degree, the impression may be that since Cryptocat is the only project publishing audits and discussing vulnerabilities, Cryptocat must be the only project with vulnerabilities in the first place. However, if other encryption projects followed our lead and fully published all audits, made all cryptographic decisions and specifications fully available for open discussion, and fully elaborated on vulnerabilities and how to fix them, users can benefit from a more honest and true perception of how encryption software is really developed, and what to expect, even if it comes at the expense of the prestige and competitive marketing potential of the software itself. Honesty is important.

There is also the danger of the false belief that if encryption software is audited by experts once, then that is enough for it to be considered reliable. Programming encryption software is a highly complex human endeavour, and deploying a piece of software to a hundred thousand users with a hundred thousand different use-cases further contributes to this complexity. We believe that the best progress towards reliable security can only be achieved via open review, stringent repeat audits, and a transparent, inclusive development process.

Download the full audit documents here.

Aside from the improvements mentioned in this post, we are still working on our mpOTR project, which aims to provide a truly global encryption protocol for group messaging. We’re looking forward to rolling out many updates to help make encryption more fun, accessible and useful for everyone in the world who expects the Internet to offer them a trustworthy feline friend for their private conversations.