Electronic Frontier Foundation Rates WhatsApp, Snapchat, Skype, Low for Security
Having secure communications is important in today’s day and age, particularly after Edward Snowden’s NSA revelations increased public awareness in abusive government snooping of personal communications. There are also a lot of messaging tools to choose from, so it can be hard to find one that’s trustworthy.
The Electronic Frontier Foundation (EFF) has published its Secure Messaging Scorecard, an extensive list that rates a number of apps and services we use every single day according to the level of security they offer.
Of note is the number of messaging apps that received low scores for protecting users and their communication data. These include Skype, Snapchat, Facebook Messenger, and WhatsApp, the latter two of which are owned by Facebook.
“Many new tools claim to protect you, but don’t include critical features like end-to-end encryption or secure deletion,” said EFF’s Technology Projects Director Peter Eckersley. “This scorecard gives you the facts you need to choose the right technology to send your message”.
Many new tools claim to protect you, but don’t include critical features like end-to-end encryption or secure deletion
So what does the EFF look for when scoring these apps? Seven things, in fact:
- Is your communication encrypted in transit?
This criterion requires that all user communications are encrypted along all the links in the communication path. Note that we are not requiring encryption of data that is transmitted on a company network, though that is ideal. We do not require that metadata (such as user names or addresses) is encrypted.
- Is your communication encrypted with a key the provider doesn’t have access to?
This criterion requires that all user communications are end-to-end encrypted. This means the keys necessary to decrypt messages must be generated and stored at the endpoints (i.e. by users, not by servers). The keys should never leave endpoints except with explicit user action, such as to backup a key or synchronize keys between two devices. It is fine if users’ public keys are exchanged using a centralized server.
- Can you independently verify your correspondent’s identity?
This criterion requires that a built-in method exists for users to verify the identity of correspondents they are speaking with and the integrity of the channel, even if the service provider or other third parties are compromised. Two acceptable solutions are:
- An interface for users to view the fingerprint (hash) of their correspondent’s public keys as well as their own, which users can verify manually or out-of-band.
- A key exchange protocol with a short-authentication-string comparison, such as the Socialist Millionaire’s protocol.Other solutions are possible, but any solution must verify a binding between users and the cryptographic channel which has been set up. For the scorecard, we are simply requiring that a mechanism is implemented and not evaluating the usability and security of that mechanism.
- Are past communications secure if your keys are stolen?
This criterion requires that the app provide forward-secrecy, that is, all communications must be encrypted with ephemeral keys which are routinely deleted (along with the random values used to derive them). It is imperative that these keys cannot be reconstructed after the fact by anybody even given access to both parties’ long-term private keys, ensuring that if users choose to delete their local copies of correspondence, they are permanently deleted. Note that this criterion requires criterion 2, end-to-end encryption.
- Is the code open to independent review?
This criterion requires that sufficient source-code has been published that a compatible implementation can be independently compiled. Although it is preferable, we do not require the code to be released under any specific free/open source license. We only require that all code which could affect the communication and encryption performed by the client is available for review in order to detect bugs, back doors, and structural problems.
Note: when tools are provided by an operating system vendor, we only require code for the tool and not the entire OS. This is a compromise, but the task of securing OSes and updates to OSes is beyond the scope of this project.
- Is the crypto design well-documented?
This criterion requires clear and detailed explanations of the cryptography used by the application. Preferably this should take the form of a white-paper written for review by an audience of professional cryptographers. This must provide answers to the following questions:
- Which algorithms and parameters (such as key sizes or elliptic curve groups) are used in every step of the encryption and authentication process
- How keys are generated, stored, and exchanged between users
- The life-cycle of keys and the process for users to change or revoke their key
- A clear statement of the properties and protections the software aims to provide (implicitly, this tends to also provide a threat model, though it’s good to have an explicit threat model too). This should also include a clear statement of scenarios in which the protocol is not secure.
- Has there been an independent security audit?
This criterion requires an independent security review has been performed within the 12 months prior to evaluation. This review must cover both the design and the implementation of the app and must be performed by a named auditing party that is independent of the tool’s main development team. Audits by an independent security team within a large organization are sufficient. Recognizing that unpublished audits can be valuable, we do not require that the results of the audit have been made public, only that a named party is willing to verify that the audit took place.
the apps featured were chosen to represent those used most frequently
Facebook Messenger only checked a couple of boxes (in-transit encryption and code auditing), and it was the same story for Google Hangouts and SnapChat. Skype scored points for not only encrypting data, but also keeping it from Microsoft‘s eyes, but failed in the remaining five categories. Signal, TextSecure, Silent Phone, CryptoCat, Silent Text, and ChatSecure + Orbot all passed every test, while QQ and Mxit failed on every single count.
The lengthy list of communication tools was chosen to represent those used most frequently and according to the EFF is meant to increase focus “on improving the tools that everyday users need to communicate with friends, family members, and colleagues. We hope the Secure Messaging Scorecard will start a race-to-the-top, spurring innovation in stronger and more usable cryptography.”
Will the EFF scorecard make you switch to a more secure messaging app?