[guardian-dev] Modernizing Expectations for the Nouveau Secure Mobile Messaging Movement

[Nathan of Guardian]

>From the blog:
https://guardianproject.info/2013/07/16/modernizing-expectations-for-the-nouveau-secure-mobile-messaging-movement/

What more can or should we do on this front? At this point, I just
want to get v12 to stable! :P

The tl;dr of this lengthy (tho entertaining and immensely important!)
post is this: Stopping with "We support OTR" or "We support PGP" is not
enough anymore. There are at least seven, if not more, very important
security features that any app claiming to provide secure messaging must
implement as soon as possible, to truly safeguard a user's communication
content, metadata and identity.

Note: The names "Gibberbot" and "ChatSecure" are used interchangeabley
below, as we are in the midst of an app rebrand. Apologies!

There has been a great deal of activity recently around new apps and
projects working towards the goal of end-to-end secure mobile messaging.
This is both prompted by the overwhelming popularity of closed-source,
insecure apps like WhatsApp, Viber, Line and WeChat, and by the recent
revelations around government-sponsored surveillance in portions of the
world that like to think of themselves as "free".

Too Many Apps

Whether it be the effort by the CyanogenMOD team to build in a secure
push messaging, the arrival of new apps like Gryphn, Wickr, Threema and
SureSpot, or the very succesful crowdsourced funding of Heml.is, there
is no question that there is both user and developer interest in this
topic. I would also be remiss not to mention the continuing excellent
work by Moxie and the Open Whisper Systems team on SMS-based secure
messaging, Ge0rg and the Yaxim app, our iOS sister project ChatSecure,
and of course, Silent Circle (are they open-source yet or what?).

Protecting Content, Metadata and Identity

At the Guardian Project, we have been working on open-source,
standards-based, secure messaging for a few years now, and are
simultaneously both excited and concerned about all of this activity. We
are seriously thrilled that so many talented developers are finally
interested in empowering every day mobile users with powerful tools to
keep their communications private. We are amazed at the creativity and
quality of output seen so far, as well as the diverse approaches to
solving this complex problem. Most of these apps are innovating way
beyond the basic concepts of secure messaging established by systems
like OpenPGP and OTR encryption, and actually thinking deeply about what
it means to be secure in a mobile context. However, we also think that,
in many cases, the security being implemented may not be going far
enough. At the least, we feel that a new bar needs to be set, that is
nost just "more secure than WhatsApp". We need to establish norms to
help the user better understand and parse through their options.

In this context, the word "secure" should be taken to mean, that the
contents of a message or conversation between one or more parties,
should only be able to be viewed by those parties. This means that the
application or service should ensure that message content, be it plain
text or rich media, is both protected on the device and over the
network, from extraction, interception, and decryption. In addition,
"secure" should also extend to protect from network traffic
surveillance, the fact that a conversation between one or more parties
is even happening in the first place. Finally, as much as possible, the
user should be able to control their identity within the messaging
system, such that personal, real-world information (phone number, email,
geolocation) is not exposed without their approval.

This three-fold approach to mobile security (Content, Metadata,
Identity) is a work in progress, but does capture our basic sentiment
and approach to secure mobile messaging. From here, I would like to step
one level down, and talk about the set of features in our next release
of Gibberbot, currently in alpha, that we feel keep our solution to
mobile messaging at the head of the pack.

1. Full Local Data Encryption

Many apps feel their job in protecting messages is done once it gets to
the device. In the face of Android app malware that can vacuum up data
from a device and forensic extraction software and hardware, this is
obviously not the case. Full disk encryption only protects when a device
is locked or powered off, and besides, most users do not enable it. It
is up to apps themselves to provide full encryption of all data -
account configuration, sensitive settings values, messages, logs -
anything that might expose a user's information to other apps on the
system or to a extraction software must be protected. Yes, this also
means your user will need to enter a password every time they use your
app, but it is possible to make that process less painful.

device-2013-07-12-053533

