Otr on Guardian Project

Integrating Crypto Identities with Android

Sat, 28 Dec 2013 19:42:56 -0400

ver the past couple of years, Android has included a central database for managing information about people, it is known as the ContactsContract (that’s a mouthful). Android then provides the People app and reusable interface chunks to choose contacts that work with all the information in the ContactsContract database. Any time that you are adding an account in the Settings app, you are setting up this integration. You can see it with Google services, Skype, Facebook, and many more. This system has a lot of advantages, including:

a unified user experience for finding and managing data about people
apps can launch common interface dialogs and screens for working with that database without having to write custom versions (launching Activitys via Intents
streamlined methods for building custom UIs based on the contacts database

With our work porting GnuPG to Android, we want Gnu Privacy Guard for Android to be fully integrated into the Android experience. Gnu Privacy Guard registers itself as a handler for all OpenPGP file and data types in Android, so users can work with these files using standard Android methods like Share/Send buttons. Or users can start by finding the person to encrypt to in the People app, then choosing the file. These flows make it intuitive to Android users, and means we have to write less code because it taps into existing Android systems. With the past release, v0.2, we laid the foundations for having the GnuPG keyring integrated into this contacts database. The next release, v0.3 will improve contacts integration a lot.

All of these contacts come from the GnuPG keyring being synced to the ContactsContract. Nathan’s contact is made up of combined info from Gnu Privacy Guard and Google. To encrypt a file to the author, select Encrypt file to… on his contact page.

One of the concerns that has been voiced about integrating with the ContactsContract database is that all the data put there will be then uploaded to the other accounts, like the Google account of the phone, or other accounts. As far as we can tell, there is no automatic syncing of data between accounts in the ContactsContract, instead it is a system of individual, local databases. We have not confirmed this with a code audit whether there is any data leakage from ContactsContract, and would love to hear more information on that. There is a layer of matching rules for locally merging those local databases into a single, unified view of that data. A good example of this unified data view in action is the built-in People app. It will show data from all of the local databases, and it will link profiles together in a single view based on programmatic rules that look at email addresses, names, etc. In any case, Gnu Privacy Guard only syncs one way. It treats the GnuPG keyring as canonical and clones the GnuPG keyring contacts to the ContactsContract whenever a sync is run. The sync process never reads from the ContactsContract, and currently no data is ever imported from it. So at the very least, the ContactsContract should not serve as a point to inject data into the GnuPG keyring.

The ContactsContract builds up the complete view of all contacts based on RawContacts provided by each account type, which are in turn built up of standard data types like name, email, phone number, etc.

One unexplored idea is for apps that need to use crypto to use only the standard Android contacts API to fetch crypto identity information like public keys and fingerprints. For example, PGP email app K-9 could look up OpenPGP info at the same time it is looking in the contacts database for email addresses. It probably even makes sense for K-9 to offload even more to an OpenPGP provider, and have K-9 just query the PGP provider whether there is a signing key available, whether the receiver has a PGP key, etc.

It is also tempting to think about using a similar technique for storing other types of keys like OTR keys for secure chat. The hard part is that OTR has no method built-in to the key for verifying whether that key is trusted. OpenPGP has key signing and the Web-of-Trust, with all of its issues, but the OpenPGP security model is designed around untrusted methods of moving public key data around. Using the contacts database for moving around public key material for later verification will work equally well for OTR, OpenPGP, etc.

On a similar note, we are also working with Dominik Schürmann and the K-9 devs to create a common Android API for a generic OpenPGP provider. This is similar to the contacts system in recent versions of Android in that there is a single, central contacts system that any app can tap into for managing data related to people.

We have decided to go with Dominik Schürmann’s approach of using an AIDL API to an Android Service. AIDL does have some downsides mostly around it being overcomplicated. But AIDL is the main Android method for inter-process communication with Services, so we are stuck with it, more or less. The beautiful thing is that this arrangement will make it possible for apps to fully offload the crypto handling to the Service, including all the required GUI bits like passphrase prompting, progress dialog overlays, key selection, etc.

For example of how this idea would work, we can look at K-9 email again. If an incoming email includes a public key or fingerprint, either of these can be sent to the OpenPGP provider for importing. An OPENPGP4FPR: URI will trigger downloading the public key from a keyserver. A public key contained in an attached file will be received by the OpenPGP provider via the Android file associations, which will then prompts the user to import it. When K-9 goes to send a OpenPGP-encrypted email to that new key, it checks the ContactsContract to see whether the recipient has a OpenPGP key. If so, it sends the email to the OpenPGP provider to be encrypted. The OpenPGP provider can then look up which key to use in it’s local keyring by using the recipient’s email address. If there are multiple keys for that email address, it prompts the user to choose. It could also base it’s choice on the OpenPGP trust level for that key.

These are currently all ideas for how GnuPG can be integrated into Android. Some of these are implemented and ready for you to try out on your device. The common OpenPGP provider idea is still very much a work in progress.

Keys, signatures, certificates, verifications, etc. What are all these for?

Thu, 12 Dec 2013 13:20:09 -0400

For the past two years, we have been thinking about how to make it easier for anyone to achieve private communications. One particular focus has been on the “security tokens” that are required to make private communications systems work. This research area is called internally Portable Shared Security Tokens aka PSST. All of the privacy tools that we are working on require “keys” and “signatures”, to use the language of cryptography, and these are the core of what “security tokens” are. One thing we learned a lot about is how to portray and discuss tools for private or anonymous communications to people who just want to communicate and are not interested in technical discussion. This is becoming a central issue among a lot of people working to make usable privacy tools.

The widely established way of talking about privacy tools comes from the lingo of the underlying methods: cryptography, networking, etc. We talk about public and private keys, signing, validation, verification, key exchange, certificates, and fingerprints. In order for cryptography to work, keys need to be marked whether they are verified or not. Few computers users understand what these terms are referring to, even highly technical people who regularly use encryption do not know the meaning of all these things, nor should they. This is a low level detail that is not important to how the vast majority of users understand privacy in computers. Keys and verification are far too abstract to be generally understandable, and what other kind of key has a fingerprint? Even more so, few people can tell you the difference between validation and verification when it comes to keys, signatures and certificates. The software should not be exposing all this, but instead should be minimizing the complexity as much as possible, and providing as simple a user experience as possible.

Defining the Concepts that Define the Experience

A key part of defining that simple user experience is defining the core concepts that the software is organized around. In our discussions, we mostly talked about the ideas of identity and trust, while some discussion of verifying identity seemed unavoidable. Talking about identity and trust is a lot more relevant in day-to-day life, i.e. knowing that the message came from the person you think it did, and trusting that it was private. It is most direct to talk about establishing a trusted connection to another person, but that’s not something that crypto can ever promise because there is still the analog gap between the person and the device. These core ideas must represent what is technically possible, so we searched for widely understood concepts that map well to the technical limitations: “a private conversation”, “a trusted app”, “verifiable video”.

create metaphors based on what users know

Diving in deeper, we concluded that the balance point between technical accuracy and widely understandable lingo was to talk about trusting the device, not the person. The technology can provide trusted connections between devices, and it is pretty close to how people experience digital communications. There is the laptop, the mobile phone, the net cafe, the friend’s computer, computer at work, etc. etc. When I look at my phone to see a message from a friend, it is easy to picture that friend typing that message out on that device, though it does take some conscious effort. The hard part here is that as we communicate more and more with our devices, there is less and less separation in our minds about whether we were talking in person, via voice, or by sending text. This is a point to focus on when thinking about designing the experience of private, secure communications software.

Let the Software Handle It!

There is a forming consensus in the world of usable security to focus on figuring out how to automate as much as possible then figure out how best tailor the experience of the essential parts that cannot be automated. The hard part will remain explaining the limitations of a given privacy tool.

At Guardian Project, we work a lot on incremental progress, so many of our projects are focused on specific, narrow improvements. With ChatSecure and Keysync , we were able to automate one small part of the whole process, cryptography identity portability, which provides the foundation to provide private communications and verifiable media. Allowing users to sync their trust profiles between desktop and mobile makes it much more likely that users will have fully verified OTR conversations when chatting on their devices and laptops.

With Gnu Privacy Guard for Android (GPGA), we have made it easy to import keys via QRCode as well as openpgp4fpr: URLs (a standard defined in conjuction with the Monkeysphere project. We are also working on a common method of using NFC for OpenPGP key signing in conjuction with OpenPGP Keychain. Even little things like optimizing support for standard file extensions can go a long way to make things easier, so GPGA automatically sets itself up to receive files with the standard OpenPGP MIME types (application/pgp-keys, application/pgp-encrypted, application/pgp-signature) as well as the corresponding file extensions (.pkr, .skr, .key, .sig, .asc, etc.). That makes it so a user can just click on one of these files, and GPGA will walk them through the whole process, doing as much as possible automatically.

Another interesting idea that is a big step in this direction is “secure introductions”. The idea is to automatically share trusted identity information when securely communicating with multiple people. For example, whenever you send a signed, encrypted email to multiple people, the email program should include the key fingerprints of each recipient in that email. Then the email program of the people receiving that email should automatically mark those keys as verified if the sender’s key is trusted and the signature is valid. There is not a meaningful amount of detail leaked in this interaction, since the existence of all the people’s keys and email address is already present in a secure email. The tricky part is figuring out how to make it harder for someone to use this maliciously to spread false identity information while keeping things as automatic as possible. This is very much a long term research idea: there are no widespread implementations of it.

Modernizing Expectations for the Nouveau Secure Mobile Messaging Movement

Tue, 16 Jul 2013 00:52:31 -0400

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”.

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.

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!”.

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.

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.

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).

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.

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.

Gibberbot v11 is not just secure, its also simple, snappy and super fun!

Fri, 08 Mar 2013 12:54:50 -0400

Gibberbot v11 is now final as of RC3 release: https://github.com/guardianproject/Gibberbot/tree/0.0.11-RC3. From here, the only changes to v11 we will be making will be critical bug fixes. We are now focused on our v12 release, which you can track here: https://dev.guardianproject.info/versions/39

_Please promote our new Gibberbot how-to interactive tutorial available here: https://guardianproject.info/howto/chatsecurely/_

If you have been tracking our efforts here for the last few years, you will know that Gibberbot, our secure instant messaging app, started out as a big old mess of an app called “ORChat” as and then “OTRChat” and then “Gibber” (or “Jibber”?), and then finally settled down into the name and app it is known as now. Really it was a proof of concept, showing that you could indeed use the OTR4J library built for desktops app, on Android.

Gibberbot was the first Android app, and perhaps real mobile app, that supported end-to-end encrypted chat using open standards like OTR and XMPP. In the early days, we were just so excited this was possible, and that we could also send the chat connections over Tor, that we didn’t think too much about how easy or fun it was to use the app itself. We were focused on our magic tricks, and not how it was to live and use the app on a daily basis.

A few months ago, we realized that on Google Play, we had a lot of reviews that basically said “This is a great idea, but it doesn’t work for me”, or “I like these guys, but the app is kinda buggy”, and even “This app gives my device crazy flash seizures”. All of these reviews were true, and we swallowed the hard medicine, that if we didn’t spend more time focusing on how the core features of being a mobile instant messaging chat client worked, that nobody would care about how secure the app was, because there would be no one using it.

We set about then not only continuing our focus on improving the core security and technical core of Gibberbot, but also focusing on a user interface update. We completed “stage 1” of that update, with another major round of effort planned for v12.

Here a few new features and improvements along those lines, that were completed for v11:

Simplify setup of Google Gmail and Google Domain accounts…. DONE! We now support the built-in authentication system on your Android phone, so if you phone is already setup with a Google account, we can tap right into that. No extra password entry needed, no need to enter anthing really. Just choose “Google Account” from the account type list.
Streamline Orbot integration to make Tor user easier… DONE! Using the new OnionKit library, Gibberbot can now tell if Orbot is installed and running, and if not, prompt the user to either install it, or ask if they want to start up and connect to the Tor network.
Make it easy for services using SSL certs not signed by the Root CA cartel to be easily verified and accepted by the user… DONE! Increasingly, it has become less and less valuable to have the TLS or SSL certificate you use with your website or XMPP server to be signed by a Root Certificate Authority, because as many point out, the SSL is broken, as long as trust this strange collection of hundreds of organizations we have no reason to really trust. Previously, Gibberbot would not handle non-Root CA certs very well, so you would just have to turn off verification. Now thanks to the concept of TOFU-POP (Trust on First Use, Persistence of Psuedonym) and the excellent MemorizingTrustManager library, user’s can now decided in an on-demand and interactive manner, whether or not they want to trust the TLS connection they are using.
Ensure Gibberbot only runs and signs in when the user wants it to… DONE! Previously, Gibberbot was a bit too aggresive about trying to stay connecting to your account, and starting up on device boot. Many users want to conserve battery, and some do not like apps that run without them asking them to first (imagine that?!). We have put Gibberbot now at the user’s beck and call, such that there are preferences to control starting on boot, and when you SIGN OUT, it really means do not every login again, until I login.
Improve the user interface to make app that is clean, fast, modern and customizable… DONE! Not only have we continued to focus on a clean, simple user interface that uses the latest interface conventions and guidelines from Google, we also wanted to start adding some fun user personalization options. One size does not fit all, and just because our app is secure, does not mean it has to be boring. As you can see below, Gibberbot now supports light and dark themes, as well as user configured app wallpaper.

I am happy to say, that will all of these improvements, we are much happier users, and are receiving much better reviews on Google Play, such as:

“Easy to set up and pretty stable and easy to use.” “Fixed on jelly bean and does exactly what it should do” and the best… “Perfect (but no ICQ Support*)”

*We may add ICQ support, just so we can be extra perfect for that one user who wants it! 🙂

All in all, we hope you agree, and that our new found focus on usability can push us from 100,000+ downloads to over 500,000+ in the coming months. We have big ideas for the future of secure mobile messaging, and making Gibberbot the best it can be is a huge part of that plan.

As always you can find the Gibberbot download (and all of our apps) in a variety of places:

Through our direct APK download: https://guardianproject.info/releases/gibberbot-latest.apk (and gpg sig)
on Google Play
or through our F-Droid Repo, which you can learn how to use here.

You can also scan this QR code, which links to the direct APK download above:

User scenarios to guide our crypto development

Sat, 14 Apr 2012 20:16:03 -0400

At Guardian Project, we find user-centered development to be essential to producing useful software that addresses real world needs. To drive this, we work with user stories and scenarios as part of the process of developing software. One particular development focus is the Portable Shared Security Token (PSST) project, which aims to make it easy to use encryption across both mobile and desktop computers, as well as keep the stores of cryptographic identities (i.e. trusted keys, certificates, etc) in sync between devices.

This post outlines some initial user scenarios that PSST aims to address. We believe them to be common enough so that our solutions will be readily applicable to real world people now. They are a small subset of all of the types of users that we feel can ultimately benefit from the PSST core research, so these user stories provide a starting place for honing the tools for the needs of actual working organizations. These stories also discuss how the software could be used in these situations. The software as described mostly exists, but not all details are currently implemented or even fully vetted as secure practices.

We are very eager for feedback, comments, and criticism on any aspect of these scenarios, from whether they are plausible to whether the user interactions described are built upon realistic expectations of actual members of organizations like the ones described here.

The Small Cabal

There is a small group of people that needs to communicate as securely and anonymously as possible. They all meet up in person. They generate keys, and individually sign each person’s key and get that person’s signature on their own key. These are local-only unpublishable signatures. No one uploads their keys to any other server or device. They each generate a revocation certificate and hook it up to their panic button app. Once the panic button is hit, the phone broadcasts the revocation certificate to the pre-determined list of people.

Diffuse Activist Organization

An activist organization has members spread out all over their country, with concentrations in certain areas, and a handful abroad. They are working in a country that aggressively tracks communications, but encryption is not banned nor aggressively tracked. Since there are many members and they are widely spread, very few of the members have met the whole membership. Many members often meet up in person at various places around the country, and some people also travel to regional and national meet-ups. The central forum for the whole group is on the internet, and there are many big group discussions and announcements that happen on internet forums.

Each member has a cryptographic key that represents their online identity, which they post to the public keyservers. They generate and store a revocation certificate to upload to the keyservers in case of a compromised key or computer. They do not post any signatures to the key servers so that the social graph information remains private. Whenever they meet another person that they trust, they sign each others’ keys and swap all signature data using direct peer-to-peer communication.

When interacting with members who they only know on the internet, they check whether they have a cryptographic trust path to each others’ keys, and if not, they establish the first step of trust via OTR by doing key verification via question/answer, shared secret or manual fingerprint validation over a trusted channel, like the phone. When they hit there panic button the post the revocation certificate to the keyserver. Each member’s computer/phone automatically checks the public keyservers for revocations hourly, and marks any revoked key as invalid as soon as it receives a revocation certificate.

Multinational Organization

An organization has many members in a number of different countries. Some of the governments are supportive of the organization’s goals, while some of the governments are strongly hostile and are actively seeking out local members. Many members work in countries where there is little chance of active tracking and monitoring of their use of encryption, while others work in high risk environments from time to time. Certain local contacts and members work in aggressively monitored countries where use of encryption is a flag for the secret police.

The public figures of the organization in safe countries have a public trust profile that is freely downloadable. They use the public OpenPGP infrastructure and publicly share all public signatures. These members also have private, unpublishable signatures related to the members in high risk situations. Operatives in high risk situations use only unpublishable local signatures and the whole collection of signatures is stored in an encrypted form. There devices only contact keyservers via anonymized connections like Tor or VPNs.

When members are signing each other’s keys, the signatures are always sent to the key owner via encrypted email. The signer can then mark the signature as private or public, or their software can be set to always mark all keys as private and unpublishable. When the key owner receives the emailed signature, she can then decide how to manage the signatures: either privately import the signature to their keyring, where it will be stored in an unpublishable format; or publicly import the signature into their keyring and sync it via the public PGP servers. If the signer emailed a private signature to the key owner, then the key management software will automatically make it a private signature.

Improvised movement organized via social software

People from all over a region join a popular movement to help organize protests, distribute media, spread information, etc. Many join in groups of friends or family, but overall the group is not socially well connected together. The common cause is the central binding of the group. In their communications, they want to avoid keyword filtering and communications tracking, as well as try to hinder infiltration and the injection of misinformation. They need to communicate and exchange media with some level of trust. Since the group wants as many members as possible, the infrastructure must be relatively open and public.

Users who do not have any shared history will trust each other’s keys on first contact, and rely on the continued validation against the initial mark of trust (known as TOFU/POP or Trust On First Use/Persistence of Pseudonym). Once users build up some context with each other, they can deepen the cryptographic trust by using OTR question/answer or shared secret authentication. Users publicly share their TOFU/POP and OTR marks of trust on public exchanges so that people can build up public trust in their cryptographic identity.

Foreign Journalist, Diplomat, Business Person, etc.

This user is working in a place with active monitoring, tracking and filtering. She has strong links to institutions outside of the country that can help in case of trouble. She has clear outsider status so is able to use encryption and anonymizing software without a large risk of persecution. She wants to keep her communications private in the face of active monitoring.

Standard public cryptography tools cover most of this situation, but they must be made easier to use, and work on mobile devices. If this user needs encrypted exchanges with locals at high risk of monitoring, local unpublishable signatures can be used in those situations.

On Verifying Identity Using Cryptography

Mon, 19 Mar 2012 11:27:51 -0400

One of the most important uses of cryptography these days is verifying the identity of the other side of a digital conversation. That conversation could be between two people using OTR-encrypted IM, a web browser showing a bank website, a Debian Developer uploading a package to the Debian build server, an ssh client logging into an ssh server, and on and on. In all of these cases, cryptography is used to ensure that the software is indeed receiving replies from the expected entity. This happens by checking the current cryptographic key against one that is known to be correct. That is essential to the whole process. If you see the key for the first time, you have no way of knowing whether that is indeed the key you are expecting because there is no point of reference.

In order for this validation of identity to work, there needs to be a method of verifying any given key and making it a reference. There are many ideas about how to do this:

a trusted list of central certificate authorities like in HTTPS
key-signing parties where people validate and sign each other’s keys in person, like used with the OpenPGP Web of Trust
“trust on first use” (aka “Persistence of Pseudonym”), where you save the key the first time you see it, and then use that as a reference (this is the way most people use SSH)
fingerprint verification, where the two people wanting to communicate cryptographically use another channel to manually check each other’s key fingerprints, like a phone call (this is used a lot in OTR and OpenPGP)
the Socialist Millionaires’ Protocol (SMP), which is a combination of user-generated question/answer pairs with a cryptographic technique that lets each side confirm whether the other answered the question correctly without divulging any information (this was recently added to OTR and is implemented in Pidgin, Gibberbot, and maybe a couple other programs)
a manually confirmed shared secret like a short password (ZRTP uses this when starting secure phone calls)
whitelists of fingerprints of widely used keys (aka public key pinning) (this was recently added to Chrome in the wake of the HTTPS certificate authority failures)

Each of these techniques has its advantages and disadvantages, but generally the higher level of verification provided means the more work to do the process. Most people don’t need the high level of verification provided by OpenPGP key signing parties, but maybe if it was fun and much easier to do, then a lot more people would do it. “Trust on first use” is really easy to use and implement, and has been working pretty well for a lot of people who use SSH and OTR. But it has big shortcomings in environments where the state or other central authority that provides the internet infrastructure wants to spy on its users. HTTPS has proven to be quite easy to use, but it has also proven to be quite breakable.

Currently, each of these techniques described above is used as the sole means of verification, then the level of verification is represented as “verified” or “not verified”. This is definitely the way that HTTPS and SSH handle it. OTR is a bit different, it has 3 states of verification: “new key”, “unverified key” i.e. trusted on first use, or “verified”, and good OTR chat apps will represent these three states in the UI. Then OpenPGP is perhaps the opposite extreme: it provides both chains of verification signatures via the Web of Trust but also user-set “trust levels” from 0 to 255 for any given key.

Perhaps an answer is to cryptographically link up these different ways of verification and represent key verification as a continuum. Then when the possibility of linking in “trust on first use” and other techniques was there, people could gradually build up cryptographic trust as they needed it. Starting with “I have seen this key before”, then on to “I have gotten them to verify their OTR key with an SMP question/answer”, then to “I have an OpenPGP trust path to them”, to “I have met them in person and manually verified their key and identity”.

To go into technical detail as an example, GnuPG supports RSA, DSA, ECDSA, El Gamal, and other key types as subkeys for an OpenPGP key. Those core algorithms core basically all of the most common uses of cryptography, including HTTPS, SSH, OTR, and OpenPGP. The link between an OpenPGP key and its subkeys is perhaps the strongest link for verification that exists, so if a given person includes their OTR key, for example, into their OpenPGP key, that provides a strong cryptographic link between them, and one that is easily publicly sharable via the OpenPGP public keyservers. When two people verify their OTR keys using the SMP question/answer, this verification could then extend to their OpenPGP keys if their OTR keys were subkeys. (The Monkeysphere Project is one such implementation of this idea, using OpenPGP keys for SSH and HTTPS).

Then the last piece of this puzzle is how to represent all of this complexity to the users. The essential part is to stop representing trust as binary yes/no. A one-dimensional continuum provides a lot more info and is a very commonly understood concept in computers (think progress bars). The hard part of this question is ranking the various techniques in how much progress they provide towards the goal of solid identity verification.

For this round of the PSST Project, we have focused on first allowing people to easily move around their OTR identities, then worked on testing out the idea of linking in all identity keys into an OpenPGP key. From what we have seen so far, we believe this is not only feasible but will provide a solid platform for linking together all these verification techniques and identity keys. And on top of that, with diligent attention to user experience and testing, it should be possible to create user interfaces that make navigating all of this a common, daily task for most computer users.

How many ways to store 5 numbers?

Thu, 23 Feb 2012 12:29:49 -0400

At the core of all software that aims to be secure, private and anonymous is encryption, or as I think of it, amazing math tricks with really large numbers. These really large numbers can serve as a token of identity or the key to information locked away behind the encryption math. There are a number of different encryption methods commonly used based on different mathematical ideas, but they all rely on people managing sets of really large numbers, usually known as keys.

It turns out that managing these sets of really large numbers can be tricky to do well, so there are all manner of key management apps and approaches. On top of that, there seems to be decades of people wanting to make their own formats for these sets of really large numbers. So if you want to work directly with the keys themselves, you not only have to sort out the difference between the kinds of numbers used in DSA, RSA, Elliptical Curve, etc., but you will also have to figure out which of the many many formats those numbers are stored in. There are base64 formats, hex formats, standardized binary formats with names like PKCS#8/DER and X.509, old formats like S-Expressions (sexp) as well as non-standard formats like keyczar’s JSON format that uses web-safe base64. Then, there are different ways of reading and writing those different formats into a file.

We started out working on the particular problem of translating the 5 numbers (x, y, p, q, g) used in DSA keys. DSA keys are used for OTR encryption, and we want to make it possible to translate the DSA key information stored by one OTR messaging app into the format used by others. Here are three examples of storing DSA keys:

(In general, its a very bad idea to post private keys anywhere at all public. These three are private keys that have been generated for test purposes)

libotr private key from Pidgin (sexp with hex numbers):

(account
(name “gptest@jabber.org/”)
(protocol prpl-jabber)
(private-key
(dsa
(p
#00CD96479A2F404FB600F9C85EE3DCD69FDF93F217AEE54A1286069983BA7731D0C73C7CB3B8CFA482A0AF6FF906E470EB4EF7F4D201D087AEDBF0086710F3039CBF42358C1BFA7D86A36332E21D32BE31538571CBC8D4F281DDD1076BA2B29B549ED29B3C19C341AEF83C80157E87FF2930B5E15C84A09AFCE28A06E06A62BCEF#)
(q #00D5B4647E688974D1B6B199E1A59AB2F985DBCE01#)
(g
#0093E333135FCBCE68FC6E410B304482F2F95D82BF53534C3636EADB0C22241CF35BD294B096070DC08138EFE73B03C88FD444595974E9455274F695147AF9D46B85286B4CFEF3D00BCA1D3BEB8C7EFFBA08132E1A1E4D9F115B863C52C72971F4695758354FC3BE3C4A45AF6A47747B59733905C33EE86ED68D9D90494877AE33#)
(y
#362C06B9CDD67FC4E7A7A62289D6C1E8BA061A024946A5ACC1A7DC70F6B03D99A1D3B3215D20BC4F8458EEC3F31E1391E9B519FDCDCC3CF0FBA38F8A7213551B32D59DE655F506633FB6B0EA94C4174D227DB614EF6723AB057B40CF36E2A414D0A8DCF223EE7EDD851793C4DC92282C79503030045D49A0ABCC3C6CC4080909#)
(x #24FE542B1C7DC8337F6F8030C7D639B7BF091B40#)
)
)

otr4j private key from Gibberbot (PKCS#8 DER with ASCII armor, escaped for Java Properties):

gptest@jabber.org.privateKey=MIIBSgIBADCCASsGByqGSM44BAEwggEeAoGBAMtPbcgvf2CAHN4djUb+gCPw/e8Xpeyc9GknS9zs\nJjSCg9vgiKBVlQBceiKAkK8SVVEaA671SS0XO575OK/sAc4j0n2t9QJP1wyGCOhV79WbwhPPEVhs\ncpAHakr9IAW6WdSnwhL/seZLYRKiVGpxXJffwN+sYjH00PulKNxmz2+DAhUAxh9yFSC1uuGk6IR0\ntnVAfsPUt7cCgYBGfHU40n0HgKIkVe3XtX0G3CbiGbR++qaEjNqnfWynggqeeVkYliLaDlVrR4B0\nnLrHZLEcUMO38YKmrwug02acp9P65IcjZ2yaioPBSmV7R6pMGOdJFR3V7Pd5R2+NcUdJd2xSffLf\nrChM82SKqa7b3DOPHkSoIdp/vJiRgikZrwQWAhRE5snYBaoR84hWVdxlumAYkBRUEA\=\=

private key from keyczar (JSON with websafe base64):

{
“publicKey”: {
“q”: “AJJfsQZrhUV8p6TmpPqa084JwX9j”,
“p”: “AIAAAAAAAAXxHhQxJRZ-PPj2BDrHHLV8c8pX6nyOLAW3Bc7CX_SfBiGH2VyImoz6JlAOZi6x_XspxdUvpTjV7J9uO9hwnF31m3SQjdkZW2DQDb5OS1rW_4MGrTJCktKtlZz7f8_5AoO8yHSY2XWNDqrpBEiNvaTX1ttQ59nREiR1”,
“y”: “AGlQuRpbat4drE_fcdSZrEVfS6Fme3tNfUoJVRec1pUhoSo9PBHKFx3lbBmI8Vnub8vuY1nM2yTadOZ8H4-TYxB5JNMVTK7vLNdVcWvUUF9zRZCwps1bl0_Al29X0I1iQYJN6Klxi_QbKaSf5PhfXLVom9bJYp7_TwZCouaab296”,
“g”: “AES5hk-DKXP__t6yDsXIdykf7lhSKHqQCW5H2V5dMg8JkoFBSP7mIvaCHT4IxoxdM2AIpWgcoi5XSrd_hD2sjNa1JHTb9BUh31dHJLym6rTsV12ClN6f78Cjt0oKFIRI\__yWn9KM-vLEsjpd10VHlPfbEgKYePCnXFt7Y78G0wGr”,
“size”: 1024
},
“x”: “AGLJry5Q0CZo9cH6XRYd2ZZZppwg”,
“size”: 1024,
}

There are many instant messaging (IM) apps that provide solid support for the OTR chat encryption protocol. Many people use the same IM account across multiple computers and programs, but this generally causes lots of headaches when using OTR. One technique for eliminating these headaches is to use the same private OTR key across all programs and computers, but since each program has a different file format, this is hard to setup. In order to address this issue, we first mapped out the key and file formats for a number of the most widely used OTR programs (Pidgin, Adium, Gibberbot, Jitsi, irssi). As part of the OTRFileConverter project, we have written parsers for these file formats, and are close to being able to convert between all of them. These parsers not only convert the private keys for each account, but also the known public keys of remote accounts as well as their verified status. In this process, we discovered a fundamental incompatibility in the otr4j library used in Gibberbot, Jitsi, beem-otr, and other software. Fortunately, it should be possible to fix the otr4j library itself and all the software based on it should have the issue transparently fixed by including the updated otr4j.

Coming soon, OTRFileConverter will be able to sync all of your key information between Pidgin and Gibberbot, so that means private keys, other people’s public keys, and whether those keys have been manually verified, or verified via the Socialist Millionaire’s Protocol (SMP).

Track our progress at: https://github.com/guardianproject/otrfileconverter