{"id":254367,"date":"2018-04-01T15:32:56","date_gmt":"2018-04-01T13:32:56","guid":{"rendered":"https:\/\/mybroadband.co.za\/news\/?p=254367"},"modified":"2018-04-01T15:33:42","modified_gmt":"2018-04-01T13:33:42","slug":"building-a-secure-messaging-app","status":"publish","type":"post","link":"https:\/\/mybroadband.co.za\/news\/security\/254367-building-a-secure-messaging-app.html","title":{"rendered":"Building a secure messaging app"},"content":{"rendered":"

By EFF<\/a> Deeplinks Blog<\/em><\/p>\n

Given different people\u2019s and community\u2019s security needs, it\u2019s hard to arrive at a consensus of what a \u201csecure\u201d messenger must provide. In this post, we discuss various options for developers to consider when working towards the goal of improving a messenger\u2019s security.<\/p>\n

A messenger that\u2019s perfectly secure for every single person is unlikely to exist, but there are still steps that developers can take to work towards that goal.<\/p>\n

Messengers in the real world reflect a series of compromises by their creators. Technologists often think of those compromises in terms of what encryption algorithms or protocols are chosen. But the choices that undermine security in practice often lie far away from the encryption engine.<\/p>\n

Encryption is the Easy Part<\/b><\/h3>\n

The most basic building block towards a secure messenger is\u00a0end-to-end encryption<\/b>. End-to-end encryption means that a messenger must encrypt messages in a way that nobody besides the intended recipient(s)\u2014not messaging service providers, government authorities, or third-party hackers\u2014can read them.<\/p>\n

The actual encryption is not the hard part. Most tools use very similar crypto primitives (e.g. AES, SHA2\/3, and ECDH). The differences in algorithm choice rarely matter. Apps have evolved to use very similar encryption protocols (e.g. Signal’s Double Ratchet). We expect that any application making a good-faith effort to provide this functionality will have published a documented security design.<\/p>\n

Beyond encryption, all that\u2019s left are the remaining details of product trade-offs and implementation difficulties, which is where the hottest debate over secure messaging lies.<\/p>\n

Next: Important Details That Are Hard to Perfect<\/b><\/h3>\n

Every secure messaging app has to worry about\u00a0code quality<\/b>,\u00a0user experience<\/b>, and\u00a0service availability<\/b>. These features are hard to perfect, but putting no effort into them will render an application unusable.<\/p>\n

When it comes to encrypted messaging apps, there\u2019s a big difference between the theoretical security they provide and the practical security they provide. That\u2019s because while the math behind an encryption algorithm may be flawless, a programmer may still make mistakes when translating that math into actual code. As a result, messengers vary in their implementation quality\u2014i.e. how well the code was written, and how likely the code is to have bugs that could introduce security vulnerabilities.<\/p>\n

Code quality is particularly hard to assess, even by professional engineers. Whether the server and client codebases are open or closed source, they should be regularly audited by security specialists. When a codebase is open source, it can be reviewed by anyone, but it doesn\u2019t mean that it has been, so being open source is not necessarily a guarantee of security. Nor is it a guarantee of insecurity: modern cryptography doesn\u2019t require the encryption algorithm to be kept secret to function.<\/p>\n

User experience quality can also vary, specifically with regard to the user\u2019s ability to successfully send and receive encrypted messages. The goalpost here is that the user always sends messages encrypted such that only the intended recipients can read them. The user experience should be designed around reaching that goal.<\/p>\n

While this goal seems straightforward, it\u2019s difficult to achieve in practice. For example, say Alice sends a message to Bob. Before Bob can read it, he gets a new phone and has to update his encryption keys. Should Alice\u2019s phone re-send the message to Bob\u2019s new phone automatically, or wait for Alice to approve Bob\u2019s new encryption keys before resending the message?<\/p>\n

What if Bob\u2019s sister shoulder-surfed his password and signed into his account on her phone? If Alice\u2019s phone re-sends the message on her behalf, she risks accidentally sending it to Bob\u2019s sister instead of Bob.<\/p>\n

Different applications might have different priorities about message delivery versus sticking to encryption guarantees, but we expect applications to make thoughtful choices and give advanced users the option to choose for themselves.<\/p>\n

Like seatbelts and two-factor authentication, the biggest failure mode of secure messengers is not using them at all. If a tool fails to reliably deliver messages in congested or hostile network conditions, users may be forced to fall back to less secure channels. Building a reliable service takes consistent, applied engineering effort that smaller services might not have the resources for, but it\u2019s essential to ensuring the user\u2019s security.<\/p>\n

Adding Security Features<\/b><\/h3>\n

Past these basic tenets of implementation and user experience, the discussion becomes thornier. Security benefits can get left behind when they\u2019re deemed to not be worth the cost to implement or when they\u2019re judged as detrimental to ease of use. We recommend considering some features in particular to create a more robust secure messenger.<\/p>\n

Modern messengers store conversation histories in the cloud. If a secure messenger stores the conversation history unencrypted in the cloud (or encrypted under information that the service provider can access), then the messenger might as well not have been end-to-end encrypted.<\/p>\n

Messengers can choose to\u00a0encrypt the backups\u00a0<\/b>under a key kept on the user\u2019s device or a password that only the users know, or it can choose to not encrypt the backups. If backups aren\u2019t encrypted, they should be off by default and the user should have an opportunity to understand the implications of turning them on.<\/p>\n

A secure application should have\u00a0secure auto-updating<\/b>\u00a0mechanisms to quickly mitigate security problems. An out-of-date messenger with known security flaws is potentially vulnerable to more potent attacks than an up-to-date unencrypted messenger.<\/p>\n

Perhaps surprisingly, a messenger being marketed as secure can undermine the goals of security. If having the application on a user\u2019s phone is a marker that the user is trying to stay secure, that could make the person\u2019s situation more dangerous.<\/p>\n

Say an outside party discovers that a person has a \u201csecure\u201d app on their phone. That app could be used as evidence that the person is engaging in an activity that the outside party doesn\u2019t approve of, and invite retribution. The ideal secure messenger is primarily a messenger of sufficiently\u00a0high popularity<\/b>\u00a0that its use is not suspicious.<\/p>\n

An app may also choose to provide reliable\u00a0indicators of compromise<\/b>\u00a0that are recognizable to an end-user, including in the event of machine-in-the-middle attacks or a compromised service provider. The application should also allow users to verify all their communications are encrypted to the correct person (i.e.\u00a0fingerprint verification<\/b>).<\/p>\n

Finally, we recommend allowing users to choose an alias, instead of requiring that their only identifier be a\u00a0phone number<\/b>. For vulnerable users, a major identifier like a phone number could be private information; they shouldn\u2019t have to give it out to get the benefits that a secure messenger provides.<\/p>\n

Features to Look Forward To<\/b><\/h3>\n

In this section, we discuss the stretch goals that no major app has managed to implement yet, but that less popular apps or academic prototypes might have.<\/p>\n

We\u2019d love to see academics and experimental platforms begin working on delivering these in a scalable manner, but we don\u2019t expect a major application to worry about these just yet.<\/p>\n

While protecting the contents of messages is important, so too is protecting the metadata of who is talking to whom and when. When messages go through a central server, this is hard to mask. Hiding the network metadata is a feature we\u2019d like to see grow past the experimental phase. Until then, we expect to see services retain only the metadata absolutely necessary to make the service function, and for the minimum possible time.<\/p>\n

Most messengers let users discover which of their existing contacts are already using the service, but they do so in a way that reveals the entire contents of a contact list to the service.<\/p>\n

This means that to find out which of your friends are using a service, you have to tell the service provider every person whose contact info you\u2019ve saved to your phone, and you have no guarantee that they\u2019re not saving this data to figure out who\u2019s friends with whom\u2014even for people who don\u2019t use the service. Some messengers are already\u00a0taking steps<\/a>\u00a0to make this information leakage a thing of the past.<\/p>\n

Pushing reliable security updates is of prime importance to security. But automatically accepting new versions of applications means that users might inadvertently download a backdoored update onto this device.<\/p>\n

Using\u00a0reproducible builds<\/a>\u00a0and\u00a0binary transparency<\/a>, users can at least ensure that the same update gets pushed to every user, so that targeted attacks become infeasible. Then, there\u2019s a better chance that the backdooring will get noticed.<\/p>\n

When a messenger allows group messaging, advanced security properties like\u00a0future secrecy<\/a>\u00a0are lost.\u00a0New protocols<\/a>\u00a0aim to fix these holes and give group messaging the security properties that users deserve.<\/p>\n

In the secure messaging community, there’s no consensus on what the best combination of features is, and there may never be. So while there will never be one perfectly secure messenger to rule them all, technical questions and conversations like the ones described above can move us towards better messengers providing more types of security.<\/p>\n

Now read:\u00a0MyFitnessPal accounts hacked<\/a><\/h3>\n","protected":false},"excerpt":{"rendered":"

It\u2019s hard to arrive at a consensus of what a \u201csecure\u201d messenger must provide.<\/p>\n","protected":false},"author":23,"featured_media":164658,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[27],"tags":[35,21611],"class_list":["post-254367","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-security","tag-headline","tag-messaging-app"],"_links":{"self":[{"href":"https:\/\/mybroadband.co.za\/news\/wp-json\/wp\/v2\/posts\/254367"}],"collection":[{"href":"https:\/\/mybroadband.co.za\/news\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mybroadband.co.za\/news\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mybroadband.co.za\/news\/wp-json\/wp\/v2\/users\/23"}],"replies":[{"embeddable":true,"href":"https:\/\/mybroadband.co.za\/news\/wp-json\/wp\/v2\/comments?post=254367"}],"version-history":[{"count":1,"href":"https:\/\/mybroadband.co.za\/news\/wp-json\/wp\/v2\/posts\/254367\/revisions"}],"predecessor-version":[{"id":254369,"href":"https:\/\/mybroadband.co.za\/news\/wp-json\/wp\/v2\/posts\/254367\/revisions\/254369"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mybroadband.co.za\/news\/wp-json\/wp\/v2\/media\/164658"}],"wp:attachment":[{"href":"https:\/\/mybroadband.co.za\/news\/wp-json\/wp\/v2\/media?parent=254367"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mybroadband.co.za\/news\/wp-json\/wp\/v2\/categories?post=254367"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mybroadband.co.za\/news\/wp-json\/wp\/v2\/tags?post=254367"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}