$Id: security.txt,v 1.5 2005/08/03 19:08:09 droggo 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 ".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.]