(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.)
The information on this page is now outdated; it is kept only as a record of our original post. The revised post contians the most up-to-date information.
Written: 2016-12-22 (Updated 2017-03-28)
Update (2016-12-29): After this page was originally posted, Wire sent us a response. We have updated this text to incorporate their clarifications. Each point now also includes a summary (written by us) of Wire's response. The original article text and Wire's full response are available in the response document.
Update 2 (2017-03-28): Wire recently updated their calling protocol to add end-to-end authentication and constant bitrate encoding.
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. However, there are a few problems with the system and its specification that cause or suggest security weaknesses. Most of these problems come from the description in the whitepapers—if the actual app avoids the problems, then the documentation is merely incomplete. These problems should not be too difficult to fix, but they should be addressed before users rely on Wire for protecting their communications.
Issues (roughly in order of decreasing severity):
-
No call authentication.
When securing a conversation, confidentiality (hiding the contents of the conversation) is not the only desirable property.
Without also authenticating the conversation, an attacker located in the network (e.g., a malicious actor intercepting traffic on a user's LAN, or a compromised ISP) can insert themselves between the endpoints.
Wire provides both properties for text-based conversations.
The Wire protocol uses SRTP to secure audio/video calls. SRTP requires an external mechanism to establish the initial cryptographic key to protect the data. Wire uses a DTLS handshake to establish this initial key. DTLS is a UDP-based analog of TLS (used to secure HTTPS web browsing). Consequently, the key exchange in a DTLS handshake needs to be authenticated by a certificate authority, as in the case of web certificates. The certificates used by Wire for this DTLS handshake are self-signed. This means that the audio/video calls are vulnerable to man-in-the-middle attacks by the Wire operators (but not to arbitrary network attackers).
The use of DTLS here is highly unusual and the security it provides is sub-optimal. A better approach would be to use a protocol like ZRTP (the standard used by Signal, Jitsi, Linphone, and others) to establish the initial SRTP key, or perhaps a more advanced key exchange scheme. The authentication for this scheme should not be based on certificates (as in DTLS); instead, the authentication should be bound to the long-term keys that are used by Wire's text-based conversations. A very simple solution would be to transparently perform a well-known unauthenticated key exchange (e.g., Diffie-Hellman) over an authenticated Wire text conversation, and to use the resulting key to initiate SRTP for the audio/video call.
The Wire security whitepaper mentions that authenticating audio/video calls against the cryptographic identities used for the text messaging protocol is future work, so this issue appears to be known.Response summary: Calls are authenticated by the Wire server, but, as noted above, there is no end-to-end authentication. This is a known limitation in Wire that will be addressed in the coming weeks. DTLS-SRTP is used in WebRTC. Since Wire was designed to work in a web browser and ZRTP is not in the WebRTC standard, DTLS-SRTP was a natural choice. In the future, public DTLS keys will be transmitted over the end-to-end encrypted and authenticated text channel, thereby providing end-to-end authentication for calls. - Questionable codecs:
It has been known for some time (e.g., WMM06, WBMM07, and WMSM11) within the system security academic community that using variable-bitrate codecs within an encrypted tunnel leaks information about the communication.
Since encryption does not hide the length of the messages being transmitted, the bitrate of a conversation over time can be observed by a passive network attacker, even without access to the encryption keys in use.
In some cases, knowledge of the bitrate changes is sufficient to reconstruct the unencrypted conversation with high accuracy.
Consequently, while variable-bitrate codecs use the available bandwidth more efficiently, using constant-bitrate codecs is important for security.
The security whitepaper mentions that Wire uses the Opus codec to transmit audio data. The whitepaper does not mention what codec is used for video data. Opus supports both variable- and constant-bitrate encodings, but Wire chooses to use the variable-bitrate encoding. Wire should ensure that constant-bitrate codecs are used for both audio and video data, and that this is clearly stated in the security whitepaper.Response summary: Wire has previously addressed this question. They consider the efficacy of attacks against variable-bitrate codecs to be questionable for streaming (i.e., not pre-recorded) calls. Since variable-bitrate encoding makes better use of network resources, Wire chooses to use it to improve call quality. If the attacks become better, Wire may add an option to use constant-bitrate codecs. - 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.Response summary: 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.Response summary: 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 is open source—and open to analysis by security researchers—but the server software is not.
Response summary: The server code will be released in Q1 2017.
The problems listed above weaken the security of Wire relative to competitors like Signal, but the problems are not insurmountable. The chat features offered by Wire have a very modern aesthetic that is very popular with users, and this makes Wire a very interesting offering. Users should be aware of these concerns before choosing to use Wire. While these problems are unaddressed, users should avoid using Wire audio/video calls for secure conversations, assume that Wire passwords could be silently compromised, treat the Wire application like a constantly updating web service rather than a semi-stable desktop application, and consider sandboxing Wire on sensitive systems.
