Passphrase storage and encryption
How to be sure a client is on the same machine as the server
Developers must protect their own systems carefully
Test, test, test. Because paranoia is a virtue, test everything, even things that you don't think will matter.
Use static checkers such as Findbugs and PMD. When you disagree with their reports say why in the code.
Test dynamically using tools such as JUnit.
Automatic testing is essential, but no substitute for traditional Alpha and Beta testing.
Get peers who understand software security to review your code.
"Security" software without source code isn't secure
You can't do source code audits without source code
Open source is no guarantee that it's trojan-free, but it definitely helps
As a user, not as root. Nothing in Tiger requires root access, with the possible exception of Business Envelopes
Minimum permissions from MAC such as LIDS
Some of these memory types are not shared on some systems
Patches to Kaffe could help with static data, stack and heap
Command lines can be hidden, although that opens other vulnerabilities
Pipes can be encrypted or avoided
If we can, lock memory pages
On Linux you can't lock memory unless you're root. Can you do it at all on Windows?
Standard Java does not allow page locking, but it should be doable via JNI
Locking memory is less important than many believe, since it usually doesn't secure memory used by pipes, stacks, heaps, etc.
Stacks and heaps are easily locked under some OSes, but are usually still executable. There are solutions to secure stacks and heaps, but few security pros use them, much less ordinary users.
There isn't an accepted secure protocol for pipes. Designing one would be easy, but getting it adopted would not.
No good solutions are available for peripherals such as keyboard and screen, or their drivers. Communications channels between device drivers and apps using them could be secured by, e.g., a pipe protocol transporting XML.
Internal hard disk
External hard disk, flash, microdrive, etc.
Don't just erase files. Wipe them. Use "shred" on *nix.
Wipe free disk space regularly
Create temp file to fill space
Remove removable media when not needed
Don't make or keep unneeded copies
Run in as limited a sandbox as possible
Sun source code is available, but neither libre nor gratis, so few will perform security audits on it
Consider Kaffe for the JVM and class libraries
Consider classpathx for java extensions
Rewrite or replace any Sun packages used
Fairly good decompilers exist for java, and might be at least a short term measure
Actually do security audits
Tiger is intended to be used. Security that isn't used might as well not exist.
Ideal authentication requires something you have, know, and are. This is almost always overkill.
Almost all mail clients store user names and passwords now anyway
After several years, we know that the only mail client encryption packages that most people will routinely use are the ones that store the passphrase
More secure, and less usable, options
Passphrases and keys on removable tokens. Should be a user option.
Require user to reenter passphrase every session. Passphrase kept only in memory. Should be a user option.
Secure coprocessor. Many types available, from a computer connected via floppy net or the parallel port without a network stack, to smartcards. An option in later versions.
Whether and how long a passphrase is stored is a user option
Carefully watch developments in areas such as blinded biometrics
Security experts who react in horror when ease of use wins over security should remember
Unused security is useless at best, and may provide a false sense of security
Sometimes the goal is "as private as a paper envelope"
We all need the cover traffic
If the decryption key is not on removable media, with an open source package an attacker knows exactly where on the system to get the key. Even with closed source it's usually not much challenge to find it, and closed source is less secure anyway. So encrypting passphrases with the key hidden somewhere on the disk would be just for show, to impress people who don't know how encryption works. We are very reluctant to do that.
An effective alternative is to put the master key on removable media, creating a hardware token. But requiring that the user keep track of a hardware token is definitely not "Making private email easy". It is an appropriate option for Business Envelopes.
Some Java security advantages
No buffer overflows
Detects stack attacks, bounds errors, and more
Easy to solve most race conditions with the "synchronized" keyword
Has no setuid, setgid, chown, etc.
Has built-in deleteOnExit for temp files
Has a pretty good MAC (Mandatory Access Control) system built-in, although it's often unused
Typesafe dynamic storage with automatic garbage collection
No signals; instead relatively safe and rigorous Exceptions
Some Java security risks
The interpreter and runtime libraries are usually closed source
The language specification is controlled by a corporation
JNI (Java Native Interface)
createTempFile by default uses shared dir and is non-atomic
World permissions for files are the default
printf was added to java as java.text.MesageFormat.format; the class is "compiled", i.e. native code, and may have the format bug
Possible excuses for using JNI
no chroot() in Java
no ulimit() or setrlimit()
But on Linux only root can lock memory, and we don't want to run as root
Maybe for Business Envelopes
no easy way to zero objects
Minimize or eliminate use of JNI (Java Native Interface)
User input should be carefully filtered for characters, length, and as much as possible, for syntax and semantics.
Character streams to System.out and System.err should be filtered
Allow only letters, digits, spaces, punctuation, and line endings
In particular no '>", '<', or '|'
Audit the interpreter and libs
This requires open source, which means a non-Sun jvm such as Kaffe
Why not C or C++?
Open source java code has "an order of magnitude fewer" bugs than closed source C/C++ code.
C handled most of the serious work for many years, but it was designed in the 1970s and shows it
Too many security related programming errors are easy in C
Although it's a little easier to write around some security bugs in C++, it's not much safer than C
You can write safe code in C or C++ or even assembly, but unless it's all you know, why take the risks?
If you must use C or C++, use safer tools such as IBM's Stack Smashing Protector
Local IP address
Not only checked by software. If web page, page should say e.g., "Domain in url for this page must be 127.0.0.1."
Local ping times
Local dynamic SSL cert
Server only accepts SSL connections, e.g. HTTPS but no HTTP
Server dynamically regenerates client SSL cert
When client connects, server verifies client cert is the same one server generated
Challenge-response through local channel
Dynamically generated secret key
Ideally shared through RAM
Response time below net times
Requires custom client
Copyright © 2005-2007 Tiger Privacy