Disk Overwrite or Wipeout Best Practice

An online search shows majority of tools available for wiping out data on a disk points to a practice of 7 wipes. They believe that it is a US DoD requirement. Some of them support the Gutmann method of 35 wipes.

However, I could not find any documentation on US government website that indicates seven wipes. The US DoD 5220.22-M, “National Industrial Security Program Operating Manual that most online tools refers to does not have any requirements of number of wipe passes. However, I found a wiki page on Data Remanence that has enough citation and it contains the following –

“As of November 2007, the United States Department of Defense considers overwriting acceptable for clearing magnetic media within the same security area/zone, but not as a sanitization method. Only degaussing  or physical destruction is acceptable for the latter.[4]

On the other hand, according to the 2006 NIST Special Publication 800-88 (p. 7): “Studies have shown that most of today’s media can be effectively cleared by one overwrite” and “for ATA disk drives manufactured after 2001 (over 15 GB) the terms clearing and purging have converged.”[1] An analysis by Wright et al. of recovery techniques, including magnetic force microscopy, also concludes that a single wipe is all that is required for modern drives. They point out that the long time required for multiple wipes “has created a situation where many organisations ignore the issue all together – resulting in data leaks and loss. “[5]Continue reading “Disk Overwrite or Wipeout Best Practice”

Protecting Clear Text Password

Passwords are the basic type of authentication in a system. They are easy to implement and also easy to attack. However, there are situations where you need to use a password to protect access to a resource. Its fine if an end user of system is providing the password directly to the system. Sometimes you need to store the password in a configuration file of a system. That’s where the dilemma starts. You have a scheduled SFTP process that needs a password to start. Do you keep the password in clear text or do you encrypt it? If you encrypt it, then how do you protect the key to encrypt and decrypt the password?

I would never suggest you to keep the password in clear text. Always have the password (in store) encrypted; symmetric encryption using 3 DES is preferred as it is efficient and will not tax the system resources. The keys can be stored in a key store. Any process or function in the system needs to have a password to access the key store to get the keys. So how do you protect the master key to the key store? Easy and economic way is to have the master password to the key store in a system configuration file that can be accessed only by the function or process that needs to know about it.

This is not a complete secure solution. However, we are introducing concept of security-in-depth where you are introducing layers of security to protect a resource. So when the scheduled job of SFTP needs to be kicked off, the process (or the job) first accesses the configuration file that contains the master password for the key store provided the process has the right privilege to access the configuration file. Once the process gets the master password, then it would decrypt the cipher text (encrypted password) to get the password to kick off the SFTP.

Key Management in Java

Sometimes developers find it confusing or hard to connect the dots between some of the key management interfaces in Java especially the key generators, key tool and key store.

In Java, keys are generated using a special class called key generator. Creating new random keys involves – invoking a key generator object for the algorithm you want to use, initializing the key generator and then request it to generate the keys.

There are two types of keys that can be generated asymmetric and symmetric keys. The asymmetric keys are generated using java.security.KeyPairGenerator class while the symmetric one by javax.crypto.KeyGenerator class. Mind you, the latter one is part of Java Cryptography Extension (JCE).
Both follow the same steps as descibed above. A symmetric key generation example is –

KeyGenerator myKG = KeyGenerator.getInstance(“DES”);
myKG.init(new SecureRandom());
SecretKey myKey = myKG.generateKey();

An example for asymmetric key generation would be –

KeyPairGenerator myKPG = KeyPairGenerator.getInstance(“DSA”);
KeyPair myKeyPair = myKPG.generateKeyPair();

In case Sun’s APIs does not support the required algorithms, then you may to look for other cryptographic provider APIs. IAIK, RSA and Entrust are some of the well known cryptographic providers, at least those that I have used. In your code, you will have to add these providers before generating the keys.

After the generating the keys, you need to store them. KeyStore (java.security.KeyStore) comes handy for holding keys as well as certificates. KeyStore contains two types of entries – (1) a private key along with the chain of certificates that correspond to the matching public key (2) a certificate of someone you trust. KeyStore supports storing and loading of keys, adding key pair entries, as well as adding and retrieving trusted certificate entries.

A passphrase is required to check the integrity of the data while you are in the operation of either storing and loading of a key or while adding key pairs. A clear text passphrase can be used, however that’s definitely not secure. One of the ways to avoid dictionary attacks, though not a real secure way, is to encrypt the private key by randomly creating a passphrase and then mixing it with the private key. The other one, probably the best one, is to use Password Based Encryption (PBE). Here a passphrase is used to generate a session key. The session key will be used with a symmetric cipher to encrypt the original private key before it is saved to the KeyStore.

While KeyStore is a simple database for storing private keys, public keys and certificates, keytool is a command line interface to the java.security.KeyStore class. You can use it to generate key pairs, inspect the KeyStore, generate CSR and also import certificates along with other options and functions.