We have been working on two developer libraries, SQLCipher and IOCipher,
which provide a simple means to enable database and file encryption in
any app. More recently, we have added the CacheWord library to that mix,
to help safely manage the locking and unlocking of these data stores.
Apps like Gryphn have already implemented all three of these libraries,
and so will the next version of Gibberbot.

2. Certificate Pinning

Moxie says it best in his post titled Your app shouldn't suffer SSL's
problems: "If you have a mobile app that makes SSL connections to a
service you control, there is really no reason to be validating your
service’s certificate using CA signatures." The Android Pinning library
makes it quite simple to support this important feature in any app. For
Gibberbot, we are pinning certificates of the most common known public
XMPP services, such as Google (talk.google.com), Facebook, Jabber.org,
Jabber.ccc.de, DuckDuckGo and few more. Beyond that, we offer manual
verification (see #3 feature below for more on that). In summary, there
is no reason anymore to trust the default CA's for a messaging app.

3. TOFU/POP aka "Manual Certificate Verification"

Chris Palmer, formerly of the Electronic Frontier Foundation and iSec
Partners and now of Google, gave a great talk a few years ago entitled
"It's Time to Fix HTTPS". In it, he introduced, or perhaps just
popularized, the phrase "Trust on First Use, Persistence of Pseudonym",
that is more happily expressed as TOFU/POP! What this means in user form
is that when you connect to a new server for the first time over an SSL
connection, instead of the SSL Certificate being verified by a built-in
set of trusted root authorities (banks, corporations, governments), the
certificate is presented to the user, in a human readable format, to be
reviewed, accepted or declined. There are a number of useful pieces of
information the user can look at to determine the validity -
fingerprints, date generated, and so on. If you can safely verify it
once, then you will only be notified or asked to verify again if the
server's certificate changes. At that point the user can be told "This
site's certificate changed, and it doesn't look the same as it was
yesterday. Maybe you should ask the admin or help system if it is still
safe to use!".

device-2013-07-12-054024

The implementation of TOFU/POP that we use in Gibberbot is the
Memorizing Trust Manager library, originally developed for the Yaxim
messaging app. It works very well, and again, is extremely simple to
implement. Through the combination of features #2 and #3 we have removed
the threat posed by the failure of the Root Certificate Authority
system, and significantly reduced the success rate of Man-in-the-Middle
attacks.

4. Proxy Support, ideally Tor

With all the talk of metadata recently, it should be clear how important
traffic surveillance is. Knowing who is using what app when, or being
able to see when two users connect peer-to-peer through a service is
immensely valuable information. If it is possible to map a user's social
graph via your app based on analysis of packets coming in and out of
your service, then you have failed in providing security to your users.
Additionally, we have begun to see a new wave of Internet filtering
around the world, as countries begin to block access to popular
messaging app downloads and centralized servers.

device-2013-07-12-054331

This makes it critical that any messaging app a user will depend on to
protect their messages, also works to protect their network of contacts
(social graph), and ensures they will have access to the service no
matter where they travel or live in the world. In order to achieve this,
direct support for proxy servers should be built in to every secure
messaging app. At a bare minimum HTTP proxies should be support, and
ideally, HTTPS and SOCKS as well. Once you have support for those, you
can easily tie into Orbot on Android, by setting the proxy to
"localhost" and the appropriate port. If you want to avoid Tor Exit Node
attacks or surveillance, you should then provide a Tor Hidden Service
.ONION address for your servers, something that the CCC's Jabber server
has provided since 2011.

We have blogged in the past about Twitter's support for proxying on
Android and our OnionKit library, now named NetCipher. Gibberbot has
supported proxying from nearly the beginning of its existence, and in
v12 we are using the OrbotHelper class to add an automatic check if
Orbot is installed and running, if a user selects to use it.

5. Verifiable Message Encryption

While we expect most nextgen secure messaing apps will support some form
of public key encryption, OTR ideally and OpenPGP alternatively, that is
not really the end of the message encryption problem. With OpenPGP, we
know that most users of the software participate in key signing parties
on a regular basis. The same is true for users of desktop OTR encryption
in apps like Pidgin. People do not verify keys as often as they should.
Since most messaging apps support in-band key exchange, it makes
performing a MITM attack at the messaging layer quite trivial, if the
SSL transport layer encryption is somehow intercepted.

device-2013-07-16-003940 device-2013-07-16-004035

What is needed are a variety of features, prods, pokes and motivational
interventions to ensure that two people who are using an app to exchange
encrypted messages know how fun and easy it can be to verify their keys.
With Gibberbot, we were one of the first apps to support the display and
scanning of OTR fingerprints as QR Codes. We will go beyond that in
future releases with NFC support, as well. We also support shared secret
and Socialist Millionaire Protocol-based verification, which in short
means, if you and your friend have a real world secret or question and
answer ready, you can easily verify your cryptographic fingerprints
without ever having to look at a long string of alphanumeric characters.

6. Key Management

This feature comes under the "a great problem to have" category. Once a
user really commits to using their app, they will begin building up a
network of verified contacts (if you have implemented #5 properly), and
generally come to regard your app as a type of secure identity
management tool. In fact, they may have created a whole unique identity
for themselves that only exists within the confines of your apps, and
its encrypted local storage (if you have implemented #1 above). At this
point, you need to figure out a means for a user to backup this
identity, and generally import and export the data in a variety of ways.
If you are using OTR or OpenPGP, then the user may want to share
existing keyrings to and from other apps, most likely on their desktop
or laptop machines. All in all, the user needs to be empowered to have
control of their identity, to move it between devices, to back it up in
case a device is wiped or lost, and to keep total control of that
information (i.e. not have it backed up automatically to a cloud).

keysync

In our case, we have been working for quite a while on a desktop tool
called OTR File Converter, which is built upon more fundamental research
into the many ways that different OTR-enabled apps store their public
and private keys. As of Gibberbot v12 alpha 3 (now called "ChatSecure"
btw!), we now have working support for importing an OTR key ring from
the desktop, in a manner that is secure and fairly simple. Our next stop
is to add export from the client, and then automated sync between
desktop and mobile on an ongoing basis. Beyond this capability, we also
plan to expand the ability to manage keys within the Gibberbot app
itself, so that a user can manually revoke, regenerate and update or
remove trust of other users' keys.

7. Panic as a feature!

Finally, we keep coming across this idea of a "Panic Button" being an
important feature for addressing security issues in a mobile
environment. A few years ago, we developed an app called In The Clear
which attempted to provide data wipe and distress beacon functionality
across your entire device, be it Android, Nokia or Blackberry. We
quickly realized that there were many, many different definitions of
what a "Panic Button" should do, and that one app may not be able to
encompass all of these needs. Since then, we have thought more about
"Panic!" as a feature for an app, and how each app we develop should
incorporate the capability to assist users when they feel the data that
the app holds may be at risk of being compromised or exposed.

device-2013-07-12-054429

In Gibberbot v12, we have implemented Panic as a quick access sidedrawer
button. The action can trigger a configurable set of actions, ranging
from simply logging out, to deleting all configured accounts, to
uninstall the app itself. In the future, we would like to also consider
supporting a "turtle shell" type feature where the app can hide itself
on your device as an encrypted anonymous blob, until you are ready for
it to come back out again. Additionally, supporting false passwords at
app unlock that trigger account data wipe or the display of false data
is also something we think would be useful to support.

What Are You Prepared To Do?

We know the deep feeling of adrenaline and satisfaction you get when
code ship software that can truly have an impact on a human's basic
freedoms. We are moved when we receive an email from a user in a part of
the world where speech and expression is limited and filtered, and they
tell us how important our software is to them, and how they do not know
what they would without us. These emotions, both from within and shared
by others, make it that more important to ensure any development of
secure messaging tools is approached in a serious and diligent manner.
Checking feature boxes is not enough. Using HTTPS is not enough. Even
supporting basic OTR and PGP is no longer enough. We must provide deep
and broad security both on the network and on the device, at all times.

If you are not prepared to go the extra mile with your app's security
capabilities, then perhaps you are in the wrong line of work.