$Id: security.txt,v 1.1.1.1 2008/09/10 09:32:57 agcrooks Exp $

Security document - BSD Privacy Guard
=====================================

1. Security Top-10
------------------

1) Securize the weakest link.

2) Validate input.

3) Follow the least priviledge principle.

4) Ask the experts.

5) Minimize trust relationships.

6) Don't reinvent the wheel.

7) Use tools for checking code vulnerabilities.

8) Make the system secure by default.

9) When fail, fail safe and loud.

10) Keep it simple.


2. Security issues
------------------

2.1. Memory purge

Confidential plaintext data can be found in the memory if we are not
careful. Passwords, private keys and decrypted messages must be
protected from local spying or forensic analysis.

Any vestige of confidential data must be proned from memory
inmediately after being used. For this, BPG will implement a
"securedelete" function that overwrites data with random stuff N
times.

Also, memory should be kept out from being paginated to disk (i.e. use
mlock).

Core dumps must be prevented (i.e. with ulimit).


2.2. Integrity of the keyring

The keyring can suffer deletion or insertion of keys if the keyring
directory is not well protected (or an evil user becomes the owner of
the keyring).

As the keys are all signed individually, the insertion is not a
problem, but it is the deletion: we can end marking a key as untrusted
(because we don't find the key) when it's actually trusted.

For fixing this, a digital signature of the whole keyring will be
always included in the keyring directory, in the file
"<keyring_name>.sig".


2.3. Man-in-the-middle attacks

A man-in-the-middle attack happens when an evil user, Mallet, sends
Alice a public key as if it were Bob's, and viceversa. This way, all
confidential messages that Alice and Bob interchange each other will
be received and decrypted by Mallet. Also, Mallet will be able to send
messages as if she was Alice or Bob.

Preventing this threaten is difficult. Any user can commit a key to a
key server pretending to be somebody.

For controlling this, BPG implements trust. By default, keys from
arbitrary sources are "untrusted", unless the user says other
thing. When you receive offline confirmation that the key signer is
who oughts to be (face-to-face meeting, for instance), then you change
the status of the key to "trusted".

In practice, it's a little more complicated. Depending on the trust
policy, you can trust keys signed by trusted users, or trust users
trusted by trusted users, depending on its level of trust.


2.4. Emissions captures

Computers screens emit electromagnetic signals that can be spied by
users placed physically near our box. So, decrypted confidential
messages can be acquired with this technique.

A way of avoiding this is to implement a viewer for X that uses
low-radiation fonts, making the message resist a TEMPEST attack.

BPG can implement this kind of viewer in the future.


2.5. Time-based attacks

Some attacks use the time an algorithm uses for encrypting or
decrypting something to deduce an approximation to the used key.

BPG algorithms will introduce random slots of time while processing to
prevent this kind of attack.


2.6. Password sniffing

Local users in the system (or trojan horses) can spy our keystrokes
and obtain the passphrase we use for private key protection or
symmetrical encryption.

There's a need of stablishing a trust path between the user and the
authentication module. It's not clear yet how will we achieve this,
and usabilty will be very important. A secure system shell is a
possible solution.

BPG will use PAM to acquire passwords.


3. Tools
--------

For reinforcing security, we'll use external security tools for
automatic code revision. This aims to reduce common coding
errors.

Which tools will be used is yet to be determined.


4. Security in GnuPG
--------------------

[TO-DO: description of good and bad design solutions in GnuPG in terms
of security.]
