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

[Lee Azzarello]

I would mention voice and video.

-lee

On Tue, Jul 16, 2013 at 1:07 AM, Nathan of Guardian
<nathan at guardianproject.info> wrote:
>
> >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.
>
>
> _______________________________________________
> Guardian-dev mailing list
>
> Post: Guardian-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>
> To Unsubscribe
>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>         Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/lee%40guardianproject.info
>
> You are subscribed as: lee at guardianproject.info