Encryption on Guardian Project

Haven: Building the Most Secure Baby Monitor Ever?

Fri, 22 Dec 2017 09:07:00 -0400

About eight months ago, friends at the Freedom of the Press Foundation reached out to us, to see if we were interested in prototyping an idea they had been batting around. They knew that from projects like CameraV and ProofMode, that we knew how to tap into the sensors on smartphones to do interesting things. They also knew we could connect devices together using encrypted messaging and onion routing, through our work on ChatSecure and Tor (Orbot!). They also knew of our deep interest in bringing ideas to life that can solve real problems faced by people out on the front lines (both at home and abroad), who often are more in danger from physical threats, than digital. They had a concept that would bring all of these things together, and just wanted to see if it was even possible. We were game, and well, here we are today, announcing a real working public beta, and a new open-source project, that we are extremely excited about.

IT’S NOT JUST A PHONE

At some point soon, we should stop calling the smartphones that over two billion people carry with them everyday and everywhere, phones at all. These devices have powerful processors with multiple cores, at gigahertz speeds, and gigabytes of RAM and storage. They have at least two cameras, now often three, arrays of microphones to capture sound near and far, and high definition, hyper sensitive touch screens for controlling them. They contain multiple radios and signal processors, that allow you to make crystal clear calls to someone on the other side of the planet, live stream 4K video, and download a game all at once. Most importantly, for the work we are announcing today, they contain an amazing variety of sensors, that can measure gravity, motion, air pressure, ambient light, temperature, and your precise location on the planet. I don’t think Alexander Graham Bell ever imagined a telephone doing all of these things. Once you step back from thinking of these devices as phones, and instead as powerful general purpose portable computing platforms, a world of possibilities and potential uses opens up wide. Even better, many people have an old second-hand, last generation device lying around, ready to be transformed into a computing platform much more powerful than a Raspberry Pi or some generic Internet of Shoddy (!) Things platform.

A SAFE ROOM IN YOUR POCKET

This re-imagining of a smartphone as something more, is what inspired the development of Haven, a new open-source project and mobile app we are announcing today, built in partnership with Freedom of the Press Foundation. The concept of Haven, as imagined by Micah F. Lee and Edward Snowden, is based on the notion that any smartphone could be turned into a personal, portable security device, to watch for unexpected intrusions into physical spaces.

They call it a “safe room” in your pocket, or way to defeat “evil maid” attacks, that lets you know when you’ve been targeted by a “black bag” operation. I also like to think that through Haven, we have unexpectedly created the most powerful, secure and private baby monitor system ever. By tapping into the sensors and processing power on these devices with custom software, a system could feel the vibrations of someone walking, detect the shine of a flashlight, hear the sound of a door opening (or a child crying), or see someone entering into the view of a camera. All of these “intruder alerts” are recorded on the device, so that the victim can have evidence of their unwanted guest. Even better, they can receive real-time secure and private notifications, with images and sound, as it happens, and take appropriate actions.

**YOU ARE THE WATCHER
**

An important design goal of Haven, is to not require the user to share data with any third-party, or to have centralized infrastructure. It was clear that some might see Haven as a surveillance device (or “self” sous-veillance), which, regardless of who is in control of it, can be problematic and a vulnerability. Thus, it was a fundamental tenet to not require people to give up privacy, in order to gain security. The person we aim to help must have complete control of the system, the sensors and the captured data and media. In addition, the device must not simply record a stream of video, audio and sensors, hoover-ing up all things. Only when configurable sensor thresholds are crossed, is any data recorded permanently in the log. All of the processing and analysis of the sensor data happens locally on the device, and is only stored locally, and not in a cloud. The device itself can be protected by a strong password and disk encryption, to stop intruders from meddling or accessing any data.

SIGNAL’D AND ONION’D

If the intruders chooses to destroy or make off with a Haven device, thats fine. The every act of vandalism and theft is detected in progress, and the owner of the device is notified in real-time. All photos and audio can be sent remotely via notifications, ensuring the evidence is safe. Haven does currently support optional plaintext SMS notifications. This does leak some data to the mobile operator or anyone who can access your text messages, that you are using Haven.

Click to view our online presentation on Haven

We provided SMS support because we wanted Haven to be used in parts of the world where mobile internet access isn’t available, is too expensive, or is heavily censored. The notification message sent over SMS provide minimal information to an attacker. Better than SMS, however, is the integrated support for sending fully end-to-end encrypted notifications, with photo and audio attachments, over Signal. This method allows you to use a device without a SIM card, or in airplane mode, since Signal utilizes the internet for communication, not the mobile operator network. Haven also includes support for Tor’s Onion Services, through integration with Orbot, the Tor app for Android. This allows you to activate a web service on your device, and make it accessible via a “.onion” address, which you can access from any Tor-enabled browser, like Tor Browser, Orfox or Onion Browser. This provides a surveillance-free, end-to-end encrypted channel between you and your device, through which you can access all data stored in Haven, past and present.

INTERNET OF SHODDY THINGS

At this point, you might be saying to yourself “Wait, did these paranoid privacy hackers just building a surveillance camera? Are they trying to sell me on some kind of IoT crap?”. While we didn’t set out to try to address the insane amount of vulnerabilities, insecurities, and fundamental flaws that most most commercial home security devices have, we do admit that our work on Haven crosses over into that problem space. We knew that journalists, activists and others were not interested in setting up cameras and microphones watching themselves ²⁴⁄₇, streaming to the cloud, as a solution to their threat. We also knew, as discussed before, that linking any solution to a centralized cloud service that asked you to trust them, also didn’t make sense.

What we’ve built then could be seen as a competitor to commercial solutions, except for a few key points. First, it is freely licensed, and open-source, enabling anyone to audit it, improve it, remix it, and use as they see fit. It runs on any hardware that can support the Android operating system back to version 4.1. This includes not just smartphones, but also tablets, Raspberry Pi’s, TV set top boxes and sticks, and the emerging Android Things platform. This makes it portable, battery powered, and able to run on devices that are readily available for very little money, anywhere in the world. It takes advantage of many more sensors than a typical home security product, and can easily be expanded to support more. Most importantly, all network communications can be encrypted using other open-source gold standards such as Signal and Tor. You can receive notifications from and access in real-time your Haven device anywhere in the world, completely privately, without any third-party even knowing you are doing so. This addresses the primary threat of remote network intruders, device botnets, and legal actions, as well. The goal is for someone to be able to use Haven, without anyone knowing they are.

With these innovations, we have set the bar for what a personal security device should be, and do. We know that many people this holiday season will be setting up new cameras around the house, on their front door, in their car… pretty much everywhere, and letting a third-party tap into all of that content. We think that Haven shows a better way, that provides just as much, if not more, peace of mind.

THE ROAD AHEAD AND YOU!

