PSST

From Guardian Project Wiki

Contents 1 Portable Shared Security Tokens 1.1 Project Sites 1.2 Areas of Inquiry 1.3 Background Narrative 1.4 Proposed Work Plan 1.4.1 Research Questions 1.4.2 Core Activites 1.4.3 Proposed Prototypes 1.5 Timetable 1.5.1 Timetable Task Detail

Portable Shared Security Tokens

Project Sites

• https://github.com/guardianproject/gnupg-for-android
• https://github.com/guardianproject/otrfileconverter
• https://github.com/guardianproject/notepadbot
• https://github.com/guardianproject/IOCipher
• https://github.com/guardianproject/IOCipherServer

Areas of Inquiry

• PSST User Stories
• Encryption and Identity Verification
• Securely Storing and Syncing
• Existing PSST Tools
• Products of PSST Work

Background Narrative

While the use of public key-based cryptographic tools (HTTPS/SSL, OpenPGP, OTR chat) has been growing rapidly within human rights and activists organizations, a growing issue looms around the increased diversity of mobile devices that a user might have. The current solution used for managing a set of public and private keys for identifying a circle of trusted people and services is designed around a first-world model ("This computer is mine and no one else's"). As the worldwide computing boom leans decidedly towards mobile devices, new concepts and approaches to managing trust and securing communications need to take into account these new types of users. A portable yet secure solution for establishing one's identity, based upon interoperable standards need to be developed.

This is by far the current most vexing end-user issue we face with our early deployments of Guardian handsets, as well as the most unique aspect of the entire proposal. At this point, we have to create completely new security identities that are separate from any existing identities, keyrings, webs of trust, etc that exist on the desktop. Having identity tokens that can easily sync between computing contexts, with them being secured the entire time is an important problem to work on, that can have some near term end-user benefit. I also believe that just the research into this area, along with published papers, blog posts, and code on the subject, could make a meaningful contribution to the field in general. With our recent breakthroughts in bringing a viable, cross-platform open-source encrypted database, I feel like we've got a big headstart into engineering this, as well. It is one of these features that users aren't asking for specifically, but in the back of their heads they wish they had. We have made some ground with this in Gibberbot (QR code scanning of identity keys, etc), but that is just a first step.

As cryptographic software proves itself to be useful, parts of the infrastructure to maintain it is showing severe weaknesses.  The certificate authority model of HTTPS/TLS is being broken in greater ways with each month passing.  The PGP "Web of Trust" has proven itself in such communities as Debian, now the barriers for widespread adoption are the ease of use of the software.  The problem can be broken down into three parts: the use of keys for signing/encrypting, the signing of other keys to provide identity validation, and keeping the private and public keys in sync on various devices.  The first is addressed in a fair amount of software packages like APG, Gibberbot, K-9, Pidgin, Adium, etc.  For signing of other people's keys, this is not widely addresses outside of very technical circles. Gibberbot makes it quite easy to verify another person's OTR fingerprint, Seahorse simplifies the PGP signing process quite a bit, but there is no app that handles all signing processes with easily. For the third part, gnupg provides robust public key and signature syncing for PGP keys but that leaves out OTR keys and TLS certs.  The PGP Web of Trust also has privacy issues since all of the data is stored on public servers, allowing for easy construction of entire social graphs. In many countries, this would endanger the users of the crypto software.

Since this project requires the syncing and secure storage of files, it might make sense to also expose this syncable, secure file store for general use.

Proposed Work Plan

Research Questions

1. What kind of data on a users desktop or laptop computer (PC) needs to be synced and stored securely on their mobile phone? Which data is most critical or most helpful to have while on the go?
2. Should the model for data syncing be a direct PC to Mobile sync, or can it take advantage of cloud or wider network based resources?
3. Can the syncing or identification of trusted third-parties utilize existing “Web of Trust” resources such as public OpenPGP directory servers, or do relationships that existing in this data need to be obscured?
4. What kind of verification needs to be put in place to ensure that the syncing between PC and Mobile does not suffer from man-in-the-middle attacks or other intrusions?
5. What is the best storage mechanism for secure data on a mobile device, an encrypted file system driver, or an encrypted relational database?

Core Activites

1. Identify target users, user stories, threat levels, bad actors
   1. Define targets for level of security
      • Baseline / typical solution
      • Hardened / locked down solution
   2. Model user stories and at-risk assets
      1. Low risk: public verified keys
      2. Medium risk: mobile private keys
      3. High risk: private keys
2. Design and Prototype Solutions
   1. Secure Sync between Desktop and Mobile
   2. Key / Token Management on Mobile
   3. Secure File Storage solution

Proposed Prototypes

The project will implement one or more prototypes of the PSST system that support syncing of secure data from the following applications:

1. Gibberbot to Pidgin Secure Messaing OTR Key Sync
2. Android Privacy Guard to Gnu Privacy Guard Desktop Public and Private Key Sync
3. Root Certificate Authority storage and sync to Android CACertMan/CACerts.bks
4. Shared Secure File System: secure file sharing between mobile and desktop
   1. NoteCipher: add support for all file types to existing “secure notepad” app
   2. Personal sync between devices not multiuser (i.e. not dropbox)

Timetable

Timetable Task Detail

Task Detail

1. Auditing
   1. Existing software and services will be inspected, tested and vetted
2. Development Sprint
   1. Each sprint will last 6 weeks
   2. All code will be managed and logged in a public version control system
3. User Testing and Design Review
   1. Promote the current stable release of prototype to a select group of users
   2. Hold design review meetings with all team, partners and others relevant
4. Publishing Papers / Specifications
   1. Publicly share proposal for any new specifications or services
   2. Post documentation of best practices determined

Timeframe	Milestone
October 1 - December 31, 2011	Two six week development sprints
January 1 - March 1, 2012	User testing and design review One six week development sprint
March 1 - March 31, 2012	User testing and design review One final development iteration Final review and publishing of spec / paper