Data Destruction and You
Despite what procrastinating students and thesis authors might tell you, its actually pretty difficult to lose your homework if its ever been written to disk. This is usually good news. However, there are those few occasions when you really wish people couldn't pull up every retirement planning document, bank statement, credit report, or other personal information you've ever stored on your computer. Those occasions include getting rid of old computers or hard drives, sending in a machine for tech support, or leaving a job. I can tell you, if I were in a position where I was receiving someone's old hard drive, I'd have a hard time not at least taking a peek.
"So, what do you do?" If someone is getting rid of a computer or hard drive, they might at least format the disk. If they are sending their computer in for technical support, they might move their sensitive documents over to a thumb drive and delete them from the disk. These are both decent tactics to prevent access by a true novice, but will rarely do anything to deter a more experienced data recovery expert. The reason for this? When files are deleted or disks are formatted, typically the information about the files on the disk is updated, but the actual memory where the files were written is unchanged. "So, really though, what should you do?" Well fortunately there are a few tools out there to help. Their basic function is to scramble the actual memory where the files were written and then update the file information appropriately.
DBAN: The Hard Drive Final Solution
Darik's Boot and Nuke, or DBAN, is the tool to use for wiping whole hard drives. When you're getting rid of old disks, leaving a job, or really just want to stress test a hard drive, just download the ISO, burn it to a CD and boot from it on the computer that you want to nuke. There are a few options available on startup. These control the type of disk wipe to perform. Generally speaking, unless you are either very paranoid or just have a week to kill, the default (dodshort) is sufficient. At the prompt, simply type "autonuke" and hit enter. Depending on disk speed and size the time to completion can vary wildly, but plan for at least a day of operation.
Shred: Single File Destruction
Shred is a pretty standard Linux command. It has a few useful command line options, including whether to use random data when over writing the file, use only zeros on the last pass, the number of passes over the file to make and finally to actually delete the file afterwards. Typically I use something like: shred -uzn38 <target file>. It is important to note that if you are using a Journaling file system, this may not be an effective mechanism. However, you can in most cases tweak journaling levels so that this will not be an issue.
Secure-Delete: More than just a Shredder
The people (person?) at Techthrob wrote a pretty good article on this subject and I found their coverage of Secure-Delete especially wonderful. I'll be lifting a few parts here.
Secure-Delete is a bit of an all in one solution for scrubbing a computer, not just the hard drive. It comes with a shredder (srm), a memory scrubber (smem), a free disk space scrubber (sfill), and a swap space wiper (sswap). This is a tool-set which is appropriate for cleaning up a machine that you don't quite want to nuke. The man pages for these tools provide wonderful documentation, but if you really need a more in depth explanation check out the Techthrob link below.
Install Secure-Delete with your package manager: apt-get install secure-delete
Resources
For a bit more detail and background check out:
Importing Non-Well Known CA Certificates
A while ago my good friend, Neil Fritz wrote a nice little article describing basic manipulation of SSL certificates in Java keystores. This is one of those things that I do just rarely enough to forget the keytool command options. So, dreading the keytool man page, I'm reposting this article here.
From time to time it may be necessary to integrate with APIs that are served using SSL certificates issued by non-well known CAs. Typically you will encounter a situation like this when a developer has issued a self-signed certificate, or is using a cert issued by a free CA like cacert.org. Java, by default, does not trust these CAs and will not allow you to connect to remote servers that have SSL certificates issued in this manner. The technical reason for this is that there is no clear trust path that can be established when negotiating the SSL connection. When a certificate is received, the signer must be a known and trusted certifcate. The JVM will look at the signer of the certificate presented and climb the chain of trust until it finds a root CA certificate that it trusts. If a trust chain cannot be established, it can be identified by a stack trace containing something similar to:
...
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
...The easiest way to prevent this from occurring is to import the CA certificates into the JVM's cacerts keystore. This keystore is located at JDK_HOME/jre/lib/security/cacerts and can be manipulated using the keytool command.
Listing Certificates
You can view the current list of certificates in a keystore using keytool but the output is somewhat cumbersome to work with. In addition to this, the aliases assigned to the certificates are free-form, so there is no clear convention that we can rely on the easily identify the certificate based on alias. To list the contents of a keystore you do something similar to:
$ keytool -list -keystore cacerts
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 78 entries
digicertassuredidrootca, Jan 7, 2008, trustedCertEntry,
Certificate fingerprint (MD5): 87:CE:0B:7B:2A:0E:49:00:E1:58:71:9B:37:A8:93:72
trustcenterclass2caii, Jan 7, 2008, trustedCertEntry,
Certificate fingerprint (MD5): CE:78:33:5C:59:78:01:6E:18:EA:B9:36:A0:B9:2E:23
thawtepremiumserverca, Dec 2, 2009, trustedCertEntry,
Certificate fingerprint (MD5): A6:6B:60:90:23:9B:3F:2D:BB:98:6F:D6:A7:19:0D:46
swisssignplatinumg2ca, Aug 13, 2008, trustedCertEntry,
Certificate fingerprint (MD5): C9:98:27:77:28:1E:3D:0E:15:3C:84:00:B8:85:03:E6
swisssignsilverg2ca, Aug 13, 2008, trustedCertEntry,
Certificate fingerprint (MD5): E0:06:A1:C9:7D:CF:C9:FC:0D:C0:56:75:96:D8:62:13
thawteserverca, Dec 2, 2009, trustedCertEntry,
...
As you can see, this is not an easy list to search through. But wait, we have the MD5 hashes of the certificates, so we can search on these and be sure that the certificate has been imported to the keystore regardless of the alias used. The MD5 fingerprint can be obtained from the CA certificate using openssl as follows:
$ openssl x509 -noout -md5 -fingerprint -in class3.crt
MD5 Fingerprint=73:3F:35:54:1D:44:C9:E9:5A:4A:EF:51:AD:03:06:B6
We can now use this to grep the output of the certificate list from keytool.
$ keytool -list -keystore cacerts | grep 73:3F:35:54:1D:44:C9:E9:5A:4A:EF:51:AD:03:06:B6
Enter keystore password:
Certificate fingerprint (MD5): 73:3F:35:54:1D:44:C9:E9:5A:4A:EF:51:AD:03:06:B6
In this case, we have verified that the class3.crt has been imported into the cacerts keystore. If the specified fingerprint hash did not exist, no results would be returned by the above command.
Importing a Certificate
To import a certificate into a keystore, you will first need to download the certificate, preferably in PEM format and save it somewhere on your computer. Once you have saved this file, you can import it as follows:
$ keytool -import -alias cacert-root -file /tmp/root.crt -keystore cacerts
Enter keystore password:
Owner: EMAILADDRESS=support@cacert.org, CN=CA Cert Signing Authority, OU=http://www.cacert.org, O=Root CA
Issuer: EMAILADDRESS=support@cacert.org, CN=CA Cert Signing Authority, OU=http://www.cacert.org, O=Root CA
Serial number: 0
Valid from: Sun Mar 30 05:29:49 MST 2003 until: Tue Mar 29 05:29:49 MST 2033
Certificate fingerprints:
MD5: A6:1B:37:5E:39:0D:9C:36:54:EE:BD:20:31:46:1F:6B
SHA1: 13:5C:EC:36:F4:9C:B8:E9:3B:1A:B2:70:CD:80:88:46:76:CE:8F:33
Signature algorithm name: MD5withRSA
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 16 B5 32 1B D4 C7 F3 E0 E6 8E F3 BD D2 B0 3A EE ..2...........:.
0010: B2 39 18 D1 .9..
]
]
#3: ObjectId: 2.16.840.1.113730.1.8 Criticality=false
#4: ObjectId: 2.16.840.1.113730.1.4 Criticality=false
#5: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
[DistributionPoint:
[URIName: https://www.cacert.org/revoke.crl]
]]
#6: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 16 B5 32 1B D4 C7 F3 E0 E6 8E F3 BD D2 B0 3A EE ..2...........:.
0010: B2 39 18 D1 .9..
]
[EMAILADDRESS=support@cacert.org, CN=CA Cert Signing Authority, OU=http://www.cacert.org, O=Root CA]
SerialNumber: [ 00]
]
#7: ObjectId: 2.16.840.1.113730.1.13 Criticality=false
Trust this certificate? [no]: yes
Certificate was added to keystoreThe user input from the above command is highlighted in bold. Basically, what we did was tell Java to import the certificate saved at /tmp/root.crt into the keystore cacerts with the alias cacert-root. When importing this information, you will be asked to enter the password for the keystore, typically, this is the default 'changeit' password. So, in this example we now have the root certificate for cacert.org in the cacerts keystore. Now lets import the class-3 certificate. This will illustrate how the trust chain operates. In the above operation, you can see that the owner and signer were the same. This indicates that the certificate was self signed and is the highest link in the trust chain. The class-3 certificate is itself signed by the root certificate, which now exists in our keystore, so adding the class-3 certificate will no longer require the verification and complex output that the above command produced as the JVM now trusts the signer.
$ keytool -import -alias cacert-class-3 -file class3.crt -keystore cacerts
Enter keystore password:
Certificate was added to keystore
We are still asked for the password for the keystore, but notice that we are not prompted to install the certificate. Since the necessary trust chain can automatically established, this is no longer necessary.
To further illustrate the chained relationship of the certificates used above, we can inspect the signer and issues using openssl.
$ openssl x509 -subject -subject_hash -issuer -issuer_hash -noout -in root.crt
subject= /O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddress=support@cacert.org
5ed36f99
issuer= /O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddress=support@cacert.org
5ed36f99
Now inspecting the class3.crt, we see:
$ openssl x509 -subject -subject_hash -issuer -issuer_hash -noout -in class3.crt
subject= /O=CAcert Inc./OU=http://www.CAcert.org/CN=CAcert Class 3 Root
e5662767
issuer= /O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddress=support@cacert.org
5ed36f99
We can see that the subject and issuer match, as do the hashes, in root.crt, so we have verified that this certificate is self-signed. The class3.crt has a different subject, as would be expected, and the issue and issuer hash match the root's subject and subject hash.