Today, we are announcing our public beta, and beginning to promote the open-source project. Haven was originally built upon our previous work with CameraV and ProofMode, as well as a project called SecurIt from developer Marco Ziccardi (https://github.com/mziccard), which is how we went from an idea to a pretty cool app in about eight months. The team at Guardian Project, has been doing the bulk of the work up to this point, but as with all of our projects, we look to expand our contributions to the community. If you are interested in this project, for your own use, as an activist, or as a developer, designer or hardware hacker, we need your help. Here’s a quick set of things to do to join:

Check out the Github issues and the Prototype Project board, pick some things to work on or provide feedback on
Come talk with us at the Guardian Project through our points of contact: https://guardianproject.info/contact
Test Haven out on your hardware and let us know if you find any issues (see havenapp.org for links)
Share your user stories, personas, threats and more, to ensure we are keeping your needs in mind
Donate (Bitcoin accepted!) to support our ongoing efforts: https://freedom.press/donate-support-haven-open-source-project/

Thanks for reading this far, and being interested in our ongoing work, to ensure people are empowered by mobile technology, and not endangered by it. Happy Holidays, and remember: keep watch, stay safe!

Building the most private app store

Thu, 02 Jun 2016 11:08:52 -0400

App stores can work well without any tracking at all

Attackers are increasingly seeing app stores as a prime attack vector, whether it is aimed at the masses like XCodeGhost or very targeted like in FBI vs Apple. When we install software from an app store, we are placing a lot of trust in a lot of different parties involved in getting the source code from the original developer delivered to our device in a useful form. Most people are entirely unaware of how much trust they are putting into this system, which they are entrusting with their personal data. Even for people who do understand the technical details involved, figuring out whether the people and the system itself is trustworthy is difficult to do.

We are building an app store that requires the bare minimum of trust: only the software developers themselves and the code they produce. We consider the app store operators and servers a threat. Building an ecosystem that enables automated, effective auditing lets the computers verify to make trust decisions easier. Effective external auditing requires an ecosystem that cannot deliver targeted content to just the auditing system, while feeding users something else (aka “binary transparency”).

Most app stores track as much as possible

The vast majority of apps stores track their users actions in detail. Some is necessary when using the business model of the app store operator taking a percentage of sales, but none of the tracking is inherent to running an app store. For example, payment verification can be handled in the app itself like shareware. A software delivery system that tracks its users makes it simple to hide malware delivery since it can target any auditing system. Most app stores know a lot about their users:

account name
identity
payment methods
everything you search for in the app store
everything you look at in the app store
everything you download, install, uninstall
which apps you actually run
where you are, based on IP, declared preference, etc.
your preferred language
and more…

Apps stores need to know very little in order to function: how to give you the files you request. That means indexes, descriptions, icons, apps, and install/delete requests (for “push” install/delete). Given that information, the client can do everything needed to provide a full app store user experience. For this work, we chose to build upon F-Droid, a community-run Android app store that distributes verified Free Software. The community has had an interest in privacy all along, and has always worked to avoid tracking. The security architecture is based on models proven by Debian, The Update Framework , and others:

HTTPS connections by default
pinned TLS certificate built into the client app
updates verified based on the signature on the app itself
file integrity protected by signed metadata
signed metadata includes hashes of the app and its signing key
signed metadata generated on a separate machine, which can be fully offline
public key for verifying metadata signatures built into F-Droid client app
signed metadata includes timestamp and expiry

While the current setup is already a solid platform, we are implementing a number of improvements. The signed metadata will include list of official mirrors, then the client chooses mirrors based on availability and freshness based on local criteria like whether Tor is in use, closest on the internet, etc. We are also moving the standard HTTP “etag” cache check from the server to the client so it cannot be abused to track users.

In order to defend against an attacker that holds the signing keys for the app repository, there must be a trustworthy source of information to compare against. Reproducible builds means that anyone with the same source code will produce the exact same binary. When paired with an auditing system, it is easy to catch malware inserted in the build process, rather than the source code, like XCodeGhost. Reproducible builds also makes it possible to have all builds of a release binary have the exact same hash. Then any app repository can build apps only from source code, and have a source of verification data from any other app repository building the same app. Building software from source has become cheap enough that many companies like gitlab.com and Travis CI are offering free, automated build services in the cloud. Since the whole F-Droid toolset is free software and designed to be easy to setup, the barriers to setting up automatic auditing are quite low. People in separate areas of the world with different risk profiles can run verification servers to provide more trustworthy information.

Another key aspect of the F-Droid project is to provide the complete toolset needed to run an app store. This enables a more decentralized ecosystem. Therefore, one key goal is to lower the risks of running the services, so that more people can run their own app stores. If the app store does not track its users, then that removes the hassle of protecting personal data from any attacker. These services can be run without fear of responding to secret orders for personal information. It also means that the server setup is a lot simpler because it does not need dynamic content. The app store serve only needs to serve files (e.g. indexes, apps, etc.). The app repository is generated on a secure machine, or even a fully offline machine, and posted to the server. The main server is purely a mirror of the offline machine where the signed repository is generated. Mirrors just shuffle bits from place to place, they are no longer an attack vector.

Putting all these pieces together provides a system where users need only audit the source code in order to verify a trustworthy app delivery. The file pipeline provides redundantly secure data transmission, the apps can be reproducibly from source code, the app repositories can be automatically audited. Of course, this system relies not only on the power of cryptography, but also the power of transparency. Debian provides a great example of the power of transparency: Debian gives a thousand volunteers root access to every Debian install (by virtue of their ability to upload signed packages that get installed as root). Yet this system has been proven over the past 20+ years to provide solid security. Ultimately we hope that this will de-emphasize the signing key as the sole protection against abuse. If malware has a decent change of being spotted, it makes it much less likely to be used since malware authors either rigorously defend their exploits, or use well known exploits that are not difficult to automatically detect.

Future Work

One attack vector that is not well covered is malware that installable by everyone, that then uses data on the local device to target specific users. That would be a way to target individuals using an app store that does not track its users. We are starting to implement automated dynamic analysis of every app using tools like Drozer.

We are also working towards making as many apps as possible build reproducibly. Some of our quick checks show that a large number of the apps in f-droid.org already will build reproducibly, given the right build environment. We are working on making the process of setting up that build environment as automated as possible.

The F-Droid “verification server” has been prototyped, and it will be further developed with the aim of making it dead simple to run in common cloud services.

We already have the infrastructure in place to do verified double-signing, where the developer first signs the release bulid, then once f-droid.org reproduces that build, it adds its signature. Then Android would enforce that both signatures need to be present in order for it to be a valid update.

As the full localization support is built out, the language that a user is using will not be reported to the server. While speaking Spanish in Spain does not provide much information, speaking Quechua in Uzbekistan can narrow it down to a single user. Instead of dividing the index metadata by language, it will instead be grouped by app. We will then group apps so that it is difficult to tell which app in the group is the one people are interested in. For example, if one very popular app is only grouped with apps that are rarely downloaded, then it is an easy assumption that someone getting info about that block of apps is most likely looking for that popular app.

Copperhead, Guardian Project and F-Droid Partner to Build Open, Verifiably Secure Mobile Ecosystem

Mon, 28 Mar 2016 13:42:36 -0400

Three open-source projects haved joined together to announce a new partnership to create an open, verifiably secure mobile ecosystem of software, services and hardware. Led by the work of the Toronto-based CopperheadOS team on securing the core Android OS, Guardian Project and F-Droid have joined in to partner on envisioning and developing a full mobile ecosystem. The goal is to create a solution that can be verifiably trusted from the operating system, through the network and network services, all the way up to the app stores and apps themselves. Through a future planned crowdfunded and commercial offering, the partnership will provide affordable off-the-shelf solutions, including device hardware and self-hosted app and update distribution servers, for any individual and organizations looking for complete mobile stacks they can trust.

Update 30 March 2016: Copperhead has announced their crowdfunding plans here.

CopperheadOS is a hardened open-source Android based on AOSP, that is available for download and installation on many Nexus devices. The Guardian Project develops popular free and open-source privacy-enhancing apps like Orbot (Tor for Android), ChatSecure, and ObscuraCam, and software libraries like NetCipher, SQLCipher and PanicKit, for developers who want to enable similar features in their own apps. F-Droid is an installable catalogue of free and open source Android software, that is built into CopperheadOS, as the default app store. It enables decentralized and verifiably secure app distribution by any individual or organization.

“I have been a happy CopperheadOS user since the first moment I installed it”, says Nathan Freitas, Founder and Director of Guardian Project, ” even with running it on a two-generation old, very inexpensive Nexus 5 device. I know I will always have the latest security updates immediately, and that everything on my device is under my control.”

“My Copperhead Nexus is the go-to device in my bag, ” says Freitas, “when I am handling sensitive information, find myself on a network I don’t trust, or am otherwise wary about my communication being tracked, intercepted or tampered with.”

Hans-Christoph Steiner who leads the Guardian Project’s developer platform says “Copperhead with F-Droid and Orbot provides all of the benefits of a smartphone, without the security and privacy downsides introduced by the major vendors, carriers and closed app stores. By building in F-Droid, Copperhead guarantees its users have direct access to the best free and open software, built directly from source-code in a trusthworthy, verifiable way”. Mr. Steiner presented on his work with F-Droid and building “private, unblockable app stores” at FOSDEM 2016 in January.

_Learn more about F-Droid from this FOSDEM 2016 talk (watch the video here)_

Collectively, this partnership creates a global team of information security researchers, forensic analysts, software developers, designers and engaged users, looking to move the state of the art forward for open, verifiably secure and privacy-enhancing mobile technology. The groups hope to expand the effort to include other mobile OS teams, application developers and even hardware developers interested in having the same kind of impact on the privacy and security of mobile computing.

James Donaldson of Copperhead says “It’s important for Android users to have a privacy minded viable alternative to closed-source solutions when contemplating mobile security. Teaming up with great partners like F-Droid and Guardian Project allows us to offer our users both security and a great experience with all of the core features they need.”

Guardian Project is an open-source effort based in New York, with a global community of contributors and partners. Copperhead is an information security firm located in Toronto, Canada, specializing in protecting data and devices from unauthorized access. F-Droid is a non-profit volunteer project, and is operated by F-Droid Limited, a non-profit organisation registered in England (no. 8420676).

Contact:

Nathan Freitas / +1 718 569 7272
nathan@guardianproject.info (XMPP-OTR, OpenPGP: 0x69B37AA9 / https://keybase.io/n8fr8)

James Donaldson / Copperhead
media@copperhead.co (OpenPGP: 0xDC1DEA5E )

How to Migrate Your Android App’s Signing Key

Tue, 29 Dec 2015 12:03:54 -0400

It is time to update to a stronger signing key for your Android app! The old default RSA 1024-bit key is weak and officially deprecated.

What?

The Android OS requires that every application installed be signed by a digital key. The purpose behind this signature is to identify the author of the application, allow this author and this author alone to make updates to the app, as well as provide a mechanism to establish inter-application trust. The Android security model defines an app by two things: the package name (aka packageName, ApplicationID, package) and the signing key. If either of those are different, then Android considers it a different app. When the package name and signing key of one APK match an installed app, then the APK is considered an update and Android will replace the installed app with the APK. If the APK is signed by a different key, then Android will prevent installing and updating.

First thing is to see what the current signing key is. Check any app’s signing key using our free utility app Checkey:

Lookout needs to generate a new key!

The official Android docs have tons of useful information about what the signing keys are good for, how to generate them, and how to use them. Unfortunately, it doesn’t provide any instructions for migrating, and for many years, 1024-bit RSA was the default. But first, why would you want or need to migrate?

Why?

Depending on when you created your signing key, you might have a particularly weak key. The primary danger of a weak key is that an adversary could break your key in order to generate fake APK signatures. Then those malicious APKs can be installed as updates to your app. There are other nefarious purposes depending on how you use the signing key in your apps. Or if you are unfortunate enough to have suffered a loss of your private key material, then it is definitely time for a new signing key.

According to our friends at the Android Observatory, over 64% of Android apps in their data store use 1024-bit signing keys (RSA or DSA).

There are several good reasons to migrate off of 1024-bit RSA keys, even though there is no public proof of a 1024 prime factorization required to generate any 1024-bit key at will. The evidence has been mounting for a decade.

NIST’s official guidelines (PDF, page 64 and 67) deprecated 1024-bit RSA keys at the end of 2013. This deprecation by NIST isn’t an indication that 1024-bit RSA is compromised, instead it is a preemptive move to stay ahead of attacks. Confidence in NIST might be shaken in light of recent revelations, but in this case increasing the RSA key size is unlikely to trigger any secret NSA backdoors. If anything, the deprecation year could have been extended slightly to allow the NSA a window where they had the capacity to factor 1024-bit keys and everyone was still using them. So, it’s time to move on.

For an example, a decade ago the cost of building special purpose hardware capable of breaking a single 1024-bit RSA key in one year was estimated at $10 million (Adi Shamir, Eran Tromer, On the cost of factoring RSA-1024, 2003). Presumably the techniques have improved by orders of magnatude, and the hardware value depreciated. It is conceivable the cost has fallen enough to be affordable not only by nation-state actors, but by large criminal enterprises too.

For a comprehensive talk on the state of the art (as of December 2012) when it comes to breaking 1024-bit RSA, check out the 29C3 talk FactHacks: RSA factorization in the real world with the cryptographers Daniel J. Bernstein, Nadia Heninger, and Tanja Lange (watch recording)

How?

Migrating to a strong key for an Android app is, unfortunately, not so simple. If you are publishing a new app to the app store, then simply generate a new strong signing key and you’re done. Congratulations! However, there exists no easy way to update your signing key for an existing application, because an installed application can only take updates from an APK signed with the same key.

Here we outline a basic method with which you can use to fake an update to your signing key. This is not as user friendly as we would like. Some of the hard facts of performing this process is that for most app stores including Google Play, you will lose ratings and reviews since the app will show up with a new package name, and the app store will treat it like an entirely new app. Also, the user will have to manually uninstall the original app once they finish the procedure. Here is a rough outline of the process:

generate the new signing key, RSA 4096
Update the first app, App1, with a mechanism for exporting private data, using TrustedIntents with a signature pin of the new key, RSA 4096, which Checkey will generate for you
Create a new version of the app with a different package name, App2
sign App2 with new key, RSA 4096
Add method to App2 for receiving user data from App1, including a signature pin of the old signing key, RSA 1024, for use with TrustedIntents
Publish App2 to the app stores
From App1, prompt user to install App2
runs and imports data from App1
App2 prompts user to uninstall App1

For F-Droid, there will be some easier tools for handling this. The F-Droid system is already used to multiple signing keys per app since F-Droid uses its own signing key for many of the apps it releases, and that F-Droid signing key is different from the signing key that the original developer used in their Google Play uploads. F-Droid will likely be able to support APKs with the same package name but with multiple signing keys.

A Note on Compatibility

There is security vs compatibility trade off a few might be interested in. Pre-4.3, Android did not support any signature algorithms except SHA1. With Android >= 4.3, SHA256 support was fixed, and SHA384, SHA512, and ECDSA were added (source). There are still android 2.3.3 (android-10) devices being sold, so anyone interested in backwards compatibility will have to heed this.

Also, the larger the keysize and hashsize used, the longer it takes to install and update the application. So extremely large values might be unsuitable for slower hardware. The following probably doesn’t buy you a tremendous amount of additional security but cranks the paranoia to 11. It does so at the cost of compatibility and performance.
 Gen with: keytool -genkey -v -keystore test.keystore -alias testkey -keyalg RSA -keysize 4096 -sigalg SHA512withRSA -dname "cn=Test,ou=Test,c=CA" -validity 10000 Sign with: jarsigner -verbose -sigalg SHA512withRSA -digestalg SHA512 -keystore test.keystore test.apk testkey 

We have some scripts that we use to generate keys in our smartcard-apk-signing repo. It is also possible to generate an Android signing key using openssl or other libraries. It is often wise to use different software than standard for doing things like generating keys. Since the Java keytool approach that is the standard, recommended method for Android, that makes it a target for adversaries that are interested in breaking keys. If a key was generated using openssl or GNU TLS instead, for example, then that key would not be affected if keytool had a bug like Debian’s CVE-2008-0166.

First working test of IOCipher for Obj-C

Mon, 26 Jan 2015 04:32:29 -0400

Every so often, we revisit our core libraries in the process of improving our existing apps, and creating new ones. IOCipher has become a standard part of our apps since it provides a really easy way to include encrypted file storage in Android apps. And we are now working on spreading it to iOS as well, headed up by Chris Ballinger, with the first preliminary tests of IOCipher for Obj-C. Testing and contributions are most welcome! Find us in our chat room or mailing list for questions, or just post a comment below! Since the iOS version is based on the exact same core library, libsqlfs, the container files they produce will also be fully compatible with each other.

Now that iOS 8 has full disk encryption by default and a host of other security improvements, you might be wondering why you would bother with app-specific encryption. The problem with full disk encryption is that the disk is only locked when your iPhone is fully turned off. Using IOCipher adds protection for sensitive data that helps in a few different scenarios.

First, full disk encryption does not protect the data at all if malware is able to get root on the device. That malware will be free to read all files on the device. Second, for people who have not set up a strong passphrase on their iOS device, using app-specific encrypted storage make it harder to access that app’s data on devices with no passcode set, especially if any additional passphrase is stored in the keychain and disallowed from backup, or if it’s just stored in your own memory.

Third is for added protetion from forensic acquisition systems, which often work using root exploits in order to read the entire filesystem without unlocking the screen[1][2][3]. By having an app-specific encrypted file container that is not mounted like a filesystem, then even root cannot directly access the files in the container. Even root needs to get the key in order to unlock the IOCipher container, whether it is in use or not, and getting that key means either a key logger, which means planning ahead, or reading they key from memory if the container is unlocked, which is a more elaborate and targeted attack that full disk acquisition after rooting.

Now consider that there is a large market 0days, i.e. unpublished exploits, and companies like VUPEN, FinFisher, and Hacking Team making it easy to purchase them, even providing guarantees that one of their exploits will work within 30 days, it seems quite likely that customers of such companies have access to secret root exploits to even iOS 8. While there are ethical and lawful reasons to use software like this, many governments are also using them for illegal and unethical things. Since we believe that everyone has a right to privacy, to speak freely, and to peaceably protest, it is important to provide protection to people who are unfairly targeted.

There is also another key advantage of the IOCipher approach when it comes to mobile devices. IOCipher is ultimately based on SQLite transactions in SQLCipher, which means that it does not require being mounted in the normal sense. There is no open state once a transaction is complete. Each read or write operation is a self-contained SQLite transaction, so if the file system is forcably quit, SQLite’s transactions prevent the whole file system from being corrupted. This is important in mobile operating systems like Android and iOS since any app or process can be killed at any moment without warning. That means that the worst that can happen to an IOCipher volume is a single write command does not get written. The whole file system will not be corrupted if the process is killed.

Coming Soon

When IOCipher is used in conjunction with our CacheWord library, it is possible for an app to provide protection even against the $5 wrench attack. CacheWord generates a strong passphrase and manages feeding it to IOCipher and SQLCipher. The user provides their own password for encrypting that strong passphrase. That CacheWord file is tiny, and can be rapidly deleted. Once it is gone, the actual passphrase that unlocks the IOCipher encryption is gone, the user’s passphrase will not unlock IOCipher directly. This is something we are working to add in all of our apps, and to also hook it up to panic button triggers. We would be quite happy to see you beat us to it by adding this feature to your app!

IOCipher with a hardware security module (HSM) aka smartcard would be really nice, since it would provide some measure of added protection without the user setting an app-specific passphrase. HSMs provide write-only private key storage locked by pin code, so even if some was able to get the encrypted file and the pincode, they would not be able to retrieve the key to unlock the encrypted file. The only way to unlock the file would be with the physical device itself, or by finding the key backup, if that existed. This is possible now using an external microSD HSM

Reducing metadata leakage from software updates

Thu, 16 Oct 2014 12:48:04 -0400

Update: now you can do this with Tor Onion Services

Many software update systems use code signing to ensure that only the correct software is downloaded and installed, and to prevent the code from being altered. This is an effective way to prevent the code from being modified, and because of that, software update systems often use plain, unencrypted HTTP connections for downloading code updates. That means that the metadata of what packages a machine has installed is available in plain text for any network observer, from someone sitting on the same public WiFi as you, to state actors with full network observation capabilities.

That means that potentially private information is leaking. That private information could be which packages you have installed and which versions. That information can help an attacker figure out the best way to break into the target machine. Also, a unique fingerprint can be generated based on which packages a machine has installed, and that could help de-anonymize traffic that goes over Tor or other anonymity tool.

For people who use apt-get in Debian, Ubuntu or any related GNU/Linux distro, there is a lot of metadata leaked to the internet when apt-get contacts Debian repositories using a standard configuration. Mostly, that is because by default, the connections are unencrypted (http, ftp, rsync). The integrity of the package itself is not reason enough to use HTTPS since the GPG signing is much more reliable for that task. Here is how I break it down:

package authenticity
(software can be modified while being downloaded)
repo availability
( whole sites or specific URL paths can be selectively blocked by governments and companies)
package availability
(software security updates can be individually blocked)
who’s downloading what package (currently visible to anyone who can see the
network traffic, including open wifi, etc.)

The current apt model covers #1 well, but only covers #2 and #3 with a two week window (the expiration date on the repo metadata). And it does not cover #4 at all. Using HTTPS for apt repos is a simple way to improve the security of all 4. It adds a weak backup security layer for #1, it makes it much more difficult for a portion of a large internet mirror to be seletively blocked (e.g. #2 and #3). For example, if you use HTTPS to mirrors.kernel.org, everything has to be blocked to block Debian repos or packages. And pipelining downloads through a reused HTTPS connection makes it very difficult for the network observer to track metadata about packages, #4).

Luckily, there are some relatively easy steps that greatly reduce the amount of metadata that is leaked: using HTTPS connections to the mirrors and running those connections through Tor. Setting apt-get to pipeline as many transactions into a given HTTPS session is also useful, but currently only supported for HTTP and not HTTPS. Even though HTTPS/TLS has security weaknesses, it is a lot better than nothing, and can help provide real world protection. The downside is that it is not common for Debian machines to connect to apt mirrors using HTTPS, so that potentially marks the install as a machine worth targeting. There are more and more HTTPS mirrors, and more interest in using them, so I think in time, that will only lessen as a concern. Here are the HTTPS mirrors that I have had good luck with:

mirrors.ece.ubc.ca
mirrors.kernel.org
mirror.cse.unsw.edu.au
spout.ussg.indiana.edu

On that note, here is the config that I have been using on a number of Debian-deriv machines, and it has been working well. It requires apt-transport-https, and privoxy setup as an HTTP proxy for Tor.

$ cat /etc/apt/apt.conf.d/99force-tor
# force everything through privoxy HTTP proxy to tor
Acquire::ftp::Proxy "http://127.0.0.1:8118";
Acquire::http::Proxy "http://127.0.0.1:8118";
Acquire::https::Proxy "http://127.0.0.1:8118";

# don't use SSL, its insecure, only use TLS
Acquire::https::SslForceVersion "TLSv1";

I have found about 10 official Debian mirrors that have reliable HTTPS. Then I have a script that finds all of them, but many have self-signed certs and other issues. A number of the HTTPS mirrors also mirror the “security” archive, but I recommend that the http URL to the official security.debian.org repo is still included to make sure that security updates are promptly available.

I also have a test security repo running that is only available via an .onion address. I hope to encourage people to run official mirrors on a Tor Hidden Service, then HTTPS is not needed. Note that apt-transport-tor is not required if a tor proxy is setup. To try mine, add it to your sources.list (and make sure apt-get is somehow using Tor). The order is important, that determines the priority of where apt-get will get the package from is all other variables are the same.

deb http://dju2peblv7upfz3q.onion/debian-security/ wheezy/updates main
deb http://security.debian.org/ wheezy/updates main

Update: Use the official Debian Tor Onion Services now, dju2peblv7upfz3q.onion is deprecated and will be shut down!

A specific example: TAILS

TAILS is an operating system that aims to be as private and anonymous as possible to enable, and has allowed journalists like Laura Poitras to work without leaking information despite being targeted by some very skilled and highly resourced organizations. TAILS mostly works as a “live CD”, meaning the whole operating system is downloaded as a single “image” file, then either burned to a CD/DVD, or to a USB thumb drive. Updates work the same way. But TAILS has an optional feature to use the Debian package system to install and persist packages that are not included by default. TAILS does not use the default set of mirrors that a standard Debian install uses, it is set up by default with a range of possible Debian package sources, including the current stable version (called wheezy), the versions in testing, and packages backported to the stable version. That means that when this feature is used, TAILS fetches the metadata for all of those sections of Debian (stable/wheezy, testing, wheezy-backports, unstable).

Given all of the proven fingerprinting approaches, like using the font list from the browser, I think its a safe assumption that the apt-get metadata will also provide similar fingerprinting opportunities. For basic TAILS use, this is all avoided since updates are done via ISO images. But once a user installs packages via apt-get, that changes since TAILS then goes out onto the internet to fetch all of the repo metadata. That goes over Tor since TAILS forces all network traffic over Tor, so that helps break the link between the machine downloading the updates and those that can see that machines internet traffic.

It seems quite likely that the set of mirrors and the order in which they are run will provide a way to identify the system as TAILS. As for identifying individual machines, apt-get sends a lot of metadata, like language that the system is using, which packages need updates, etc. On top of the set of mirrors used, there is potentially enough metadata there to fingerprint the individual machine.

One open question is how the apt-get downloads map to different Tor circuits. If all of the traffic from a given apt-get session goes over a single Tor circuit, then the exit node, the mirror server, and any network observer that can see the traffic between those two can use that as the fingerprint.

To expand on this, if TAILS fetched all of its apt sources (wheezy, backports, testing, etc) via HTTPS from the same mirror (e.g. mirrors.kernel.org), then the exit node and network observer could not really distinguish the distro the machine making the connection was running since mirrors.kernel.org hosts many distro mirrors. There are two key parts here: using HTTPS to encrypt the data, and using HTTP pipelining so that network connections are reused for multiple downloads, rather than the default behavior of making a new HTTPS for each individual download. This setup would also prevent the custom pattern of apt sources from being distinguished since it would just show as downloading some series of files, and those files could be packages, package metadata, perl modules, source tarballs, etc.

CipherKit updates: IOCipher and CacheWord

Fri, 26 Sep 2014 21:39:54 -0400

We’ve been on a big kick recently, updating the newest members of our CipherKit family of frameworks: IOCipher and CacheWord. There also are is a little news about the original CipherKit framework: SQLCipher-for-Android.

IOCipher v0.2

IOCipher is a library for storing files in an encrypted virtual disk. It’s API is the exact same as java.io for working with files, and it does not need root access. That makes it the sibling of SQLCipher-for-Android, both are native Android APIs that wrap the SQLCipher database.

This round of work focused on making IOCipher more reliable and secure, and easy to integrate with CacheWord. It can now handle files up to 4GB in size, the same as FAT filesystems, and it has much improved performance, especially under concurrent load. There is now also an unmount() method to lock the database and wipe the key from memory. The central VirtualFileSystem class is now a singleton, since you can only have a single virtual disk open at a time. Lastly, the IOCipher release now includes binaries for armeabi, armeabi-v7a, and x86. IOCipher v0.2 was built against SQLCipher-for-Android v3.1.0, and that is the minimum recommended version to use.

Find downloads, example projects, test suites, and more on the IOCipher page. Follow the development on the IOCipher project page.

CacheWord v0.1

Once you are using SQLCipher and IOCipher, then you’ll definitely need to do some password management, and password caching too, since no one wants to type their password again every time they come to an app. That is where CacheWord comes in: it is a library for managing passwords, and it is designed easily feed directly into SQLCipher and IOCipher, or really anything that needs secure password caching.

Most of this update was about making CacheWord ready to deploy. That means fixing bugs and drastically simplifying it’s dependencies. CacheWord now can be used as a plain jar file or an Android Library Project, and it only depends on android-support-v4.jar.

Part of the process of simplifying CacheWord also involved stripping down the API to only want CacheWord should really handle. The standard API is all in the CacheWordHandler class. So that means that your app has to handle any Notification, and pass it to CacheWord if you want CacheWordService to run in the foreground.

CacheWord also now dynamically chooses how many iterations of the key derivation function based on the CPU type. That means that new, fast devices, the derived key will be a lot stronger, while on slow, old devices, it won’t take a minute to unlock your app.

Find downloads, example projects, and more on the CacheWord page. Follow the development on the CacheWord project page.

SQLCipher

The upcoming release of SQLCipher-for-Android also has been simplified. It will no longer depend on commons-codec.jar or guava-r09.jar (thanks to Jeff Campbell for submitting those commits!), remove ~8000 methods for those who fear running into the 65k method limit of the classes.dex file. We’ve been working on making the build process be reproducible, so that anyone can verify that the official releases are built only from the source in the git repo, and nothing else has been added. We’re also working on moving the password format conversion code out of CacheWord and into SQLCipher, where it belongs.

Security in a thumb drive: the promise and pain of hardware security modules, take one!

Fri, 28 Mar 2014 16:54:39 -0400

Hardware Security Modules (aka Smartcards, chipcards, etc) provide a secure way to store and use cryptographic keys, while actually making the whole process a bit easier. In theory, one USB thumb drive like thing could manage all of the crypto keys you use in a way that makes them much harder to steal. That is the promise. The reality is that the world of Hardware Security Modules (HSMs) is a massive, scary minefield of endless technical gotchas, byzantine standards (PKCS#11!), technobabble, and incompatibilities. Before I dive too much into ranting about the days of my life wasted trying to find a clear path through this minefield, I’m going to tell you about one path I did find through to solve a key piece of the puzzle: Android and Java package signing.

For this round, I am covering the Aventra MyEID PKI Card. I bought a SIM-sized version to fit into an ACS ACR38T-IBS-R smartcard reader (it is apparently no longer made, and the ACT38T-D1 is meant to replace it). Why such specificity you may ask? Because you have to be sure that your smartcard will work with your reader, and that your reader will have a working driver for you system, and that your smartcard will have a working PKCS#11 driver so that software can talk to the smartcard. Thankfully there is the OpenSC project to cover the PKCS#11 part, it implements the PKCS#11 communications standard for many smartcards. On my Ubuntu/precise system, I had to install an extra driver, libacr38u, to get the ACR38T reader to show up on my system.

So let’s start there and get this thing to show up! First we need some packages. The OpenSC packages are out-of-date in a lot of releases, you need version 0.13.0-4 or newer, so you have to add our PPA (Personal Package Archive) to get current versions, which include a specific fix for the Aventra MyEID: (fingerprint: F50E ADDD 2234 F563):

sudo add-apt-repository ppa:guardianproject/ppa
sudo apt-get update
sudo apt-get install opensc libacr38u libacsccid1 pcsc-tools usbutils

First thing, I use lsusb in the terminal to see what USB devices the Linux kernel sees, and thankfully it sees my reader:

$ lsusb
Bus 005 Device 013: ID 072f:9000 Advanced Card Systems, Ltd ACR38 AC1038-based Smart Card Reader

Next, its time to try pcsc_scan to see if the system can see the smartcard installed in the reader. If everything is installed and in order, then pcsc_scan will report this:

$ pcsc_scan 
PC/SC device scanner
V 1.4.18 (c) 2001-2011, Ludovic Rousseau <&#x6c;u&#x64;ov&#x69;c.&#x72;o&#x75;&#x73;s&#x65;au&#x40;f&#x72;&#x65;e&#x2e;fr>
Compiled with PC/SC lite version: 1.7.4
Using reader plug'n play mechanism
Scanning present readers...
0: ACS ACR38U 00 00

Thu Mar 27 14:38:36 2014
Reader 0: ACS ACR38U 00 00
  Card state: Card inserted, 
  ATR: 3B F5 18 00 00 81 31 FE 45 4D 79 45 49 44 9A
[snip]

If pcsc_scan cannot see the card, then things will not work. Try re-seating the smardcard in the reader, make sure you have all the right packages installed, and if you can see the reader in lsusb. If your smartcard or reader cannot be read, then pcsc_scan will report something like this:

$ pcsc_scan 
PC/SC device scanner
V 1.4.18 (c) 2001-2011, Ludovic Rousseau <&#x6c;&#x75;&#x64;&#x6f;&#x76;&#x69;c.rousse&#x61;&#x75;&#x40;&#x66;&#x72;&#x65;e.fr>
Compiled with PC/SC lite version: 1.7.4
Using reader plug'n play mechanism
Scanning present readers...
Waiting for the first reader...

Moving right along… now pcscd can see the smartcard, so we can start playing with using the OpenSC tools. These are needed to setup the card, put PINs on it for access control, and upload keys and certificates to it. The last annoying little preparation tasks are finding where opensc-pkcs11.so is installed and the “slot” for the signing key in the card. These will go into a config file which keytool and jarsigner need. To get this info on Debian/Ubuntu/etc, run these:

$ dpkg -S opensc-pkcs11.so
opensc: /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
$ pkcs11-tool --module /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so \
>     --list-slots
Available slots:
Slot 0 (0xffffffffffffffff): Virtual hotplug slot
  (empty)
Slot 1 (0x1): ACS ACR38U 00 00
  token label        : MyEID (signing)
  token manufacturer : Aventra Ltd.
  token model        : PKCS#15
  token flags        : rng, login required, PIN initialized, token initialized
  hardware version   : 0.0
  firmware version   : 0.0
  serial num         : 0106004065952228

This is the info needed to put into a opensc-java.cfg, which keytool and jarsigner need in order to talk to the Aventra HSM. The name, library, and slot fields are essential, and the description is helpful. Here is how the opensc-java.cfg using the above information looks:

name = OpenSC
description = SunPKCS11 w/ OpenSC Smart card Framework
library = /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
slot = 1

Now everything should be ready for initializing the HSM, generating a new key, and uploading that key to the HSM. This process generates the key and certificate, puts them into files, then uploads them to the HSM. That means you should only run this process on a trusted machine, certainly with some kind of disk encryption, and preferably on a machine that is not connected to a network, running an OS that has never been connected to the internet. A live CD is one good example, I recommend Tails on a USB thumb drive running with the secure persistent store on it (we have been working here and there on making a TAILS-based distro specifically for managing keys, we call it CleanRoom).

HSM plugged into a laptop

First off, the HSM needs to be initialized, then set up with a signing PIN and a “Security Officer” PIN (which means basically an “admin” or “root” PIN). The signing PIN is the one you will use for signing APKs, the “Security Officer PIN” (SO-PIN) is used for modifying the HSM setup, like uploading new keys, etc. Because there are so many steps in the process, I’ve written up scripts to run thru all of the steps. If you want to see the details, read the scripts. The next step is to generate the key using openssl and upload it to the HSM. Then the HSM needs to be “finalized”, which means the PINs are activated, and keys cannot be uploaded. Don’t worry, as long as you have the SO-PIN, you can erase the HSM and re-initialize it. But be careful! Many HSMs will permanently self-destruct if you enter in the wrong PIN too many times, some will do that after only three wrong PINs! As long as you have not finalized the HSM, any PIN will work, so play around a lot with it before finalizing it. Run the init and key upload procedure a few times, try signing an APK, etc. Take note: the script will generate a random password for the secret files, then echo that password when it completes, so make sure no one can see your screen when you generate the real key. Alright, here goes!

code $ git clone https://github.com/guardianproject/smartcard-apk-signing
code $ cd smartcard-apk-signing/Aventra_MyEID_Setup
Aventra_MyEID_Setup $ ./setup.sh 
Edit pkcs15-init-options-file-pins to put in the PINs you want to set:
Aventra_MyEID_Setup $ emacs pkcs15-init-options-file-pins
Aventra_MyEID_Setup $ ./setup.sh 
Using reader with a card: ACS ACR38U 00 00
Connecting to card in reader ACS ACR38U 00 00...
Using card driver MyEID cards with PKCS#15 applet.
About to erase card.
PIN [Security Officer PIN] required.
Please enter PIN [Security Officer PIN]: 
Using reader with a card: ACS ACR38U 00 00
Connecting to card in reader ACS ACR38U 00 00...
Using card driver MyEID cards with PKCS#15 applet.
About to create PKCS #15 meta structure.
Using reader with a card: ACS ACR38U 00 00
Connecting to card in reader ACS ACR38U 00 00...
Using card driver MyEID cards with PKCS#15 applet.
Found MyEID
About to generate key.
Using reader with a card: ACS ACR38U 00 00
Connecting to card in reader ACS ACR38U 00 00...
Using card driver MyEID cards with PKCS#15 applet.
Found MyEID
About to generate key.
next generate a key with ./gen.sh then ./finalize.sh
Aventra_MyEID_Setup $ cd ../openssl-gen/
openssl-gen $ ./gen.sh 
Usage: ./gen.sh "CertDName" [4096]
  for example:
  "/C=US/ST=New York/O=Guardian Project &#x54;e&#x73;&#x74;/&#x43;N=&#x74;es&#x74;.&#x67;&#x75;a&#x72;di&#x61;np&#x72;o&#x6a;&#x65;c&#x74;&#x2e;i&#x6e;fo&#x2f;em&#x61;i&#x6c;&#x41;d&#x64;re&#x73;s=&#x74;e&#x73;&#x74;@&#x67;&#x75;a&#x72;di&#x61;np&#x72;o&#x6a;&#x65;c&#x74;.i&#x6e;fo"
openssl-gen $ ./gen.sh "/C=US/ST=New York/O=Guardian Project Te&#x73;t&#x2f;C&#x4e;=&#x74;e&#x73;t&#x2e;g&#x75;ardi&#x61;n&#x70;r&#x6f;j&#x65;c&#x74;.&#x69;n&#x66;o/em&#x61;i&#x6c;A&#x64;d&#x72;e&#x73;s&#x3d;t&#x65;st&#x40;g&#x75;a&#x72;d&#x69;a&#x6e;p&#x72;o&#x6a;e&#x63;t.&#x69;n&#x66;o"
Generating key, be patient...
2048 semi-random bytes loaded
Generating RSA private key, 2048 bit long modulus
.......................................+++
..................................................+++
e is 65537 (0x10001)
Signature ok
subject=/C=US/ST=New York/O=Guardian Project Test/&#x43;&#x4e;&#x3d;&#x74;&#x65;st.gu&#x61;&#x72;&#x64;&#x69;&#x61;nproj&#x65;&#x63;&#x74;&#x2e;&#x69;nfo/e&#x6d;&#x61;&#x69;&#x6c;&#x41;ddres&#x73;&#x3d;&#x74;&#x65;&#x73;t@gua&#x72;&#x64;&#x69;&#x61;&#x6e;proje&#x63;&#x74;&#x2e;&#x69;&#x6e;fo
Getting Private key
writing RSA key
Your HSM will prompt you for 'Security Officer' aka admin PIN, wait for it!
Enter destination keystore password:  
Entry for alias 1 successfully imported.
Import command completed:  1 entries successfully imported, 0 entries failed or cancelled
[Storing keystore]
Key fingerprints for reference:
MD5 Fingerprint=90:24:68:F3:F3:22:7D:13:8C:81:11:C3:A4:B6:9A:2F
SHA1 Fingerprint=3D:9D:01:C9:28:BD:1F:F4:10:80:FC:02:95:51:39:F4:7D:E7:A9:B1
SHA256 Fingerprint=C6:3A:ED:1A:C7:9D:37:C7:B0:47:44:72:AC:6E:FA:6C:3A:B2:B1:1A:76:7A:4F:42:CF:36:0F:A5:49:6E:3C:50
The public files are: certificate.pem publickey.pem request.pem
The secret files are: secretkey.pem certificate.p12 certificate.jkr
The passphrase for the secret files is: fTQ*he-[:y+69RS+W&+!*0O5i%n
openssl-gen $ cd ../Aventra_MyEID_Setup/
Aventra_MyEID_Setup $ ./finalize.sh 
Using reader with a card: ACS ACR38U 00 00
Connecting to card in reader ACS ACR38U 00 00...
Using card driver MyEID cards with PKCS#15 applet.
Found MyEID
About to delete object(s).
Your HSM is ready for use! Put the secret key files someplace encrypted and safe!

Now your HSM should be ready for use for signing. You can try it out with keytool to see what is on it, using the signing PIN not the Security Officer PIN:

smartcard-apk-signing $ /usr/bin/keytool -v \
>     -providerClass sun.security.pkcs11.SunPKCS11 \
>     -providerArg opensc-java.cfg \
>     -providerName SunPKCS11-OpenSC -keystore NONE -storetype PKCS11 \
>     -list
Enter keystore password:  

Keystore type: PKCS11
Keystore provider: SunPKCS11-OpenSC

Your keystore contains 1 entry

Alias name: 1
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: &#x45;&#x4d;&#x41;&#x49;&#x4c;&#x41;&#x44;&#x44;RESS=test@g&#x75;&#x61;&#x72;&#x64;&#x69;&#x61;&#x6e;&#x70;&#x72;oject.info, CN=test.guardianproject.info, O=Guardian Project Test, ST=New York, C=US
Issuer: E&#x4d;A&#x49;LA&#x44;D&#x52;ES&#x53;=&#x74;e&#x73;&#x74;@&#x67;u&#x61;rd&#x69;a&#x6e;pr&#x6f;j&#x65;ct&#x2e;i&#x6e;f&#x6f;, CN=test.guardianproject.info, O=Guardian Project Test, ST=New York, C=US
Serial number: aa6887be1ec84bde
Valid from: Fri Mar 28 16:41:26 EDT 2014 until: Mon Aug 12 16:41:26 EDT 2041
Certificate fingerprints:
	 MD5:  90:24:68:F3:F3:22:7D:13:8C:81:11:C3:A4:B6:9A:2F
	 SHA1: 3D:9D:01:C9:28:BD:1F:F4:10:80:FC:02:95:51:39:F4:7D:E7:A9:B1
	 SHA256: C6:3A:ED:1A:C7:9D:37:C7:B0:47:44:72:AC:6E:FA:6C:3A:B2:B1:1A:76:7A:4F:42:CF:36:0F:A5:49:6E:3C:50
	 Signature algorithm name: SHA1withRSA
	 Version: 1


*******************************************
*******************************************

And let’s try signing an actual APK using the arguments that Google recommends, again, using the signing PIN:

smartcard-apk-signing $ /usr/bin/jarsigner -verbose \
>     -providerClass sun.security.pkcs11.SunPKCS11 \
>     -providerArg opensc-java.cfg -providerName SunPKCS11-OpenSC \
>     -keystore NONE -storetype PKCS11 \
>     -sigalg SHA1withRSA -digestalg SHA1 \
>     bin/LilDebi-release-unsigned.apk 1
Enter Passphrase for keystore: 
   adding: META-INF/1.SF
   adding: META-INF/1.RSA
  signing: assets/busybox
  signing: assets/complete-debian-setup.sh
  signing: assets/configure-downloaded-image.sh
  signing: assets/create-debian-setup.sh
  signing: assets/debian-archive-keyring.gpg
  signing: assets/debootstrap.tar.bz2
  signing: assets/e2fsck.static
  signing: assets/gpgv
  signing: assets/lildebi-common
[snip]

Now we have a working, but elaborate, process for setting up a Hardware Security Module for signing APKs. Once the HSM is setup, using it should be quite straightforward. Next steps are to work out as many kinks in this process as possible so this will be the default way to sign APKs. That means things like figuring out how Java can be pre-configured to use OpenSC in the Debian package, as well as including all relevant fixes in the pcscd and opensc packages. Then the ultimate is to add support for using HSMs in Android’s generated build files like the build.xml for ant that is generated by android update project. Then people could just plug in the HSM and run ant release and have a signed APK!

Tweaking HTTPS for Better Security

Wed, 12 Feb 2014 19:14:59 -0400

The HTTPS protocol is based on TLS and SSL, which are standard ways to negotiate encrypted connections. There is a lot of complexity in the protocols and lots of config options, but luckily most of the config options can be ignored since the defaults are fine. But there are some things worth tweaking to ensure that as many connections as possible are using reliable encryption ciphers while providing forward secrecy. A connection with forward secrecy provides protection to past transactions even if the server’s HTTPS private key/certificate is stolen or compromised. This protects your users from large scale network observers that can store all traffic for later decryption, like governments, ISPs, telecoms, etc. From the server operator’s point of view, it means less risk of leaking users’ data, since even if the server is compromised, past network traffic will probably not be able to be encrypted.

In my situation, I was using our development site, https://dev.guardianproject.info, as my test bed, it is Apache 2.2 and openssl 1.0.1 running on Ubuntu/precise 12.04 Long-Term Support, so that means that some of the options are more limited since this is an older release. On Debian, Ubuntu and other Debian-derivatives, you’ll only need to edit /etc/apache2/mods-available/ssl.conf. There are more paranoid resources for perfectly configuring your TLS, but we’re not ready to drop support for old browsers that only support SSLv3, and not TLS at all. So I went with this line to enable SSLv3 and TLSv1.0 and newer:
 SSLProtocol all -SSLv2 

With TLS connections, the client and the server each present a list of encryption ciphers that represent the ciphers they each support in order of preference. This enables the client and server to choose a cipher that both support. Normally, the client’s list takes precedence over the server’s, but with many browsers that can be changed. Unfortunately it seems that Microsoft Internet Explorer (IE) ignores this and always uses the client’s preference first. Here’s how to make Apache request that the server preferences are preferred:
 SSLHonorCipherOrder on 

Next up is tweaking the server’s preference list to put ciphers that enable forward secrecy first (don’t worry if you don’t understand the next stuff about my rationale, my aim is to walk thru the process). This is done in most web servers using openssl-style cipher lists. I started out with what Mozilla recommends, then pared down the list to remove AES-256 ciphers, since AES-128 is widely regarded to be faster, quite strong, and perhaps more resistant to timing attacks than AES-256. I also chose to remove RC4-based ciphers, since RC4 might already be broken, and will only get worse with time. RC4 has historically been used to mitigate the “BEAST” attack, but that is mostly happening in the clients now. So with that I ended up with this cipher list (should be all one line in your config file):
 SSLCipherSuite "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:CAMELLIA128-SHA:DES-CBC3-SHA" 

One thing to make sure is that all of these ciphers are supported on your system. You can get the list of supported ciphers from openssl ciphers. I used this command line to get them in a nice, alphabetized list:
 openssl ciphers | sed 's,:,\n,g' | sort 

Lastly, we want to set the HSTS header to tell the browser to always use HTTPS. To enforce this, a header is added to the collection of HTTP headers delivered when connecting to the HTTPS site. This header tells the client browser to always connect to the current domain using HTTPS. It includes an expiration date (aka max-age) after which, the client browser will again allow HTTP connections to that domain. The server might then again redirect the HTTP connection to HTTPS, and again the client will get the HSTS header, and use only HTTPS until the expiration date comes again. To include this header in your Apache server, add this line:
 Header add Strict-Transport-Security "max-age=15768000;includeSubDomains" 

Now you can check the results of your work with Qualys’ handy SSL Test. You can see the result of my efforts here: https://www.ssllabs.com/ssltest/analyze.html?d=dev.guardianproject.info. A- is not bad. I tried for a good long while to get IE to use FS (Forward Secrecy) ciphers, but failed. IE does not respect the server-side cipher preferences. My guess is that the only way to get IE to use FS ciphers is to make a custom cipher list that does not include anything but FS ciphers and serve that only to IE. I know it is possible to do because bitbucket.com got an A+ for doing it. For a quick way to check out the cipher lists and HSTS header, look at iSEC Partner’s sslyze.

This is only a quick overview of the process to outline the general concepts. To find out more I recommend reading the source articles for this post, including specific directions for nginx and lighttpd:

Mozilla’s Server-side TLS
Qualys’ Configuring Apache, Nginx, and OpenSSL for Forward Secrecy
Qualys’ Is BEAST Still a Threat?
HTTP Strict Transport Security

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.

Getting keys into your keyring with Gnu Privacy Guard for Android

Fri, 06 Dec 2013 15:11:53 -0400

Now that you can have a full GnuPG on your Android device with Gnu Privacy Guard for Android, the next step is getting keys you need onto your device and included in Gnu Privacy Guard. We have tried to make it as easy as possible without compromising privacy, and have implemented a few approaches, while working on others. There are a few ways to get this done right now.

Gnu Privacy Guard registered itself with Android as a handler of all the standard OpenPGP MIME types (application/pgp-keys, application/pgp-encrypted, application/pgp-signature), as well as all of the OpenPGP and GnuPG file extensions (.pkr .skr .key .sig .asc .gpg .bin). This means that users just have to share a file to Gnu Privacy Guard using any of the standard Android methods, these files can be launched from an email attachment, opened from the SD card using a file browser, clicked in the Downloads view, etc.

So if you want to quickly send your whole public keyring from your laptop to your mobile device, you can just grab the database file directly from GnuPG and copy it to your SD card. Here is how:

plug your device into your laptop via USB so you can copy files to the SD card
find your GnuPG home folder (on GNU/Linux and Mac OS X, it will be in ~/.gnupg/pubring.gpg, on Windows it is %APPDATA%\gnupg)
In your GnuPG home folder, copy pubring.gpg to your device’s SD card
unmount and unplug your device
on your device, open your favorite file manager app (OI File Manager, Astro, etc)
go to the SD card
long-click on pubring.gpg and share it to Gnu Privacy Guard
click OK on the Import Keys dialog

After that, Gnu Privacy Guard will do the rest. Give is some time to sync to the Contacts database, then you’ll see all of your keys from your desktop are now in your People app and are listed in Gnu Privacy Guard itself. You can now encrypt files to any of those keys, or verify files signed by any of those keys. Here are a couple screenshots to illustrate key points in the process, using OI File Manager:

1. send your public keyring file

2. choose Gnu Privacy Guard to send the file to

3. click OK to import the key file

4. now you can see the imported keys in Gnu Privacy Guard

There are many ways to get the keyring files like pubring.gpg to your device: you can also share the keyring files via email, chat, or even services like Dropbox or Google Drive. Then once the files are on your device, you can import them using the same procedure as above. But keep in mind that you are sending your whole collection of secure contacts to that service, which will have full access to read it. If you have any worries about leaking your keyring to anyone, then a good method is to copy it directly to the SD card.

search the keyserver for the author’s key (the key from 1998 is lost, don’t use that one…)

You can also search and download keys via the public pool of OpenPGP keyservers. If you already know someone’s keyid or fingerprint, you can search using that. Otherwise, you can search based on name or email address. But be careful! Downloading a key from a keyserver does not give you a key you can trust. Anyone can upload a key to the keyservers, and they can make that key have any name or email address. Downloading from the keyservers is a convenient way to download a key, but you must verify the key’s fingerprint with the person you are trying to find.

scan this QR Code to get the author’s OpenPGP key

In conjunction with the

Monkeysphere project, we developed a standard URI scheme for sending OpenPGP key fingerprints. For example, you can find my key ID here: openpgp4fpr:9F0FE587374BBE81. This provides a clickable way to get an OpenPGP key. On an Android device with Gnu Privacy Guard installed, you can click on this link to download my key from the keyservers. This URI scheme also works well in QR Codes. Scan this QR Code on your device with an app like Barcode Scanner, and click Open Browser, and Gnu Privacy Guard will download my key to your device.

There are other ideas out there that we also want to support. For example, OpenPGP Keychain includes a way to transmit the whole public key via NFC. This allows people can swap keys directly from phone to phone without having internet access at all. But NFC is quite slow to transmit data so the devices need to be held together for a while until the whole key is received. NFC could be used to rapidly transmit an openpgp4fpr: URI, and then the whole public key would be fetched from a keyserver, but that then requires internet access and also leaks a bit of metadata to the internet. A better technique would be to transmit the entire public key over Bluetooth, using NFC to setup the Bluetooth session. We’re also looking at ways to do this via WiFi and Bonjour (mDNS) local service advertisements.

Your own private dropbox with free software

Tue, 12 Nov 2013 12:50:23 -0400

There are lots of file storage and sharing software packages out there that make it easy for a group of people to share files. Dropbox is perhaps the most well known of the group, it provides an easy way for a group of people to share files. The downside of Dropbox is that it is not a private service, just like any cloud-based service. Dropbox has total access to your files that you store there. That means its likely that the NSA and its collaborators do too.

Dropbox also knows where the computers are that are accessing their service because they can see the IP address of the incoming connections. To help with this, it is possible to use use Dropbox over Tor, thankfully they have provided proxy settings.

For our shared files, we use SparkleShare. It provides an experience very similar to Dropbox: you have a SparkleShare folder that is synced up with the service, and in turn any other users who are also linked up to it. Once its setup, it is as easy to use as Dropbox, but setting it up takes a bit more work than Dropbox. It builds upon two software packages well known for security and reliability: git and ssh, and works with Tor Hidden Services. It runs on Windows, Mac OS X, and GNU/Linux, and there is an Android client in the works.

You can use any git service as the server for SparkleShare, including github, bitbucket, gitorious, etc. But these have the same issues as putting your files on Dropbox: that service has complete access to your files. For extra protection, SparkleShare can encrypt the files on the client-side, have encrypted shared folders with SparkleShare, so that the server does not have access to the files. For the last piece of setting up a private SparkleShare, you need a computer that you can ssh to, and has git and Tor on it. This computer could even be an old Android device running Lil’ Debi, it only needs enough disk space for your SparkleShare files and a steady network connection. Running it on your own computer means it can use a Tor Hidden Service, and that all of the metadata related to who is editing what files remains private.

To start, setup a Tor Hidden Service to the sshd port. You can read all about that process in the Tor instructions, but basically, you need to add something like this to the torrc configuration file:

HiddenServiceDir /var/lib/tor/ssh_hidden_service/
HiddenServicePort 22 127.0.0.1:22

Then restart tor, and it will generate two files in /var/lib/tor/ssh_hidden_service/, open the file called hostname to see your new .onion address. We’re going to use fakefakefakefake.onion as our made-up one for this HOWTO. That is the address you will use in SparkleShare as the server address.

Next ssh needs to be setup to use Tor to access the .onion address of the Tor Hidden Service. To do that we need the wonderful Netcat tool (nc). On Debian/Ubuntu, run sudo apt-get install netcat-openbsd to get it, its included with Mac OS X by default. Now edit your SSH config file, its usually in ~/.ssh/config, and add this section:

Host *.onion
     Compression yes
     ProxyCommand nc -X 5 -x 127.0.0.1:9050 %h %p

For Windows, you need to use connect proxy, which is thankfully included in SparkleShare. You can optionally use connect instead of Netcat/nc on Mac OS X (fink install connect or brew install connect) and GNU/Linux (e.g. apt-get install connect-proxy or yum install connect-proxy). Instead of the snippet above, use this snippet in ~/.ssh/config to use connect:

Host *.onion
     Compression yes
     ProxyCommand connect -5 -S 127.0.0.1:9050 %h %p

Now its time to set up the git repo on the server that will be the conduit for sharing files between the different users. Basically, all you need to do is create a new folder, then make it a “bare” git repo (you can read all about it in the git book):

ssh git@fakefakefakefake.onion
mkdir /home/git/MyPrivateShare
cd /home/git/MyPrivateShare
git init --bare

For sshing to the git, we set up a single account called git, then to grant access, we add the SSH key (SparkleShare calls this the Client ID) to the git account’s ~/.ssh/authorized_keys file.

Now everything should be ready to start adding clients! In SparkleShare, go to Add Hosted Project…, choose On my own server, then enter your username and .onion address (ssh://git@fakefakefakefake.onion) in Address and the path to the git repo (/home/git/MyPrivateShare) in Remote Path:

Now the client will download the entire git repository from the server, and you’ll then have a working shared dropbox! If there are a lot of files in it, then the first sync can take a long time before any files show up. This is because git first downloads the entire history first, then it checks out the files. After that initial setup, then the new files show up quite quickly.

So this SparkleShare setup keeps your files on computers that you control, it prevents information and metadata from being leaked to the network while people are using this SparkleShare setup. When using Client Side Encryption, even less data is leaked. The server cannot access the content of the files at all since they are encrypted. The the server in this case would only be able to see the network traffic, and which ssh key was used to access the server. If everyone accessing this setup used the same user account (i.e. git) and ssh key, then the server would not even know which user is making the changes. This is about as private as you could hope for in a shared dropbox folder.

One last nice feature of this setup is that git server does not need a domain name, static IP or even a public IP, it just needs a working internet connection. As long as it can connect to Tor, then the Hidden Service will work. So if this private dropbox is for extra sensitive stuff, it could be stashed anywhere it can get power and wifi.

Issues when distributing software

Thu, 31 Oct 2013 15:51:19 -0400

There is currently a discussion underway on the Debian-security list about adding TLS and Tor functionality to the official repositories (repos) of Debian packages that is highlighting how we need to update how we think about the risks when distributing software. Mostly, we are used to thinking about making sure that the software that the user is installing is the same exact software that has been posted for distribution. This is generally handled by signing the software package, then verifying that signature on the user’s machine. This is how it works on Mac OS X, Windows, Debian, etc. etc.

But the authenticity of a software package is not the only issue that needs to be addressed, especially these days where many companies and governments around the world are trying to track everything that anyone is doing on the internet. In order to understand why Tor and TLS would be useful here, it good to break down the various concerns (or threats if you prefer):

package authenticity (software can be modified while being downloaded)
package availability (software security updates can be individually blocked)
repo availability (internet services can be blocked by governments and companies)
who’s downloading what package (currently visible to anyone who can see the network traffic, including open wifi, etc.)

Most people distributing software are used to thinking about #1 verifying packages when thinking about the security of software distribution. #2, #3, and #4 are also important, and currently not well addressed. This is where TLS and Tor come in. Both can help prevent Man-In-The-Middle manipulations as well as reduce the amount of information that is leaked to the network. Tor can also help with #3. Since Tor is difficult to block, it is often uses to circumvent censorship. In this case a software repo could be blocked entirely, and Tor could help with gaining access to it. The Update Framework has a good overview of the possible attacks against software repos.

So having software repos available with both TLS and Tor available as options is a very good idea. As far as I have seen, there are not any Debian repos available via a Tor Hidden Service. There are a number of official mirrors that already support TLS/HTTPS. You can find them using this script:

#!/usr/bin/python

import urllib2
import re
import ssl
import sys

# # find generic mirrors
mirrors = urllib2.urlopen('http://www.debian.org/mirror/list')
https = []
for line in mirrors.readlines():
    m = re.match('.*<td valign="top"><a rel="nofollow" href="http(.*)">.*', line)
    if m:
        url = 'https' + m.group(1)
        print 'trying: ',
        print url,
        print '...',
        sys.stdout.flush()
        try:
            response=urllib2.urlopen(url, timeout=1)
            https.append(url)
            print 'success!'
        except urllib2.URLError as err:
            print 'fail!'
        except ssl.SSLError as err:
            print 'bad SSL!'

# print 'HTTPS apt repos:'
#for url in https:
#    print url


# # find security mirrors
mirrors = urllib2.urlopen('http://www.debian.org/mirror/list-full')
securitys = []
for line in mirrors.readlines():
    m = re.match('.*</tt><br>Security updates over HTTP: <tt><a rel="nofollow" href="http(.*)">.*/debian-security/</a>.*', line)
    if m:
        url = 'https' + m.group(1)
        print 'trying: ',
        print url,
        print '...',
        sys.stdout.flush()
        try:
            response=urllib2.urlopen(url, timeout=1)
            securitys.append(url)
            print 'success!'
        except urllib2.URLError as err:
            print 'fail!'
        except ssl.SSLError as err:
            print 'bad SSL!'

# print 'HTTPS security repos:'
# for url in securitys:
#     print url


# now find the backports mirrors
mirrors = urllib2.urlopen('http://backports-master.debian.org/Mirrors/')
backports = []
for line in mirrors.readlines():
#<td><a href="http://be.mirror.eurid.eu/debian-backports/">/debian-backports/</a>
    m = re.match('.*<td><a href="http(.*)">.*/debian-backports/</a>.*', line)
    if m:
        url = 'https' + m.group(1)
        print 'trying: ',
        print url,
        print '...',
        sys.stdout.flush()
        try:
            response=urllib2.urlopen(url, timeout=1)
            backports.append(url)
            print 'success!'
        except urllib2.URLError as err:
            print 'fail!'
        except ssl.SSLError as err:
            print 'bad SSL!'

#print 'HTTPS backports repos:'
#for url in backports:
#    print url


# now find the CD image mirrors
mirrors = urllib2.urlopen('http://www.debian.org/CD/http-ftp/')
cds = []
for line in mirrors.readlines():
# <a rel="nofollow" href="http://mirror.easyspeedy.com/debian-cd/">HTTP</a></li>
    m = re.match('.*<a rel="nofollow" href="http(:.*)">HTTP</a></li>.*', line)
    if m:
        url = 'https' + m.group(1)
        print 'trying: ',
        print url,
        print '...',
        sys.stdout.flush()
        try:
            response=urllib2.urlopen(url, timeout=1)
            cds.append(url)
            print 'success!'
        except urllib2.URLError as err:
            print 'fail!'
        except ssl.SSLError as err:
            print 'bad SSL!'

print 'HTTPS CD image repos:'
for url in cds:
    print url


# now write everything to a file
f = open('/tmp/https-debian-archives.txt', 'w')

f.write('HTTPS apt repos\n')
f.write('---------------\n')
for url in https:
    f.write(url + '\n')

f.write('\n\nHTTPS security repos\n')
f.write('---------------\n')
for url in securitys:
    f.write(url + '\n')

f.write('\n\nHTTPS backports repos\n')
f.write('--------------------\n')
for url in backports:
    f.write(url + '\n')

f.write('\n\nHTTPS CD image repos\n')
f.write('--------------------\n')
for url in cds:
    f.write(url + '\n')


f.close()

Keeping data private means it must be truly deletable!

Fri, 23 Aug 2013 17:36:49 -0400

There are lots of apps these days that promise to keep your data secure, and even some that promise to wipe away private information mere seconds or minutes after it has been received. It is one thing to keep data out of view from people you don’t want seeing it, it is also important to be able to truly delete information. Unfortunately computers make it very difficult to make data truly disappear. When we tell a computer to delete a file, it only deletes the reference to the data. The data itself remains on the disk unchanged. For any UNIX geek out there, you can easily see an example of that by greping a partition (e.g. sudo grep password /dev/sda3. To solve this problem, there are “secure delete” options. Secure deletion removes the reference like regular deletion, then wipes the data on the disk by overwriting it with random data. That’s much better, but not always good enough. It turns out that its possible to remove the hard disk and read magnetic residue and recover even wiped data.

Mobile devices only make that problem worse because they almost always rely on flash memory for disk storage. Flash memory has wear-leveling programming built into it, so it is not possible to guarantee that a file will be wiped without overwriting the whole flash disk, then deleting it all and overwriting the whole thing again. Not only is it not practical to delete the whole disk just to remove one file, it also takes a long time.

So what can we do about this? Use encryption! [1] If the data is encrypted before its written to either a classic hard drive or flash memory disk, then the actual data is never on the disk itself. If the data is encrypted with a good passphrase, then just “forgetting” the key will make it basically impossible to recover the data. Additionally, encrypted data looks like random data, so it is easy to hide the deleted, encrypted data from the recovery techniques by adding random garbage to the disk. It turns out that with the right architecture, a key can be forgotten quite quickly, much quicker than even the most basic secure deletion.

This logic is built into our new passphrase library Cacheword. Cacheword is a library for securely working with and caching passphrases. It plugs right into SQLCipher for Android and IOCipher. SQLCipher and IOCipher are both ways for easily storing data using strong AES-256 encryption. Cacheword then handles getting the passphrase from the user. Instead of feeding that passphrase directly to SQLCipher or IOCipher, it creates an encrypted file for storing a strong AES-256 key and that is what is used to lock SQLCipher and IOCipher. The user’s passphrase then just unlocks that encrypted key file.

The means you can get rapid deletion of data stores of any size by just deleting the key file. The user never sees the actual key so they cannot divulge it. Since the user’s passphrase is not the key for the data but instead the key to the Cacheword key file, the secure deletion can first focus on that key file. The key file is small, so that can happen very quickly. Then even if the data files are recovered, the user does not has the passphrase to the data, its only locked away in the now deleted key file. The key was stored encrypted, so a standard deletion will provide decent protection: it will look like random data on the disk.

To really ensure the key and the data is gone for good, an app can implement a full wiping procedure. Normal wiping procedures can follow as a background task, making it harder and harder to recover the data, no matter who the adversary is. The full wiping procedure would go something like this (with a rough timeframe for each step):

Cacheword wipes the passphrase from memory (nanoseconds to milliseconds)
the Cacheword key file is deleted (milliseconds)
write random garbage to disk patterned after the key file to obscure the deleted key file (milliseconds to minutes)
delete the SQLCipher/IOCipher data files (seconds to minutes)
fill entire memory (RAM) with random garbage (minutes to hours)
fill entire disk with random garbage (hours)
power off device

That’s the overview of the process. But of course, there are always annoying technical details, and I’ll continue on about some of them, for those who like such things.

To start with, the user’s passphrase will most likely be stored in memory by code outside of Cacheword, SQLCipher, and IOCipher. For example, the Android text entry widget will have the passphrase pass thru it, and inevitably will store that data in memory. It is up to the garbage collection to remove that from memory, and the garbage collection might not zero out the memory before deallocating it. We’re still looking into ideas for how to trigger that, and would love to hear suggestions.

To truly wipe the data from the disk, there would need to be multiple passes where the entire disk is filled up then the entire disk is deleted. That is rarely practical. So hiding the existence of the encrypted data stores is difficult to do in practice. The encrypted data will remain encrypted with AES-256 using a random, full length key, so it would be basically impossible to crack using publicly known technology and techniques.

The best bet for preventing the most advanced adversary from getting the deleted data would involve a few cycles of rebooting, filling up the memory and disk with random garbage after doing the procedure outlined above. A more rapid version of that would be to delay filling the disk until after a reboot. That would ensure that the key to the data is thoroughly wiped as quickly as possible before starting in on the much less important and long lasting task of wiping the entire disk to hide the deleted data files.

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.

GnuPG for Android progress: we have an command line app!

Thu, 09 May 2013 10:48:52 -0400

This alpha release of our command-line developer tool brings GnuPG to Android for the first time!

GNU Privacy Guard Command-Line (gpgcli) gives you command line access to the entire GnuPG suite of encryption software. GPG is GNU’s tool for end-to-end secure communication and encrypted data storage. This trusted protocol is the free software alternative to PGP. GnuPG 2.1 is the new modularized version of GnuPG that now supports OpenPGP and S/MIME.

You can get it from the Play Store:
https://play.google.com/store/apps/details?id=info.guardianproject.gpg

Or download the .apk from our nightly builds:
https://guardianproject.info/builds/GnuPrivacyGuard/

Setup

Before using gpgcli, be sure to launch the app and let it finish its installation process. Once it has completed, then you’re ready to use it. The easiest way to get started with gpgcli is to install Android Terminal Emulator. gpgcli will automatically configure Android Terminal Emulator as long as you have the _Allow PATH extensions</em settings enabled.

Features

TRUSTED SECURITY: This technology already seamlessly integrates into Linux on Debian, Ubuntu, Fedora, Mac OSX (GPGtools), Windows (gpg4win)
PUBLIC KEY ENCRYPTION: Full interoperable replacement of the proprietary Pretty Good Privacy (PGP) standard that uses a serial combination of hashing, data compression, symmetric-key cryptography and finally public-key cryptography; each step uses one of several supported algorithms.
BROAD ALGORITHM LANDSCAPE: Supports 3DES, AES, Blowfish, CAST5, DSA, ElGamal, MD5, RSA, RIPDE-MD-160, SHA-1, TIGER, and Twofish.
VERIFIABLE INTEGRITY AND AUTHENTICITY: Digital signatures create a trusted trail of ownership.
CONFIRMED SECURITY: Italian Police, the FBI, and British police have been unable to crack its security and have resorted to demanding private keys. It’s been likened as “the closest you’re likely to get to military-grade encryption” by cryptographer Bruce Schneier.
HELP SYSTEM: A quick help tool is built in.
KEYSERVER SUPPORT: Integrated support for HKP and LDAP keyservers (keys.gnupg.net).
OPEN STANDARD COMPLIANT: Full OpenPGP implementation. Learn more about standards RFC2440 & RFC4880

Please Report Bugs

This is an early release of a big project, so there will inevitable be bugs. Help us improve this software by filing bug reports about any problem that you encounter. Feature requests are also welcome!

https://dev.guardianproject.info/projects/gpgandroid/issues

Coming Soon

SECURITY FOR APPS: We have an API in the works so that developers can
easily embed this into any app to give it state of the art security features.
GUI: We’re building a graphical user interface for easy key management.
STAY UP TO DATE: Sign up for our low-traffic Guardian-Dev mailing list to
be notified when the API and GUI are released:
https://lists.mayfirst.org/mailman/listinfo/guardian-dev
Find us in IRC, we want feedback!
- #guardianproject on freenode
- #guardianproject on oftc
.

IOCipher beta: easy encrypted file storage for your Android app

Thu, 07 Feb 2013 14:45:28 -0400

At long last, we are proud to announce the first beta release of IOCipher, an easy framework for providing virtual encrypted disks for Android apps.

does not require root or any special permissions at all
the API is a drop-in replacement for the standard java.io.File API, so if you have ever worked with files in Java, you already know how to use IOCipher
works easiest in an app that stores all files in IOCipher, but using standard java.io with IOCipher is possible
supports android-7 v2.1 and above
licensed under the LGPL v3+

You can download it here:

https://guardianproject.info/code/iocipher/

Adding IOCipher to our InformaCam and NoteCipher apps is already in the
works. There is already one app in the Play Store built with IOCipher: Gryphn Secure Messaging

We’ve recently done some heavy testing and bug fixing and this is ready for beta status. That means for many applications, it should be stable with reasonable performance. But its not done yet, and there are some known edge cases documented in our bug tracker which we aim to address in the next beta release:

https://dev.guardianproject.info/projects/iocipher/issues

Some additional notes on usage:

single thread/sequential access is the preferred way of using IOCipher
multi-threaded access possible, but potentially unstable under very high load
VFS now has beginTransaction and completeTransaction to optimize performance
parts of java.io not currently supported: vectored I/O, memory-mapped files

featured photo “Safe” from Pong on Flickr

report on IOCipher beta dev sprint

Thu, 31 Jan 2013 19:45:44 -0400

We are just wrapping up an intensive dev sprint on IOCipher in order to get the first real beta release out, and it has been a wonderfully productive session on many levels! Before we started this, we had a proof-of-concept project that was crashy and ridiculously slow. We’re talking crashes every 100 or so transactions and 9 minutes to write 2 megs. Abel and I were plodding thru the bugs, trying to find the motivation to dive into the hard problems in the guts of some of the more arcane parts of the code. Aaron Huttner of Gryphn found IOCipher while developing their Gryphn Secure Text Messaging and thought it was a remarkable easy way to add encrypted storage of files, and it worked quickly for him, so he included it his app before we had even announced an alpha release (thanks again for the vote of confidence!).

Aaron worked through a lot of the bugs with us, providing good bug reports and real, working test cases in code. What more could we ask for? We made progress on them slowly but surely. Gryphn then decided they needed IOCipher to work for them ASAP so they could put out a real release. They approached us about funding a development sprint and we thought it was a great idea. This also allowed us to bring in Stephen Lombardo and Nick Parker of Zetetic to apply their SQLCipher and SQLite expertise. Our very own David Oliver put together the deal, and off we went. So we put our heads down and focused everything on getting IOCipher to be a real file system.

To begin with, we focused on the core of IOCipher, libsqlfs, since we could run that on GNU/Linux, greatly speeding up the testing cycle. It started out with about 3 full days of Abel and I running fsx (File System eXersizer) tests of all shapes and sizes on libsqlfs mounts to try to pin down the crashes. It seemed like we were swimming in mountains of test results that vaguely pointed somewhere. We had some vague leads, but were excited to find that memory-mapped writes were far and away the most common crash. Since IOCipher does not use mapped writes at all, we could safely ignore those crashes for now. Turns out that using libsqlfs as a FUSE mount for our test platform has produced this one red herring.

One thing we knew all along is that both reads and writes were really slow, so Zetetic started with that. We all had the idea that the block sizes should all be aligned, and that should likely speed things up. This means Java stream readers and writers, writes in our Posix-style JNI layer, and the page size of the SQLite database. Zetetic did some testing and found that using 8k block sizes throughout produces some dramatic speed increases, here are some ballpark figures for doing a 2MB write with no contention:

~710 seconds: default 256 byte blocks and no buffering, one SQLite transaction per block
~65 seconds: wrapping all the 8192 write calls for each 256 byte block in a single SQLite transaction
~20 seconds: same as above with the IOCipher FileOutputStream wrapped in a BufferedOutputStream
~5 seconds: increase internal IOCipher block size to 4k
~10 seconds: 8k sqlfs block size, 8k sqlite page size, and 8k BufferedOutputStream buffer, one SQLite transaction per block
~1 second: same as above, all blocks written in a single SQLite transaction

Ok, now we had something you could actually use. Pretty slow still, but no longer ridiculous. Through much reading of code and testing, we figured out that there is one spot of the code that assumed it would always be able to read from the database. Under heavy load, this was not possible, especially when you have 9 minute blocking write operations. So the next step was to figure out all of the locking and make sure that was working right. The libsqlfs code from 2006 had the remnants of three separate locking mechanisms in it, SQLite locking, pthread locking, and a delay-retry timeout mechanism. Zetetic dove into updating libsqlfs to replace all that and use all of the modern SQLite tricks like sqlite3_busy_timeout() to replace the delay-retry logic, v3.0 locks and v3.7 Write-Ahead-Logging which gave libsqlfs a huge improvement in read/write concurrency, and putting libsqlfs and IOCipher reasonable performance in the realm of other encrypted file systems. I’ll let Stephen explain it:

First, we changed the transaction command in begin_transaction to use “begin immediate”. This seeks an immediate reserved lock on the database, but does not exclusively lock it. This reduces unresolvable contention for write locks that would normally occur with deferred transactions, and is less restrictive than an exclusive lock, since it will continue to allow shared locks for reading.

It is extremely important that we prevent write operations from failing to execute due to busy timeouts, even if another process/thread has the database locked. Even using WAL, it is still possible for a command to be blocked during attempted concurrent write operations. This causes the write operation to fail leading to corruption. While libsqlfs has some “delay()” code that provides rudimentary busy handling, it is only in use for a small number of operations leaving other critical calls unprotected. Therefore, our second change was to register SQLite’s internal busy handler with a relatively high timeout (currently 10 seconds, but open for discussion) via sqlite3_busy_timeout. This provides protection for all operations in libsqlfs, reducing the likelihood that a write operation would fail outright, though it may be delayed.

Finally, we enabled WAL mode to speed up write operations and further improve concurrency between readers and writers. Note that WAL mode only fsync()s on checkpoint operations, so it may be possible to enable NORMAL synchronous mode with lower overhead than the standard journal mode (we didn’t change this yet).

With these changes in place, three concurrent fsx processes running in parallel on a single fuse mount produced no errors in a 24hr test run. The tests also shows improved performance on read and writes. In light of these results, we’d like to get your feedback on these changes, and request that you run your own tests in the multi-threaded Android application to see if they resolve the problems that were reported.

This was the final kicker. Who would of thought we could again get performance improvements of an order of magnitude twice in a single dev sprint. Now we have a encrypted filesystem that is stable and with reasonable performance that is really easy to use. And since that means that there is only very short chunks of time where everything is blocked (no more 9 minute writes), the crashes have basically vanished under real world loads. We have run super heavy file system tests over hundreds of thousands of operations without data corruption or crashes. We know that there is the theoretical potential for crashes in certain operations under super heavy load. We aim to address that in upcoming releases. And in conclusion, I’ll quote Aaron since he summarized what we are trying to achieve when we make developer tools:

Between SQLCipher-for-Android and IOCipher I don’t think it could get any easier to implement cryptography on Android, hopefully people pick up on this.

So grab the code now from git, if you’re ready to dive in! Or for the more patient, we’re developing tutorials to go along with the beta release that is coming any day now.

Sometimes the best solution is a library, not an app

Mon, 27 Aug 2012 12:30:15 -0400

Our general approach to software development starts with surveying existing solutions that are available and in use, to see if there is already enough of an ecosystem or whether we need to seed that. When there is already an adundance of tools and apps out there, we work to find the good ones, provide feedback and auditing, and then build apps and tools to fill in any gaps. For example, this was our approach in the Open Secure Telephony Network.

When there is not an ecosystem around a given problem, then we aim to make it as easy as possible for people writing software to address the issues. In this case, we focus on making developer tools. For example, most of the data on our phones is easily accessible to someone who has physical access to the device, be it the secret police or a thief. IOCipher and SQLCipher-for-Android both provide tools to easily encrypt data, using APIs that are very familiar to anyone doing Android development. We specifically aim to take complex technical challenges and bundle them up into packages that allow developers to add functionality in a matter of hours or days rather than weeks or months.

With the developer tools that Guardian Project is creating, the impact is not as overt as in other software development since they are largely invisible to the users if we have done our jobs right.

In order for our developer projects to have a good impact, there are many different aspects that need to be covered. After assessing the current available tools to determine the general approach, the technical approach is chosen. This will influence the development time, the efficiency, and ease of use. As soon as the project is developed to a basic usable state, it is time to get feedback from willing testers to validate the techical approach. After more development and feedback, next comes documentation and beta releases. Once the project gets to a point where the releases and documentation are good enough for most people to figure out what they need, then we start evangelizing the tool and lobby the developers of existing software to adopt the new tool. As part of that, we also offer meetups and workshops for people to see demos, discuss ideas with us, get started, and learn best practices.

Some Current Projects

We already have a couple well known developer tools out there, like SQLCipher-for-Android and Orlib. We have many more in development. Here’s a quick overview:

Orlib is an Android library to make it very easy to include Orbot/Tor support in any app. Any app that uses orlib can transparently route all traffic through the Tor network without requiring that the device be rooted. It is a well established project that mostly needs more documentation, developer support, and evangelizing.
SQLCipher is a custom version of the SQLite database that provides easy-to-use, flexible and robust encryption. Guardian Project created SQLCipher-for-Android, which mirrors the standard Android database API, so developers already know how to use it, and need only add support for handling the passwords.
libsqlfs provides a complete virtual disk on top of a SQLCipher database. The virtual disk is encrypted and contained in a single file, which can be easily moved around, copied, shared, etc. It is a standard FUSE filesytem that can work on Android, GNU/Linux, and Mac OS X. libsqlfs is a pre-existing tool that was abandoned by its authors and has been adopted by the Guardian Project.
IOCipher is a cousin to SQLCipher-for-Android: it provides virtual encrypted disks for Android apps without requiring the device to be rooted. It uses the standard Java API for working with files, so developers already know how to use it, and only need to handle the passwords and opening and closing the virtual disks. It is based on libsqlfs and SQLCipher.
Gnu Privacy Guard (GnuPG) for Android brings the widespread standard in OpenPGP encryption to Android. GnuPG provides solid encryption for keeping emails and files private, and for verifying that emails and files are who you think they are. GnuPG is built-in to basically every GNU/Linux distro, in GPGTools for Mac OS X and Apple Mail, a plugin for Outlook and Thunderbird, etc. We are working to bring GnuPG to Android to make it the cornerstone of Android encryption like it is elsewhere.
ffmpeg is a popular, widespread framework for transcoding and filtering digital videos. It has been essential to our apps ObscuraCam, InformaCam, and Murrow/StoryMaker. We want to now work to make it dead simple for developers to build their own apps on it. We are also extending it to provide a full framework for audio and image redaction, metadata management, and encryption of sensitive parts of the media. This will make it easy for media app developers to build in privacy to their own apps.
Portable Shared Security Tokens (PSST) is our project to tackle the issues of digital identity and crypto key management. This is perhaps the most vexing issue facing deployment of secure mobile devices today. Public-key cryptography (HTTPS/SSL, OTR chat, PGP email, etc.) is a proven, powerful way to validate digital identity while keeping the contents private. Their cryptographic keys essentially become their proof of identity, and as such that identity must be portable across computing contexts (mobile devices, desktop environments, etc.). An interoperable standard and associated developer libraries needs to be developed to make possible a portable and secure solution for establishing one’s identity.
Always Secure Messaging (“AweSoMe”) is a collaborative effort to build interoperable, open-source, secure messaging applications, that work from mobile to mobile, as well as mobile to web. In particular, the goal is to create an extremely usable and high quality experience, that simultaneously supports one-to-one and one-to-many (group) end-to-end secure messaging communications across multiple platforms.
Bazaar provides the last piece of this puzzle: easy, secure and private distribution of software. Debian GNU/Linux has proven that decentralized software stores can work well. Google Play and the Apple App Store both provide excellent examples for how to make it easy to find and distribute apps, but are often blocked or not available in many parts of the world. Bazaar combines all of these ideas to provide a decentralized, peer-to-peer app store that makes it easy to find and distribute apps.

Threats and Usability of Secure Voice

Tue, 10 Jul 2012 12:48:18 -0400

In my previous post I found that end-to-end encryption with OSTN is both effective and usable. There are two important things the user must be aware of when using OSTN. They must confirm with each phone call that the encryption icon is present and they must correctly complete SAS verification dialog boxes. So on a basic level, encrypted voice just works. But, what does this all mean? This post looks at the threats to security and usability of encrypted ZRTP phone calls in CSipSimple.

Usable Security
Crypto wizards have created and refined algorithms that bring strong encryption to the everyday user. Yet, more often then not, security is compromised through user error. This is a usability problem. Information security is abstract and the practicalities of the real world demand that encryption software ‘just works’ for the average user. It is more dangerous for a user to be unaware of a loss of encryption then that they fail to get it working. Government P25 handheld radios were found to have such poor usability for encryption that a research team found many government agents accidentally transmitting sensitive information in the clear. ZRTP and CSipSimple’s implementation fair much better however.

Whitfield Diffie is pioneer of modern cryptography

Whit and Gandalf fight evil with magic abilities gained by pouring through dusty tomes full of obscure symbols. (Borrowed from this excellent Math Rules Cyberspace presentation)

Although not required for the average user, its good to have a basic background of cryptography. This is not an full introduction, but it will provide some background on ZRTP and the importance of authentication.

ZRTP, Authentication, PKI
Most usability issues with encrypted communications deals with Public-Key-Infrastructure or PKI. Public Key Infrastructure is how we verify the identity of each participant in a communication channel. Verifying the identity of the other party is important to prevent Man-In-The-Middle-Attacks. These attacks allow an attacker the opportunity to eavesdrop. PKI is a crucial point to understand in almost all encryption schemes. It inherently effects how the encrypted communication medium will be used.

Basically, to use encryption, both users must exchange secret keys without transmitting them in the clear. This is a bootstrapping problem, exchanging keys safely requires both users to already have exchanged keys! Public key cryptography has solved the problem of needing to secretly exchange keys in advance. Rather, a user can exchange public keys that don’t require secrecy. These keys can be published to the world. The issue is then whether or not the public key is authentic. How does one user know that they received the right public key and not the public key of an attacker attempting a MITM attack?

Different communities have different approaches to PKI. Smaller distributed technical communities have long relied on the web-of-trust model supported by PGP. This was the first widely available open-source software that provided strong cryptography to everyone. It was created by Phil Zimmerman who also created ZRTP to encrypt voice. Its work flow, while fine for some, has precluded its widespread adoption outside of the tech community.

Websites rely on a Certificate Authorities to make encryption transparent for the user. It does not require the user to make manual trust decisions and ‘just works’. However, it never obtained the goal of strong end-to-end encryption the way PGP has because it relies on the trust of centralized authorities that have proven time and time again to not be trustworthy. The future of SSL is a heavily researched area. For some approaches to this issue I’d personally suggest looking into DNSSEC, Convergence, and this talk from Dan J. Bernstein, a cryptographer and professor at the University of Illinois. This talk by Moxie Marlinspike at Blackhat 2011 is great, it introduces Convergence and provides an interesting dialogue on the SSL issue.

Modern cryptographic protocols such as OTR(instant messaging) and ZRTP(voice) have come a long way in providing easy to use end-to-end encryption. They are open standards that strike a great balance between usability and security. They both have adopted to the TOFU POP model (Trust on First Use- Persistence of Pseudonym). This is similar to what SSH does: when you first connect to the server you are asked if you want to save and trust the server’s public key. ZRTP takes it a step farther and verifies the other party’s identity on first use. A commitment protocol is used that requires the users to discuss whether they both are viewing the same string of text in a dialog box. This guarantees that the person you hear on the other end of the phone is the actual person your talking to.

This is great because by saving the public key and trusting it an attacker can no longer pretend to represent someone else’s key. This relies on the first conversation not being actively attacked. The commitment protocol strengthens this by making sure that the first time you trust a key, you actually have a way to verify it. This solves the issue of MITM attacks!

If all this doesn’t make sense, that is OK, you don’t actually have to understand cryptography to use OSTN. You just need to understand what it provides you (Confidentiality!). More information about authentication and verification was written in a great post by Hans. Guardian also has a great research project called PSST that is actively solving verification problems like this across multiple platforms and communication schemes.

Below are the threats to the current ZRTP implementation in CSipSimple from both the user’s perspective and attacker’s perspective.

User Threats
ZRTP is great in this regard. It is one of the most user friendly ways to enable verified end-to-end encryption. This said, there are two concepts that a user should understand:

Verification: The first time you call someone with ZRTP a dialog box is displayed that asks both users to confirm that they see the same SAS (Short Authentication String). Once confirmed this identity will persist within your OSTN account and when you call the same person this dialog will not appear. If your conversation is not verified it is possible that the call is susceptible to a certain kind of attack (MITM) that allows someone to listen to your phone call. As seen in the pictures above it is easy to tell if your phone call is encrypted but not if it is verified. It is up to the user to make sure they pay attention to the SAS dialog at the beginning of a conversation. Key’s are remembered after first verification so lack of a SAS box indicates the user’s have both hit OK on a previous SAS box.
Opportunistic Encryption: This means that encryption is only attempted, but not forced. If you have encryption on, but you happen to talk to a friend who has managed to turn it off, then your call will silently remain unencrypted. Since encryption can not be forced, a user must not expect to be encrypted but rather check their phone at the beginning of every call to be sure. This is how opportunistic encryption should work, but it would be easy for a user to assume otherwise. Don’t do it!

Adversarial Threats
Currently, I see two opportunities for attackers that are related to the same two usability concerns listed above.

MITM: I mentioned before that unverified conversations are susceptible to eavesdropping. This is solved by verifying each conversation by sharing a 4 letter code before starting a conversation. You must actually cancel or ignore the SAS dialog for this to happen. Don’t!
Force clear-voice communication: Opportunistic encryption presents a more interesting problem. It is possible for someone to selectively block a ZRTP negotiation packets. This would force two users to start a conversation in clear-voice despite both setting their accounts to use ZRTP. It would be obvious to the user if they check for the lock icon, but friends who frequently communicate with OSTN might forget to check each time. This could be prevented by having a setting to force encryption. In this case the call would simply fail. In Wireshark, I was clearly able to distinguish the ZRTP negotiation packets. An attacker who can filter your traffic on the application layer can perform this attack. ISPs, Governments, and adversaries on your LAN may reasonably be in a position to do this.

The MITM attack can be mitigated with verification. The selective blocking of ZRTP packets can not be avoided (because ZRTP can’t stop censorship) but the consequences can be mitigated by paying attention to when your calls are encrypted.

**Improving ZRTP usability
**
Given the threats listed above, I see a couple things that would increase usability and prevent accidental misunderstandings by the user.

Forced ZRTP Encryption: ZRTP in CSipSimple has two modes: off or opportunistic. I would propose changing these options to ZRTP Off, Attempt ZRTP, and Force ZRTP. Force ZRTP would provide a huge security benefit to accounts in CSipSimple that you would always expect to use encryption with.OSTN would of course be the ideal example here.

Current ZRTP options in CSipSimple

Verification Status: Currently you can tell when your conversation is ZRTP encrypted by the lock icon. This is great because this allows the user to avoid problems with opportunistic encryption or a downgrade attack. It would make sense to allow the user to see whether their call has also been authenticated correctly. Feedback might encourage users to continue to correctly use the SAS function.

This means your OSTN call is encrypted. It would be useful if it displayed the verification status of the caller as well.

Verification Options: Currently when verifying an identity the user is displayed with the SAS. They have the option to press ‘OK’ or ‘Cancel’. Cancel effectively ignores this step, OK means that the SAS has been verified. This is non-intuitive. I would propose simply having three options: Verify, Ignore, Reject. The current function of OK is mapped to Verify, Cancel is mapped to Ignore, and Reject ends the phone conversation in situations in which the SAS doesn’t match.

Suggested improvement would present “Verify, Ignore, and Reject” as options to the user

Wrapping up
It should be noted that I pick on CSipSimple over the other clients because it is both great software and the recommended client to use with OSTN. It is still considered experimental software and requires the nightly release for OSTN support. Other clients may suffer from these ZRTP usability issues as well. The good thing is that by simply implementing a working ZRTP client you should have most of the protocol benefits thanks to its simple and elegant design. The recommendations I make here should applicable across all ZRTP implementations. A future comparison of of these implementations may be in order.

A Network Analysis of Encrypted Voice over OSTN

Thu, 05 Jul 2012 14:23:50 -0400

Introduction to OSTN

The OSTN network stands for Open Source Telephony Network. It is a federated network standard for supporting Internet calling with end-to-end encryption ala ZRTP. Its very similar to e-mail in that VOIP calls can be routed to addresses such as user@domain.tld. Its a simple concept, but I believe it to be ground breaking implementation! Never before have I seen such an accessible solution to encrypted VOIP calls. OSTN is platform independent, is a federated network, and it is an open standard such that it is widely adoptable. There are two main components that are required to use OSTN with encryption: a VOIP client that supports ZRTP for end-to-end encryption and user account with an OSTN provider.

OSTEL is the first working OSTN provider. Sign up for an account at ostel.me.
CSipSimple is the recommended VOIP client for use with OSTN. It has a built in profile for OSTN accounts and supports ZRTP. You must use the nightly build! This is the latest version and requires that you allow outside applications on Android by checking the Settings>Applications>’Unknown sources’ box. Information on setting it up for your Android device can be found on our wiki.

While this post focuses on using OSTN with the recommended CSipSimple software, the concepts extend to all OSTN platforms. Check out the project page for more info on alternative clients.

Looking at Encrypted VOIP with Wireshark

Traffic dumps of an OSTN call and a ZRTP encrypted OSTN call were logged and analyzed in Wireshark for comparison. This is how someone between you and your caller would see your VOIP traffic. I was looking for three things in this audit

Confirm encryption was working in conjunction with what a user would logically expect
Demonstrate how easy it is to capture and view non-encrypted VOIP
Identify threats what types of security ZRTP provides

I can confirm that the encryption works as expected. The traffic logs of both phone calls can be found at the end of this post. First, here is a look at a normal non-encrypted phone call over OSTN with CSipSimple and secure call.

Cleartext phone calls are noted by absence of ZRTP overlay.

ZRTP Enabled phone calls are indicated by lock icon

It is quite clear to the user that ZTRP has been enabled by the lock icon that appears in both phones. Traffic logging has also confirmed that when you see the lock icon, ZRTP has successfully been set up and is being used. So far, so good. Make sure you see the lock sign if you are expecting to be talking on a secure conversation.

CSipSimple uses opportunistic ZRTP encryption that is enabled by default for OSTN accounts with CSipSimple. This means that all calls will begin without encryption and then send ‘ZRTP Hello’ packets to let each host know that a ZRTP conversation can begin. From here ZRTP negotiates a secure connection and then transfers the conversation to encrypted voice. Here are two pictures from Wireshark showing the very beginning of a (ZRTP enabled) OSTN phone call and where the encryption actually switches on. The SRTP protocol indicates that you are using encrypted voice. ZRTP simply defines the negotiation process for SRTP. This is not a minor thing however, it is because of this that ZRTP can provide end-to-end encryption. End-to-end encryption prevents a third-party from eavesdropping and possibly passing information on to higher authorities.

First UDP packets of an ZRTP enabled phone call. ZTRP Hello is sent out at the same time as the first RTP packet.

Successful ZRTP hand-off. Connection switches from normal RTP to encrypted RTP here.

The important part to notice here is that the hand-off is fast. Comparing the times of the first RTP packet to the first encrypted packet takes about 1.5 seconds. Multiple traffic logs confirmed that this is a consistent number. This means that if you immediately start talking during the start of an encrypted phone it is possible for some of your voice to be transmitted clear-text. I attempted to record this section by talking in the very beginning of a call and extracting voice. I wasn’t successful, but I wouldn’t discount that you will release some clear voice audio at the beginning of a conversation.

What ZRTP Guarantees

So, things look good with OSTN calls. ZRTP is enabled by default on all OSTN accounts with CSipSimple and it uses opportunistic encryption. Also, it is very easy for the user to tell that their call has been successfully encrypted. Great! What does this mean for the user? When correctly using ZRTP, a user can expect that their phone calls are fully confidential. No third party can intercept, listen, or mangle your phone call. This includes your OSTN provider of course.

What ZRTP Doesn’t Guarantee

ZRTP does not stop censorship or provide anonymity. This is something Orbot might be able to help with one day. Currently, the latency of the Tor network prevents real-time protocols from working. The current best solution would be to use a VPN provider to tunnel ZRTP traffic. However, now that VOIP is illegal in many countries it is not recommended that anyone trust this solution until a tested and verified method is published.

Conclusion

Using end-to-end voice encryption has never been this easy! This analysis confirmed that OSTN works quite well in practice. There are two things the user should do to ensure secure communication: make sure to read and confirm the verification dialog boxes and check to make sure your calls have the lock icon when you are counting on them to be encrypted. Just like that, you too can be a cypherpunk (or just someone with a reasonable expectation of privacy!). Like Phil Zimmerman, the creator of ZRTP, has said: “[OSTN] lets you whisper in someone’s ear a thousand miles away” Check back for our upcoming post which will look in more detail at the threat model of an OSTN phone call.

You can download the traffic log of a encrypted and unencrypted OSTN call here

IOCipher lives! encrypted virtual file system for Android

Thu, 17 May 2012 16:44:35 -0400

Nathan and I just got the first complete test of IOCipher working in the IOCipherServer/SpotSync app. We created a filesystem sqlite.db file, then mounted it and got all the files via HTTP. In the test suite, I have lots of operations all running fine and encrypting! The core idea here is a java.io API replacement that transparently writes to an encrypted store. So for the most part, just change your import statements from:

java.io.*   --->   info.guardianproject.iocipher.*

Then in your code, make a VirtualFileSystem instance and mount it, and unmount it. That’s about it. Right now, you can have only a single filesystem per app, but you can unmount one and mount another. We hope to add support for multiple filesystems in the not-too-distant future.

Its ready for people to try, some kind of early alpha. Here’s the framework itself:
https://github.com/guardianproject/IOCipher

THe easiest way to get started right now is probably the test suite:
https://github.com/guardianproject/IOCipherTests

Our first app using it is here:
https://github.com/guardianproject/IOCipherServer

Comments, feedback, criticism, welcome and wanted!

Singing and Dancing for Encryption

Thu, 19 Apr 2012 09:30:48 -0400

If you see me dancing or signing with my phone in my hand, I may not just be having a great time, but also creating an encryption key. Part of the issue with security is that it can often be difficult to implement or an added step in what users want to be an easy and seamless process. What if we can make secure and private communications fun and easy?

This past weekend, a bunch of members of the Guardian Project team found ourselves at the Wall Street Journal Data Transparency Hackathon. The Journal put this together in order to “invite developers to help build free Web tools that promote data transparency and control.” The tracks were divided into:

Scanning: Enhancing technology that scans the Web to reveal tracking
Education: Helping people see how much information they share
Control: Improving software that helps people control sensitive information

Tracks were led by Ashkan Soltani, an independent researcher and technical adviser to the Journal; Brian Kennish, a Web developer and founder of Disconnect; and Jacob Appelbaum, a security researcher at the Tor Project. Our teams went down the path of control, with the goal of making tools that are secure by default.

We danced our way into winning in the control category by helping the victorious Cryptocat team that has a tool for encrypted chat service right from the browser. This fantastic project blew through a number of innovations, porting into a Firefox web app, doing desktop notifications, and improved cryptographic primitives from within the browser. We helped by creating an Android app for the tool that converts dance moves into a random number generator for creating the encryption key. Just start the program, enter the name of the chat, enter your nickname, then DANCE. Starting a secure chat from a phone is now as easy as that. You can try it in your browser via their site https://crypto.cat/ or download our new Android app (either with or without Tor compatibility). And congrats to Nadim Kobeissi for this well deserved win and the team Tobias Pulls, Jacob Appelbaum, David Huerta, Joseph Bonneau and Nathan Freitas.

The Guardian Team & Friends Hacking Away

We sang our way into winning in a new category that the judges came up with, “soup cans and string” for Ostel, our encrypted VOIP solution. Launching an alpha version of our tool in front of some of the worlds leading experts in the security field was a risky move, but thankfully we managed to work out a number of bugs and generally received great feedback and support from the community. Over the weekend, we made progress in our alpha demo, identified additional clients that can receive calls on Mac, PC, Linux, iPhone, & Blackberry and created a new user signup system that allows users to register and immediately be sent an email with a link to their credentials via SSL. To extend the project even further, we have started compiling information on VOIP laws in countries from every continent so that the tool can explicitly be supported on as many platforms, in as many countries and in as many languages as possible. In addition to singing praise, singing (and other voice signatures) might be used in the future for entropy as the random number generator for the encryption key exchange. PrivateGSM is already doing this and it would be great to incorporate this feature into Ostel & CSipSimple later on. Thanks to Lee Azzarello, Luke Stark, Sean McIntyre and Zach Schwartz for being great members of the Ostel team.

Lee accepts the "Soupcan & Strings Award" for Ostel

Dancing for encryption in Cryptocat, singing for encryption in Ostel. Let us know if you have other ideas for fun ways to generate keys. We’re always looking for inspiring ideas from the community.

We’re even well on our way to seeing the world through encryption tinted glasses. Progress was made on making innovations in our Informacam project. The goal is to be able to snap a picture, but protect the privacy of the people in the frame by blurring their faces and the metadata connected to the event. Whie this can be crucial in a sensitive scenario, it can also be important that a judge or trusted organization can “unblur” the image and so we’re working on a way to encrypt and send those pixels. Bugs were removed, code was written, and soon enough, hopefully we’ll be able to incorporate it into the new Google Augmented reality goggles.


Using the InformaCam “Identify” filter.	Select a Trusted Destination for your encrypted media.

Being head down, singing and dancing encryption with our security glasses on while coding, it was easy to miss the other amazing projects in the room. I highly recommend checking out the other winners as well. They’re doing fantastic and necessary work:

“Scanning” Track Winner: TOSBack2 – a living archive of all privacy policies
“Education” Track Winner: PrivacyBucket – a Chrome extension that measures the extent to which individual third-party trackers can discover demographic information about the use
Judges’ Choice Winner: Site Scoper
“Ready for Primetime” Winner: MobileScope
“Zuckerberg/Systrom Memorial Award for Opportunistic Optimism” Winner: Pestagram
“Best Listener” Winner: The Price of Free

Thanks to Julia Angwin and the WSJ team for making this great event and the fantastic What They Know blog possible, to Gunner for being such an inspiring facilitator, to judges Alessandro Acquisti, Sid Stamm, Dan Kaminsky, Andrew McLaughlin and to everyone else who made this possible.

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.

Transparent encrypted virtual disks for Android (we call it IOCipher)

Tue, 03 Apr 2012 13:16:41 -0400

When using phones, laptops, computers, etc. it feels like a private experience, as if our screen was the same as a piece of paper, and when that paper is gone, then no one can see it anymore. Digital media works very differently. While the user interface portrays the deletion of files as very final, for someone with the right tools, it is actually not hard to recover deleted files. Also, digital information takes up so little space, we now regularly carry vast amounts of information in our pockets. Our phones have become amazingly powerful computers, storing as many photos, videos, documents, etc. in our pockets as would have required a room not so long ago. So when you lose this phone, or it gets stolen, or accessed against your wishes, the lies of the interface are laid bare, and vast troves of your information is now in someone else’s hands. So how can we capitalize on all this power without giving up control of our information?

Encryption provides the building blocks for making the experience no longer a lie. With properly encrypted data, it is possible to throw away the key and delete it, and then no one can get the data ever again. The problem now is how best to use encryption to make our private information actually private with as few complicated decisions or onerous interfaces as possible. Full disk encryption is one popular choice. It does a good job of providing a transparent experience, merely type in a password when you boot up your computer, and the rest is totally normal. But it also offers limited protection. When your full disk encryption is unlocked and your computer is running, that disk behaves no differently than an unencrypted disk. Someone with access to the computer has full access to the files, malware does too, undelete tools will still work, etc. You have to power off the computer to get the protection that full disk encryption provides.

Another option is providing virtual encrypted disks like TrueCrypt or Apple’s encrypted disk images. Then you can decide on what needs to be in which compartment and what is always unlocked versus what is locked away behind a long, cryptic password with a short timeout. This provides good security and privacy when managed properly, but requires a fair amount of skill and time to setup and manage everything. These techniques also require root access since they mount these virtual disks as file systems. We focus a lot on Android, where most people do not have root access.

A related approach is to have a software layer automatically encrypt each file. This is how the EncFS FUSE module and the Certgate MAPL file access work. This provides transparent encryption, but since each file is individually encrypted, a lot of information is still available without decrypting anything: the file size, modification and access times, etc.

We’re working on another approach similar to the approach we took with SQLCipher for Android. We’re calling it IOCipher. In SQLCipher for Android, we took the code from Android’s core android.database.* classes used for working with the built-in SQLite and replaced the guts with the SQLCipher encrypted database. This allows Android app developers to use the familiar and well documented android.database.* API to build in encrypted storage into their apps. With IOCipher, we are again using SQLCipher as the core, but this time we are wrapping it with libsqlfs to make it behave like a filesystem, then grabbing the code to Android’s java.io.* API and replacing the guts with calls to libsqlfs on top of SQLCipher. libsqlfs is also a FUSE(Filesystem in Userspace) module, so it provides an API very similar to the POSIX API for working with files and directories. So that makes it easy to take java.io.File, for example, and replace all the calls to read(), open(), write(), stat(), etc. with calls to sqlfs_proc_read(), sqlfs_proc_open(), sqlfs_proc_write(), sqlfs_proc_stat(), etc. Then all the Android developer needs to do is to java their import java.io.* to import info.guardianproject.iocipher.*, specify the database file to use, and the key to lock/unlock it, and the rest is normal Java programming.

The beauty of using libsqlfs+SQLCipher is that its built of top of SQLite, which gives us a single, very portable file that is the whole filesystem, like a Mac OS X .dmg file or TrueCrypt .tc file. SQLite also allows multiple processes to access the same database file, so that means multiple apps can mount an IOCipher virtual disk, and can use Android permissions and native filesystem permissions to control access to the virtual filesystem. Lastly, libsqlfs is already a FUSE module. FUSE is already nicely integrated into most GNU/Linux distributions, and also available for Mac OS X and BSD. That means that the single file that represents a IOCipher file system could also be easily mounted on GNU/Linux, Mac OS X and BSD (we are already doing this on Debian and Ubuntu, Mac OS X will require some more work).

All in all we think this approach will make filesystem encryption easier to include in Android apps, and also make it possible to have the encryption be trivial to setup and very transparent to the user. Its close to being usable, once it is, we’ll post instructions on how you can use it in your apps. For now, you can follow our progress here:

https://github.com/guardianproject/libsqlfs
https://github.com/guardianproject/IOCipher
https://guardianproject.info/wiki/Products_of_PSST_Work

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

Introducing InformaCam

Fri, 20 Jan 2012 13:58:26 -0400

These are interesting times, if you go by Times Magazine as an indicator. The magazine’s person of the year for 2011 was The Protester, preceded in 2010 by Facebook founder Mark Zuckerberg. Both entities partners with equal stake in freely sharing the digital content that shows the world what’s going on in it, at any time, from behind any pair of eyes. Also casting in their lot with the others is Time Magazine’s 2006 person of the year, You: the You that puts the “you” in “user-generated content;” the You whose miasma of bits, bytes, and the powerful images they express are becoming increasingly problematic. Problematic and exciting. As governments, police forces, and other power players here and abroad crack down on voices of dissent, it is only You, The Protester, armed not with a press pass, but with a smartphone and a Twitter account, who brings the rest of the world its news. You do it mainly without either the support or permission of those in power, and this makes you a very important person in the world.

The smartphone’s role in the defense of human rights has thus become ever-more clear. How can we make it clearer? Our latest project, InformaCam, tackles this issue head-on. In collaboration with Witness.ORG and the International Bar Association, we’re building a powerful tool to create iron-clad digital images and video that could, should the occasion arise, be used in courts of law to bring justice. This is no small feat– with this project we are helping create the first evidentiary standards for digital media in the social networking age. So, there’s been a lot of excitement these past few weeks about InformaCam, as well as a lot of mystery. It’s time to give the project a proper unveiling.

InformaCam is a plugin for ObscuraCam that allows the user, without much intervention on their own part, to inflate image and video with extra points of data, or metadata. The metadata includes information like the user’s current GPS coordinates, altitude, compass bearing, light meter readings, the signatures of neighboring devices, cell towers, and wifi networks; and serves to shed light on the exact circumstances and contexts under which the digital image was taken. Some users will already be familiar with ObscuraCam, which allows for capturing and digitally manipulating media. With InformaCam included, the app starts to behave almost like Adobe Photoshop or GIMP, supporting non-destructive, layer-based edits to media. This means that a version of an image can be created with any sensitive image data and metadata preserved and encrypted to trusted entities, along with a redacted version that has its metadata stripped which can be easily shared to Facebook, Twitter, Flickr, or any public service the user wishes to use.

How InformaCam Works

The workflow is similar to that of ObscuraCam, but with a few key differences. Notice that on start-up, the app triggers the on-board sensors. (Notifications in the top right corner clearly indicate the GPS and Bluetooth modules have been turned on.) This allows the app to register sensory and atmospheric data throughout the session. These “bundles” of data contain the following:

Current timestamp
Device’s identification
User’s public (PGP) key
Image Regions created in the image/video
Current latitude & longitude
Current cell ID (if available)
Altitude
Compass bearing

Whether the user is taking a picture, or editing an existing piece of media, the app registers the goings-on, and signs each bundle of data with the user’s private key. This mean that all actions taken on a piece of media (from capture to editing) are attributed to the user.

As with ObscuraCam, the user can perform image filtering and obfuscation on image regions. InformaCam also adds the “Identify” filter, which prompts the user for the subject’s name (or pseudonym) and to fill in whether or not the subject has given his or her consent to be filmed. This checklist of subject permissions can be further developed to match the needs of any organization to provide further protection to the people in front of the camera. Notice again the sensor notifications: the context surrounding each edit to the image is recorded and will be inserted into the media as metadata once the media is saved.

When the user saves the image or video, a dialog appears prompting her to choose one or more “trusted destinations.” This could be an organization, a news outlet, or any friend whose PGP key is known to you. A copy of the unredacted, data-rich image will be created and encrypted to those parties. At the same time, a redacted and data-stripped version is made available to share with anyone, anywhere.


Using the InformaCam “Identify” filter.	Select a Trusted Destination for your encrypted media.

The Informa Metadata Schematic

The metadata is organized in four categories: intent, consent, geneaology, and data. Here’s a rundown of what these categories mean.

Intent

This expresses information about the media’s creator, and the rules governing how this particular media object can be shared, and to whom.

This bucket of information regards the subjects contained in the image. Each subject is identified (by a name or pseudonym selected by the user) along with their stated preferences regarding treatment of their likeness. For example, if Bobby insists that he wants his face to be fully redacted (rather than blurred) this preference should be registered in metadata.

Genealogy

This information regards chain-of-custody, and represents how the media was acquired, and if a particular image or video is a duplicate of another.

Data

This category includes all standard metadata (timestamp, acquired sensory data, location and movement data) that have been collected during the lifetime of the image, from the moment it was opened to the instant it was saved.

A sample metadata bundle for an image taken with InformaCam looks like this in JSON notation:

{ "data":{ "device":{ "bluetoothInformation":{ "selfOrNeighbor":-1, "deviceBTAddress":"00:25:36:79:EC:6C", "deviceBTName":"nexxxie" }, "imei":"363289131048142" }, "sourceType":101, "imageRegions":[ { "regionDimensions":{ "height":256, "width":256.00006103515625 }, "regionCoordinates":{ "left":527.705078125, "top":196.15255737304688 }, "obfuscationType":"Identify", "location":{ "locationType":11, "locationData":{ "gpsCoords":"[40.7085011,-73.9668647]", "cellId":"36789325" } }, "captureTimestamp":{ "timestamp":1326216508313, "timestampType":7 }, "subject":{ "consentGiven":"general_consent", "informedConsentGiven":true, "subjectName":"Harlo!" }, "unredactedRegion":"I@4070cf30" } ], "imageHash":"f18e7510faaad0d942db68b5c75f219a", }, "geneaology":{ "dateAcquired":0, "localMediaPath":"\/mnt\/sdcard\/DCIM\/Camera\/1326216520426.jpg", "dateCreated":1326216527629 }, "intent":{ "owner":{ "ownershipType":25, "ownerKey":"MY-IDENTITY-IS-HERE" }, "securityLevel":1, "intendedDestination":"[\"harlo.holmes@gmail.com\"]" }

Your Help

InformaCam is a work-in-process, and we’d love help from the community in fleshing out our metadata specification, especially in adding new items to the consent checklist. Feel free to contact us with any suggestions/comments, or just leave some helpful tips in the comments below.

How To: Lockdown Your Mobile E-Mail

Fri, 09 Jul 2010 11:00:25 -0400

Update 2015-04-27: _We now recommend OpenKeychain over APG, the app described in this blog post. The set up is drastically easier, so you probably don’t even need this HOWTO anymore. Start by downloading K-9 and OpenKeychain, then go into OpenKeychain and start the config there._

Over the past few years it’s become increasingly popular to sound the call that ‘email is dead{#y8a0}.’ And while many complementary forms of synchronous and asynchronous communication – from IM to social networking – have evolved since email first came on the scene, it’s hard to see email suddenly disappearing from its role as the most important way organizations communicate. I expect to be scooting around on my hoverboard by the time email goes the way of the dinosaur.

Unfortunately, many of the protocols involved in sending and receiving e-mail are not considered secure – in the sense that they are vulnerable to eavesdropping. Simple Mail Transport Protocol (SMTP) – the Internet standard for e-mail transmission across IP networks most commonly used by client applications for sending messages to a mail server for relaying – is typically implemented without any type of transport encryption. Internet Message Access Protocol (IMAP) and Post Office Protocol (POP) suffer from the same eavesdropping issues as SMTP when implemented without transport encryption. Even when SMTP is implemented with transport encryption it does not, by default, require the authentication of e-mail message senders. As a result, mail servers cannot be sure that the senders of messages are really who they claim to be. And even though POP and IMAP require users to authenticate, messages are sent and delivered using SMTP.

The result is a situation where the recipient of an e-mail message can be positively identified but the sender cannot. Along with the eavesdropping concerns mentioned at the top of the paragraph, this is an alarming state of affairs. Imagine if the same were true of snail mail – there would be rioting in the streets! Fortunately there has been a lot of great work done to combat these fears – the main issue being that the problem itself is still one that is often ignored or not fully understood by the layperson. As secure solutions for mobile platforms gain momentum, we’re hoping to change things.

Enter OpenPGP, an IETF standard for encryption and decryption of data. The version of OpenPGP that exists today is the evolution of PGP, which was created in 1991 as a means for secure BBSs communication and message storage (it ironically also stands for “Pretty Good Privacy”). Why do you need PGP? In the words of its inventory, Phil Zimmerman: “It empowers people to take their privacy into their own hands.” How it works is a whole other story – one too complex for the purposes of this posting – but we’ll do our best to scrape the surface quickly. Disclaimer: The following is meant solely as an introduction. There are many people out there who are experts in these topics, and we welcome any and all comments – especially if we misstate or misrepresent anything!

PGP uses a serial combination of hashing, data compression, symmetric-key cryptography, and, finally, public-key cryptography. From the user’s perspective, it creates two cryptographic keys to encrypt and decrypt data. The first of these two is called the Public Key – which can be freely shared with anyone the user wishes and is used by others to encrypt data so that it can be decrypted by only the intended recipient. The second key is the Private Key, which should be kept as private and safe as possible. It is used to decrypt data that has been encrypted using a specific Public Key. As long as the Private Key is kept secret, only the owner is able to decrypt data that has been encrypted with a Public Key. One problem with older methods of encryption was the relative ease with which codes could be broken. With increasingly powerful computers that are able to crack codes via pure ‘brute force,’ encoding methods must be incredibly complex to stand up. To combat this, PGP uses a key that is astronomically large, meaning that the security of PGP encryption lies entirely with the key as opposed to keeping the method for key generation a secret. In fact, the methods that PGP encryption uses are known and widely documented. In addition, the size of keys can be increased whenever necessary to stay one step ahead of technological advances. And for the time being, each of the algorithms in current use by PGP is not known to have cryptanalytic weaknesses.

So how secure does this make your information? Italian Police, the FBI, and British police have been unable to crack its security and have resorted to demanding private keys. It’s been likened as “the closest you’re likely to get to military-grade encryption” by cryptographer Bruce Schneier. Short answer: pretty darn good, as long as you guard your private key wisely.

You’ve probably guessed by now that the reason for this posting is to show you how to effectively use OpenPGP to secure your mobile email. And while we would’ve loved to just jump right into the tutorial, there are a few more things you should know first. Android Privacy Guard{#udlg} (or APG for short), is a first step at bringing OpenPGP{#qtjc} to the Android platform, letting you manage OpenPGP keys directly from your Android phone – and use them to encrypt, sign and decrypt emails and files. Very recently the teams behind APG and the popular, open-source Android email client K-9 Mail have joined forces in a limited edition team-up to create a beta version of K-9 that plays nice with APG quite seamlessly. We’ve been using it as our default email solution at Guardian for weeks now and want to share it with you!

Note: Currently APG only supports importing and deleting keys – not generating them – so you’ve got to use a desktop implementation of OpenPGP (such as GNU Privacy Guard{#vrm_}) to actually generate your keypair if you don’t already have one. A number of front-end applications and libraries are available to perform this task. If you already have a keypair set up, you should skip the first step.

1. Download and Install GnuPG Generate an OpenPGP keypair

Install GnuPG here. There are binaries available for whatever OS flavor you prefer, and since they do a great job of making documentation and How-To Guides available, we’ll skip the part where we reinvent the wheel.

2. Generate and export your keypair

Follow the instructions here to create a new keypair. Export your public and private keys (re-direct from stdout to a file) and stick that file on your Android device’s SD card. Usually it’s best to create a new folder /APG to keep things organized, especially if your SD card is a mess like ours 🙂

3. Download APG and import your keys

If you don’t already have it, download Android Privacy Guard from its repository here or point your barcode scanner to the QR code below. You can also find it on the Market if you prefer.

Fire up APG and select ‘Manage Public Keys’ from the menu:

From the ‘Manage Public Keys’ screen, select ‘Import Keys’:

From the popup dialog, select the public key that you’ve transferred to your SD card. It’s helpful to use a file browser program like Astro File Manager if you don’t already have it installed:

<p style="padding-left: 30px; text-align: center;">
  <span style="line-height: 8px;"><a href="https://guardianproject.info/wp-content/uploads/2010/06/apg_import_keys_blur.png"><img class="size-medium wp-image-392 aligncenter" title="apg_import_keys_blur" src="https://guardianproject.info/wp-content/uploads/2010/06/apg_import_keys_blur-180x300.png" alt="" width="180" height="300" srcset="https://guardianproject.info/wp-content/uploads/2010/06/apg_import_keys_blur-180x300.png 180w, https://guardianproject.info/wp-content/uploads/2010/06/apg_import_keys_blur.png 480w" sizes="(max-width: 180px) 100vw, 180px" /></a></span>
</p>

<p style="padding-left: 30px;">
  <p style="padding-left: 30px;">
    Once your public key(s) are successfully imported, return to the main APG menu, select ‘Manage Secret Keys’ and repeat the steps above for your Private Key.
  </p>

  <p style="padding-left: 30px;">
    <strong>4. Download and Configure K-9 Mail</strong>
  </p>

  <p style="padding-left: 30px;">
    Download the latest version of K-9 mail featuring APG integration. You can find it on the Downloads page <a href="https://code.google.com/p/k9mail/downloads/list">here</a> or, again, point your barcode scanner to the QR Code below. Whatever floats your boat.
  </p>

  <p style="padding-left: 30px; text-align: center;">
    <img class="aligncenter" src="https://chart.apis.google.com/chart?chs=150x150&cht=qr&chl=http://k9mail.googlecode.com/files/k9-apg-2900-beta.apk&chld=L|1&choe=UTF-8" alt="" width="125" height="125" />
  </p>

  <p style="padding-left: 30px;">
    Set up your email account by entering your email address and password, then give it a name.
  </p>

  <p style="padding-left: 30px;">
    <a href="https://guardianproject.info/wp-content/uploads/2010/07/k9_setup1.png"><img class="aligncenter size-medium wp-image-451" title="k9_setup" src="https://guardianproject.info/wp-content/uploads/2010/07/k9_setup1-168x300.png" alt="" width="168" height="300" srcset="https://guardianproject.info/wp-content/uploads/2010/07/k9_setup1-168x300.png 168w, https://guardianproject.info/wp-content/uploads/2010/07/k9_setup1-84x150.png 84w, https://guardianproject.info/wp-content/uploads/2010/07/k9_setup1.png 480w" sizes="(max-width: 168px) 100vw, 168px" /></a>
  </p>

  <p style="padding-left: 30px;">
    <p style="padding-left: 30px; text-align: center;">
      <img class="aligncenter" title="k9_almost_done" src="https://guardianproject.info/wp-content/uploads/2010/07/k9_almost_done-168x300.png" alt="" width="168" height="300" />
    </p>

    <p style="padding-left: 30px;">
      For more popular accounts such as gmail, Yahoo!, etc., K-9 will automatically detect the correct configuration. For more complex accounts such as Exchange, please check out the K-9 wiki page <a href="https://code.google.com/p/k9mail/w/list">here</a>.
    </p>

    <p style="padding-left: 30px;">
      <strong>5. Send and Receive Encrypted Email!</strong>
    </p>

    <p style="padding-left: 30px;">
      Thanks to the integration effort by the teams at APG and K-9, actually using secure mobile email becomes easy. The compose screen features a prominent checkbox and button that allow you to sign and encrypt your outbound messages, respectively.
    </p>

    <p style="padding-left: 30px;">
      <a href="https://guardianproject.info/wp-content/uploads/2010/07/k9_compose.png"><img class="aligncenter size-medium wp-image-453" title="k9_compose" src="https://guardianproject.info/wp-content/uploads/2010/07/k9_compose-168x300.png" alt="" width="168" height="300" srcset="https://guardianproject.info/wp-content/uploads/2010/07/k9_compose-168x300.png 168w, https://guardianproject.info/wp-content/uploads/2010/07/k9_compose-84x150.png 84w, https://guardianproject.info/wp-content/uploads/2010/07/k9_compose.png 480w" sizes="(max-width: 168px) 100vw, 168px" /></a>
    </p>

    <p style="padding-left: 30px;">
      Decrypting messages with your private key is even easier and is literally a 1-touch experience:
    </p>

    <p style="padding-left: 30px;">
      <a href="https://guardianproject.info/wp-content/uploads/2010/07/k9_almost_done.png"></a><a href="https://guardianproject.info/wp-content/uploads/2010/07/k9_view_decrypt.png"><img class="aligncenter size-medium wp-image-455" title="k9_view_decrypt" src="https://guardianproject.info/wp-content/uploads/2010/07/k9_view_decrypt-180x300.png" alt="" width="180" height="300" srcset="https://guardianproject.info/wp-content/uploads/2010/07/k9_view_decrypt-180x300.png 180w, https://guardianproject.info/wp-content/uploads/2010/07/k9_view_decrypt-90x150.png 90w, https://guardianproject.info/wp-content/uploads/2010/07/k9_view_decrypt.png 480w" sizes="(max-width: 180px) 100vw, 180px" /></a>
    </p>

    <p style="padding-left: 30px;">
      <strong>Enjoy! </strong>As always, please post all questions, concerns, and jokes (only good ones please) in the Comments section. We’re very excited about the powerful combination that these two apps bring and we’d love to hear from you!
    </p>

    <p style="padding-left: 30px;">
      If you find any issues with APG, please report them <a href="https://code.google.com/p/android-privacy-guard/issues/list">here</a>:
    </p>

    <p style="padding-left: 30px;">
      <span style="line-height: 13px;"><span style="line-height: 16px;">Likewise, report issues with K-9 <a href="https://code.google.com/p/k9mail/issues/list">here</a>. </span></span>
    </p>