Wire

(This post was written by a researcher in the Cryptography, Security, and Privacy (CrySP) lab at the University of Waterloo. The opinions expressed here do not necessarily reflect the opinions of other CrySP researchers or the university.)

Written: 2016-12-22 (Updated 2018-02-21)

Update (2018-02-21): After our original post, Wire updated their calling protocol to add end-to-end authentication and constant bitrate encoding. The server code was also released. This page now reflects the current state of the protocol. For our original post, including Wire's original response, see the archived version.

Recently, the Wire secure messaging application has received increased attention from the media and the public. In the wake of the Snowden revelations, we have seen the release of many secure messaging platforms, each claiming to offer excellent security features. Unfortunately, it is often difficult to evaluate the truth of these claims. We have also seen multiple instances where users place their trust in flawed or outright broken systems based on word-of-mouth recommendations or shallow media endorsements.

Luckily, Wire has behaved responsibly in this respect. Unlike many of their competitors, they published security and privacy whitepapers explaining the operation of their system. Allowing a protocol to be openly evaluated by security researchers is an important part of building a secure system.

The design of the Wire protocol as described in the whitepapers is relatively good. Additionally, the changes made to the protocol since our original post have substantially improved the security of the system. Only a few of our minor complaints remain.

Issues (roughly in order of decreasing severity):

• No call authentication. Wire now offers end-to-end authentication for voice and video calls.
• Questionable codecs: Wire now provides a user option (disabled by default) to use constant-bitrate codecs, which prevents some sophisticated eavesdropping attacks.
• Web-style account authentication: The Wire client authenticates with a central server in order to provide user presence information. (Wire does not attempt to hide metadata, other than the central server promising not to log very much information.) The Wire whitepapers spend an unusual amount of space discussing the engineering details of this part of the protocol. However, the method of authentication is the same as it is on the web: the Wire client sends the unencrypted, unhashed password to the central server over TLS, the server hashes the plaintext password with scrypt, and the hash is compared to the hash stored by the server. This process leaks the user's password to the central server; the server operators (or anyone who compromises the server) could log all of the plaintext passwords as users authenticate.
  
  Wire likely designed the protocol this way in order to make it easier to support web-based clients. Authentication mechanisms like this are standard on the web for historical reasons. However, since Wire has complete control over both the client software and the protocol, it is possible to do better. Wire should use a password-authenticated key agreement or a more sophisticated challenge/response protocol for user authentication. The advantage of these schemes is that they authenticate users without making the passwords vulnerable to data breaches on the central server. While the system would still be vulnerable to attackers capable of releasing malicious Wire updates, this would be a significant improvement.
  Summary of Wire's response: This authentication design comes from the desire to make Wire work in a web browser. Wire has looked at alternatives and is considering improving the protocol.
• Code structure and complexity: The Wire implementation is extremely complex, making the attack surface relatively large. The desktop application is implemented as a packaged web application. Each time that the application is launched, large parts of the code (written in JavaScript) are re-downloaded and executed from the Wire servers without user interaction. Essentially, the Wire app itself is merely an embedded web browser. There does not appear to be any notion of "JavaScript pinning".
  
  A common weakness of all secure messaging applications is that the application must be downloaded, trusted, and updated regularly; if the update mechanism is ever compromised, the system can be made to arbitrarily deviate from the specifications to the benefit of the attacker. However, the current design of the Wire desktop application makes such attacks simple, difficult to detect, and rapid. Moreover, the complexity of the application and its libraries presents many opportunities for security vulnerabilities. While this complexity may be necessary to support the rich feature integrations of the platform and the broad system support, the cost is more opportunity for exploitation.
  Summary of Wire's response: The most important component—the encryption library Proteus—has been audited several times. As mentioned above, this problem generally applies to all secure messaging applications. The Wire client is open source and can be built without relying on any server. Wire is aware of this general weakness and is exploring improvements.
• Closed-source server: The Wire client and server are now open source—and available for analysis by security researchers.

The remaining issues with Wire are relatively minor and also affect many of its competitors. Users should treat Wire passwords like they treat passwords for websites (e.g., use a strong and unique password for Wire). Users should treat the Wire application like a constantly updating web service rather than a semi-stable desktop application. Expert users operating on sensitive systems should consider sandboxing all Internet-enabled applications, including Wire. The recent improvements to the Wire protocol and Wire's admirable response to our original posting are welcome and inspire confidence in the team.

The chat features offered by Wire have a modern aesthetic that is very popular with users, and this makes Wire a very interesting offering. At this time, the security offered by the Wire protocol is comparable to Signal, and some aspects of the user experience are superior (e.g., Wire does not require the use of phone numbers as identifiers). Users should consider Wire as a good alternative to other secure messaging systems, and users of insecure platforms like text messaging should strongly consider the use of secure messaging applications.