Page:
API Design
Pages
API Design
Alternative Passphrase Methods
App Security
Backups
Build Security
Competing Apps
Database Design
Google Summer of Code 2014
Google Summer of Code 2015
Google Summer of Code 2016
Home
Icons and Colors
Intents
Keyserver less OpenPGP
Language Conventions
OpenPGP Key Transfer
OpenPGP Security
Paper
QR Codes
Release Management
Secure OpenPGP Key Pair Synchronization via IMAP
Security Tokens
Test URLs
Vulnerabilities
cure53 Security Audit 2015
3
API Design
Dominik Schürmann edited this page 2016-02-23 11:30:48 +01:00
Table of Contents
OpenPGP Remote API
Please also read the Tutorial and try out the demo app before reading this.
- The API does not use the Android permission system due to its problems (details). Instead OpenKeychain stores its own table of granted applications.
- The API should be as easy as possible and extendable. Because of this, the AIDL file is kept small and all operations are defined by Intents which can be passed through this interface to the remote service.
- The API should be able to work on
byte[]
,Strings
, and files. To implement this, we useParcelFileDescriptors
, which are passed via the AIDL method.ParcelFileDescriptors
are initialized overInputStreams
, which can be based on all content types. (Note:ParcelFileDescriptors
can not be part of the Intent, because of constraints in Android OS. They must be part of the AIDL method) - The client app should be able to define where output is written, thus the calling client defines a
ParcelFileDescriptor
used to write the output into. - Clients should never be able to actually access the private key object
- Clients should only work with private keys explicitly allowed by the user. This is done by API accounts on the side of OpenKeychain. Clients request a specific account based on a unique name and the user can then select the private key for this account. Clients can only decrypt with private keys set for these accounts.
- All user interaction should be happening on the right task stack and clients should be able to specify by themselves when user interaction should be shown (consider a background encryption task, where a passphrase input is required. The user interaction for passphrase input should be delayed until the user unlocks his/her phone again). This requirement is implemented by returning
PendingIntents
to the client application, which are then started by the client at a chosen time.PendingIntents
are also attached to the client app's task stack. Actitivites are never started from OpenKeychain's background service.