Security of Data can not be well maintained without the use of high-grade encryption. Even relatively low-grade encryption, such as the 128-bit SSL keys popular in Web communications, can be broken given enough patience. Of course, data security needs must be managed carefully against performance considerations. It doesn't matter if you're data is absolutely unbreakable, if using it is so inconvenient that no one will bother. Of course, computer power has increased at such a rate lately, that encryption times are no longer as much of an impediment as they used to be. Ten years ago, who would have dreamed of using an encrypted filesystem? These days, it would be foolish to consider having any private data on a laptop that wasn't encrypted. Which leads, easily, into the First Law of Enterprise Encryption:
All portable computing devices **must** be protected with a proven encrypted filesystem.
This ensures that even if a piece of hardware is stolen, the data on it will be safe from prying eyes. Of course, anytime you keep encrypted data, some sort of security is needed to protect the key used to decrypt the data. In most systems, this will be implemented as a passphrase. Brute-forcing has come a long way in taking advantage of the increased parallelism of modern sytems, but don't be fooled. Unless your password is very short, and very simple, even the most advanced Brute Force method will still take years to complete. That isn't to say that your current password is good enough, or that you shouldn't work hard to protect it. I've seen plenty of good heuristics which can greatly improve the performance of a Brute Force attack by taking advantage of common patterns.
Interestingly, passphrases have been a deterrent to many organizations to adopting high-grade encryption. The reason is simple, and I'm sympathetic to it. If you lose your passphrase, or your key, any data encrypted with that key is lost forever. Losing keys should almost never happen. Storage is cheap. Backups are easy, and plentiful. Even printed out, a 4 Kilobyte RSA key (generally considered enormous), will take only a few sheets of paper, and will be more resilient than a digital copy. Backups should always be stored in a secure location (a safe would be ideal, or a bank vault). If you must keep a backup of your passphrase, it should be stored in a seperate physical location from the key.
Backup copies of keys and/or passphrases should be kept in highly secured facilities, which very few people have access to, and they should never be kept with each other.
Now that the data and passphrases are secured for portable devices, we arrive at a question of securing communcations. SSL provides good coverage for most purposes, plus key sizes have grown quite a bit recently, providing far better security. However, SSL has a few downsides. First, it's expensive to get a key that is signed. Part of this is the Certificate Authority (CA) needing to go through the steps of verifying your identity and worthiness of a signed key, and it's worked out fairly well for the web, where a list of trusted CAs may be maintained by the browser vendor. Of course, this implicit trust model could be exploited, though most organizations have enough interest in keeping their reputaion in order to prevent gross abuses. The key problem lies with the fact that it is nigh-impossible for a user to add a new CA key to their systems. If you wanted to trust that I was a worthwhile signer of keys, and you could trust any key I put my digital signature on, it isn't straightfoward to add my key as a trusted signer. Further, people looking to get keys signed would be unlikely to choose to have me be the signer on their keys, since if my key isn't listed as a trusted key on a user's browser, the user is presented with errors. In effect, we've pushed the control of the web of trust into the hands of corporations like Verisign, who charge $300-$1200 per year for a key. Even if Thawte offers e-mail keys for free, they don't allow the use of the key for business use, making it basically useless in our target today: the Enterprise.
The current state of crypto-management, with a small number of dedicated CAs and high cost of entry, is a symptom. It's a symptom of the lack of good integration of cryptographic technology and thinking into our current environment. Some people say it's because we're not evolved correctly to handle modern security and trust issues as they relate to the Internet. I think that's unfair. Modern information security may not be instictual (just yet), but we can still learn to use it, and as the technology becomes more tightly integrated into our computing systems, we won't have to worry about it. However, I think the way a healthy crypto-ecosystem is supposed to work is perfectly understandable to most users. It's built around the Web of Trust concept. Most people already live their lives according to a web of trust theory.
You tend to trust your close family and friends, and therefore, will extend a bit more trust to your those people who demonstratably know someone you trust. For instance, if my father indicates that he trusts someone whom he works with, I'm more likely to trust that person because my father does. This is a very basic level of how our society is orgnanized. Yes, it can be taken advantage of (con-artists take advantage of this aspect of trust all the time), but public-key cryptosystems require a more explicit expression of trust than normal society: the key signing. Some people even have get togethers where they arrange to sign one anothers keys, thus expanding the web of trust. Key Signing Parties are an interesting method to solving the problem, but ideally, all people who use a digital system would have their own private key, and the web of trust could be grown more biologically than it is today.
Large organizations are in an interesting position to solve the web-of-trust issue. Large companies already perform verification of identity when they employ a new employee, and in doing so, could easily sign an encryption key for the user, having verified that they are who they say they are, and the key does belong to them. For an organization which consists of many departments, a 'keymaster' could be assigned, who's responsibility it is to sign verified keys. As long as the trust model ensures that users trust the 'keymaster' for a department, all keys signed by that 'keymaster' will have at least some level of trust associated with them. This allows for secure communication between all users on a cryptosystem, and allows for the transmission of even the most priveledged data, since it will travel through the network in an encrypted state, safe from prying eyes.
Unfortunately, there are problems with all well-meaning cryptosytems. Key distribution, key revocation, key expiration. A lot of questions and arguments on how to handle these issues. I'm not going to touch on them today, but upcoming posts will deal with these problems, and possible solutions.