Security Musings » data protection

There’s a reason to check security during development

Benjamin Hartley — Mon, 07 May 2012 21:17:55 +0000

During security assessments, I always make sure they’re performing security testing as part of their development process.

This is why: “Apple security blunder exposes Lion login passwords in clear text”

No need to go into details as to what happened here; it’s well-researched in the linked article. However, this is exactly the scenario that development security testing is meant to avoid. A seemingly innocent patch disables or circumvents an important security feature. The results are predictable.

It could be worse, though. Here’s the worst case: the problem isn’t detected. Because the security was included in the original version, and because nobody checked, it is assumed that the security is in place, and successive updates are made, with the security feature in question not working, but everyone assuming it does. And successive patches are built upon the circumvented security. by the time the bug is discovered, fixing it is a gargantuan task.

So, it’s not that bad. It’s still a major breach, though. So if you ever wonder if that testing is really necessary during development, you can point to this incident and confidently say “Yes.”

On the importance of a Safe Harbor

Benjamin Hartley — Thu, 12 Apr 2012 21:40:13 +0000

A service provider shall not be liable for monetary relief, or, except as provided in subsection (j), for injunctive or other equitable relief, for infringement of copyright by reason of the provider’s transmitting, routing, or providing connections for, material through a system or network controlled or operated by or for the service provider, or by reason of the intermediate and transient storage of that material in the course of such transmitting, routing, or providing connections – 17 USC § 512, from the Cornell University Law School

No business is an island. There’s no company that does not, to some extent, rely on other businesses. Business models assume that vendors will be able to assure a steady flow of goods, that retailers will sell goods and pay as contractually bound, that shippers will actually ship goods, etc. Our legal system is filled with assurances to that effect. And this is important, because it gives companies confidence to make such agreements. Knowing that business partners can in fact be bound and trusted to perform their duties, companies can more readily act to grow and increase their revenues. The key component here is confidence – a certainty that once a contract is signed, it will be followed.

That’s what makes the MegaUpload case rather disturbing. There’s no doubt that MegaUpload was hosting infringing content. However, the content was not all infringing – but all of it was taken down. Right now there is a case and the hosting company, Carpathia, is seeking court action which would allow it to release the existing data back to MegaUpload users.

However, in a way, the damage has already been done. Whatever the outcome of the case itself, one message has been sent clearly: your data can be held hostage by others’ data. That’s sure to have a chilling effect on the hosting industry for years to come.

How not to secure your mobile phone.

Tim Donaworth — Thu, 22 Mar 2012 20:22:51 +0000

The following events are based on actual facts and actual events. Names have been changed to protect the oblivious.

I would like to start off by stating that I take no pity on the individual this story is about. I refer to them as oblivious because to do what they did simply can’t be categorized in any other way.

Let’s back up a week. I’ve been in need of another Android device to do some tinkering with, have a backup for my daily driver, and to have something that my son can play with and not fear total destruction (again of the daily driver). After checking with friends and co-workers if they had any spares – they didn’t – I resorted to Ebay. Long story short, I found an LG Optimus S – a rather sturdy little phone for its age for $7 plus $4 shipping. The description said that it did not boot. Being the hacker that I am, I generally don’t let simple statements like that deter me.

A few days later I had the phone in my mailbox. It even included the battery, which I wasn’t expecting. I attempt to boot it up, and as described – it doesn’t boot. I plug it in to ensure it has a charge. It won’t charge. I pull out the voltmeter and quickly determine the battery is junk. Fast-forward two more days after a visit to Amazon (Prime). A new battery is awaiting me in my mailbox. Plug it in, viola, Android magic!

Immediately after boot up I notice the first notification is a voice mail. Seems the user never did reset the device. Being nosey, I check the notification. Something about John borrowing the truck for an extra day. I hope Sam¹ didn’t miss that voice mail. I check the contacts, and once again, it is full of names and addresses of people I’ve never heard of. Popping into the app drawer, I notice that not only does all the user data remain, but so do the apps. At this point I’m ready to simply go ahead and do a hard reset as I have zero interest in any of the previous owner’s old apps or information. But then this catches my eye:

Chase Android App

That’s right, the Chase Banking app. Immediately, my heart sinks. I already start to dread what I presume I’m going to find. I open the app, click the login button, and literally face-palm. Username jxxxxx, Password ********. The user’s login details were saved in the application. I’m now one click away from being in someone else’s bank account. At this point I’m feeling extremely paranoid, and my white-hat mindset kicks in. I pull the battery, put it back in, and proceed to hold the home key, volume down key, and power it into the recovery screen. A couple more volume clicks later, and the device is completely formatted and returned to its factory settings. The old data is wiped.

As I mentioned, I was already fairly certain as to what I was going to find before ever even entering into that Chase app. Why? Most people do not understand the consequences of their actions, especially when it comes to security. Nor do they even consider it when dealing with the majority of technical things they do on a day-to-day basis.

So for those of you wondering, let’s review some of the steps that Sam¹should have taken.

Upon boot up, the device went straight to the launcher. No pin, password, or swipe gesture was required. You should always protect your devices with some sort of locking feature. This is especially true if you have sensitive data stored on your device. If you use your device to access your company email or remotely connect to your company network, this should definitely be part of the company policy. It’s easy to configure within Exchange as well.
The user stored sensitive credentials within apps. Storing your password for something like your gaming account is one thing. Even allowing Android to automatically log into your email is a little risky, but saving the username AND password to your banking application? That’s just asking for trouble. NEVER store credentials in any application that you wouldn’t want someone else having access to! End of story.
The user sold a device (knowingly) without performing a reset or wiping the data. This policy holds true for more than just cell phones. But let’s face it; we are all even more connected to our phones today than ever before. I’d go as far as to say some even use them more than their actual computers (for personal tasks). If/when you sell electronic devices, you should always perform a format, or wipe of all stored data, whether this is a factory reset of a phone, a format and reinstall of a laptop OS, or even a full DoD multiple pass wipe. Always destroy your data before releasing your devices to the public.
The fact that Sam¹even had his banking app on his phone can be viewed as a flaw – but I’ll let that one slide. I personally choose not to keep anything on my devices that can associate me to what my banking information may be. I go even as far as to ensure that any emails I get from my banks are sent to an email address that isn’t associated with my default Android account. Paranoid, perhaps. Secure, you bet!

I will take a slight bit of leniency on Sam¹based solely on the fact that he thought the device was toast. But this is even more reason why you should take the steps necessary to ensure the device is wiped clean before getting rid of it. And for the average Joe (Sam) it’s not always obvious how to do these tasks. I had to look it up myself for this specific device (Android tends to vary the button combination per device). But in this case because the phone wouldn’t boot with the dead battery, Sam wouldn’t have even been able to perform the reset without some other form of digital magic.

Moral of the story: Wipe your devices, lock your devices, and don’t store credentials to sensitive information!

¹Sam is a made up name, unless his name really was Sam, in which case it is purely coincidental.

Smart Phone Security Pointers

Nick Staples — Sat, 17 Dec 2011 02:35:50 +0000

Around this time of year, many people receive new devices and gadgets as gifts, and some of those gadgets turn out to be smart phones. But smart phone security is very tricky to pin down, as there are multiple vendors and platforms to take into consideration, not to mention the speed at which smart phone technology is evolving. So when I came across this Top 10 iPhone Security Tips whitepaper (pdf), I knew that it was probably a good thing that it attempts to target a specific platform. However, after reading through it, I think that many of the things McAfee points out can also apply to a Droid or BlackBerry. And so, by stripping away the platform-specific details, we arrive at a pretty decent list of things a new smart phone owner can do to achieve some basic smartphone security:

Enable passcode/lock

Mobile phones have had passcode capabilities for a long time. Make sure you’re using it, since a passcode lock is often the first line of defense.

Erase all data before a return, repair, or resale

If you will no longer be the owner in possession of the device, it’s best to erase everything you can first. Everything. If you can do a factory reset, do so, because your phone constantly records information and there is always some data that isn’t easily found, let alone purged.

Regularly update firmware

I’m guilty of not doing this– sometimes the update notification will sit around for a week before I finally give it permission to run. But this is one of the easier things to do, since it’s mostly automatic.

Don’t run shady apps

Just like with a personal computer, if you run unknown or untrusted applications, you substantially increase your chances of getting got. So if you don’t want to get got, be prudent about what apps you run on your device.

Take advantage of the web browser’s security

For smartphones with native web browser apps, be sure to use the security features to clear caches and stored passwords when it’s necessary. Just because a web browser is on a mobile device doesn’t mean it’s a security lightweight. Check out the “settings” or “options” to see just how much your mobile phone web browser can do to help you out.

If you’re not using it, disable it

I’m also guilty of leaving stuff running unnecessarily. Be careful about leaving debug mode enabled, Bluetooth and wifi on, etc. Generally speaking, the more doors you leave unlocked, the lighter you sleep at night. Turning off unused services when they aren’t needed is a good habit to form, even outside the realm of security.

Secure that email

In addition to providing native web browser apps, many smartphones also come bundled with a native email app. Check the settings for these apps to take advantage of any security features they’re offering (such as SSL/TLS).

Use a phone tracker

The GPS can be bad for privacy if you are reckless with it. However, it can also be a powerful tool to help you recover a lost/stolen device. I believe the iPhone 4 has a built in device-finding service (complete with a remote wipe). But even if you have a different smartphone, there is almost certainly an app that provides some remote tracking for lost devices (i.e. Where’s My Droid app for Android).

This certainly isn’t a comprehensive list, but it should be enough to get both new and old smartphone users thinking about general mobile device security in a healthy way.

“I think they already know about the mountains, sir.”

Benjamin Hartley — Mon, 31 Oct 2011 21:13:50 +0000

A few years ago, a friend of mine served in Afghanistan. It was, as he described it, a long and mostly dull duty. When not busy with soldierly duties, he wrote on his blog and took pictures, often of the rather picturesque – to those who didn’t have to traverse it – scenery. At one point, however, he was informed that these landscape pictures were, in fact, an operational security violation. Not the ones taken in-camp, but the gorgeous panoramas of Afghani mountains and valleys. The theory was that, using those pictures, insurgents could find their position. My friend’s response was succinct: “I think they already know about the mountains, sir.”

In a previous job, I was charged with creating the security documentation for a particular government system, including the disaster recovery plan. That plan necessarily had to include the power requirements for the system. However, with a certain amount of digging, I discovered that by the standards to which I would be held, the simple fact that the servers used either 110V or 220V power was considered “secure unclassified information” and my report would require rather cumbersome treatment. Mind, what put it over the top was not that the servers required 110V, or that the servers required 220V, but simply that the servers might require one or the other. Or, in other words, that the servers required electricity in the same fashion as every other standard server. The bleedingly, patently, absurdly obvious. But that fact was somehow important for security.

There is a certain tendency, with respect to security, to classify, render confidential, or otherwise obscure every piece of information. I cannot count how many times I have heard “we can’t tell you what kind of encryption we use – that would make it insecure!” or some other variant. Indeed, there is a certain value to hiding some seemingly obvious pieces of information – the number of servers, the ports being used, the location of a datacenter in a building. These are not without purpose. There is no sense in making an intruder’s job any easier, and great value in making it as trudgingly difficult and annoying for them as possible.

But this must be tempered with a modicum of sense. In risk assessment terms, this means examining a piece of information and determining what level of risk it exposes. There is no sense in restricting the fact that servers run off of electricity; an intruder knows that – it’s not something that takes much knowledge to figure out. There’s no sense in hiding the fact that a base which is in contact with the local population can see the mountains – the insurgents know that. These are obvious things.

And there’s an important psychological component there. By trying to secure patently obvious things, security by obscurity (already a bad idea) becomes security of absurdity. The very concept of security becomes eroded. Yes, it’s easier to treat all information as secure, but the end users won’t view it that way. What they’ll see – correctly – is a security posture which has gone amok and which is not connected to the reality of their work. And they’ll start ignoring it because it’s ridiculous. And then they’ll be ignoring actually sensible security; they’ve lost confidence in the directives and the purpose behind them. And then you have a problem.

The point is to maintain a real connection with the people who have to implement security directives. As I’ve said before, their job is not to keep your infrastructure secure – their job is, well, their job. To keep people following secure processes, they have to be invested. They have to be able to understand why they’re doing these things. You have to acknowledge that they know the mountains are there, and work within that reality.

The Digital Underground

Nick Staples — Sat, 08 Oct 2011 02:56:38 +0000

A lot of what we security professionals do includes protecting information from being compromised (especially personal information). The shift towards more profit-driven computer crime has happened swiftly over the last decade, so it should come as no surprise that there is a booming underground market centered almost entirely around compromised financial and personal data. And, on the other end of the spectrum, we have laws and regulations to help minimize the leakage of this data in the first place. Plenty of research and documentation exists for the many ways we try to protect information, but there isn’t much (public) info on the underground market populated by the attackers and their associates who trade in illegally-gotten information. So, how do someone’s bank account credentials grease the wheels of this unique ecosystem?

The Underground Economy: Priceless (pdf) touches on the subject in a great amount of detail, even explaining the importance of reputation and the lengths people take to avoid prosecution.

Essentially, public and private servers host communities of individuals who offer their services for a fee. Maybe one person will help someone else cash out an entire bank account (for a 50% cut). And maybe another person will deliver ill-purchased goods to a safe location (for a 30% stake). In the mix are also those who initially did the work (or wrote the code) to capture the information, as well as people who specialize in forging IDs, curious researchers, law enforcement… the list goes on. Compromised financial data seems to lead to a very deep chain of events that attracts many people with varying skillsets, most of whom are simply offering to perform the same hustle(s) over and over. It is a system where both information and skills are bartered/exchanged and high risk is accepted for high returns on investment.

But not all participants are highly skilled– there should be some low-hanging fruit in there too, right? Surely, there are people who aren’t as cautious or who miscalculate their risk of exposure, yet we still have trouble keeping up with even a fraction of the online fraud. While I’m glad we are focusing efforts on preventing information from being compromised in the first place, I feel like there is a growing opportunity to focus a lot more research on thwarting these high-risk behaviors directly. Sometimes you have to treat both the symptom and the cause.

Removing Trusted Certificates from Android

Tim Donaworth — Thu, 15 Sep 2011 15:22:55 +0000

In light of all the discussions about maintaining a secure posture on trusted certificates, we oftentimes forget about the little guys. In this case, I’m talking about our mobile devices. We tend to forget that these devices are just as vulnerable as our desktop/laptops. Unfortunately, it’s not always easy to manage the certificates on these devices. But if you own an Android device and would like to take a little more control over what your device is trusting, here’s how you can do it.

Remove a CA Cert from Android System
The bouncycastle library will be required, you can grab it here:
BouncyCastle Library

You’ll need the Android-SDK as well in order to utilize ADB. It can be found here if you don’t already have it:
Android SDK

Move the jar into the $JAVA_HOME%\lib\ext folder. It’s most likely in a place like this:
```
C:\Program Files (x86)\Java\jre6\lib\ext\
```
Connect your USB cable to your phone and verify with adb that it is seen as attached. [%android-sdk% is the location of the Android SDK installed on your system]
```
%android-sdk%\tools> adb devices
```

You’ll need to grab the cacerts.bks file from your phone using adb:

%android-sdk%\tools>adb pull /system/etc/security/

cacerts.bks cacerts.bks

Now let’s extract the cacerts.bks to a human readable format (there are other ways of reading bks files, but this is an easy route)

%android-sdk%\tools>"%JAVA_HOME%\keytool.exe" -keystore

cacerts.bks -storetype BKS -provider org.bouncycastle.jce

.provider.BouncyCastleProvider -storepass changeit -v

-list > calist.txt

Open the newly created calist.txt file and search for the desired CA Cert ( DigiNotar CA in our case). You’ll want to identify the alias name number. You’ll use this to identify the certificate so that you can remove it with keytool.exe:

*******************************************
Alias name: 61

Creation date: Feb 8, 2011

Entry type: trustedCertEntry

Owner: C=NL,O=DigiNotar,CN=DigiNotar Root CA,E=info@diginotar.nl

Issuer: C=NL,O=DigiNotar,CN=DigiNotar Root CA,E=info@diginotar.nl

Serial number: c76da9c910c4e2c9efe15d058933c4c

Valid from: Wed May 16 17:19:36 UTC 2007

until: Mon Mar 31 18:19:21 UTC 2025

Certificate fingerprints:

MD5:  7A:79:54:4D:07:92:3B:5B:FF:41:F0:0E:C7:39:A2:98

SHA1: C0:60:ED:44:CB:D8:81:BD:0E:F8:6C:0B:A2:87:DD:CF:81:67:47:8C

Signature algorithm name: SHA1WithRSAEncryption

Version: 3
*******************************************

%android-sdk%\tools>"%JAVA_HOME%\bin\keytool.exe" -keystore

cacerts.bks -storetype BKS -provider org.bouncycastle.jce.

provider.BouncyCastleProvider -storepass changeit -v -delete

-alias

For example:

%android-sdk%\tools>"%JAVA_HOME%\bin\keytool.exe" -keystore

cacerts.bks -storetype BKS -provider org.bouncycastle.jce

.provider.BouncyCastleProvider -storepass changeit -v

-delete -alias 61

You’ll probably want to repeat this process for the Comodo certificates as well if you’re really security minded (of course you are).

Once you’ve removed the certificate you can push the cacerts.bks back to your phone for usage:

%android-sdk%\tools>adb remount

%android-sdk%\tools>adb push cacert.bks /system/etc/security/

The final step will require you to reboot your phone so that Android can reload the cacerts.bks.
Enjoy!

If you have root access and don’t feel like going through ADB and all the SDK installation, the GuardianProject has created an Android app (CACertMan) that is targeted at doing the above for you and letting you manage your certs yourself. You can check it out here. It is still in beta and isn’t 100% compatible yet, hence the manual instructions above.

Certification Authorities Behaving Badly

Peter Hesse — Tue, 30 Aug 2011 14:59:06 +0000

edited September 2 with an update on Apple/Safari.

Another case of a certification authority (CA) issuing a certificate they never should have has surfaced. You may remember when we discussed the Comodo incident earlier this year. Now, a certificate issued by DigiNotar has surfaced in the wild, being valid for *.google.com – meaning it could be used to secure any transaction with any Google web property, including GMail. According to this pastebin post, this certificate “is being used in the wild against real people in Iran *right* now.” DigiNotar has issued a statement. Here is some information about why this is bad, and what steps you should take to remove this issuer from your trust lists.

What does this mean?

SSL, or TLS, is used to perform two things. First, it provides authentication of the web server to the web browser. (It can optionally provide authentication of the browser to the server, too, but that’s less common.) This means that the web browser knows that it is talking to a trusted web server and can share sensitive information with it. Second, it provides transport-layer encryption, so that the communications between the web browser and the web server are encrypted. This means that other parties cannot read what is being sent between the server and browser. This is widely used for most logins, because you don’t want your username and password being sent to the server “in the clear”. Anything sent “in the clear” can be read by anyone else on your network (or within range of your wireless network), or by anyone on any network that your traffic is routed through between you and the server.

In this case, a fraudulent certificate has been issued for *.google.com by a certification authority which is completely trusted by most modern web browsers. This means that the web browser will see this certificate, consider it valid for all traffic with Google (and GMail), and go ahead and create that little lock icon everyone has been trained to look for, which indicates your communication is secure.

Except, it’s not.

Google does not own this certificate. Google did not pay for this certificate. Therefore, when you communicate using this certificate, it’s not with Google. It’s with whoever managed to get that certificate issued, which according to the pastebin, is by groups wishing to do harm to individuals in Iran.

Personally, I don’t want to take a chance on whether it might be used against me, as well.

What should I do about it?

It is my opinion that issuance of a certificate such as this is an unforgivable sin. Certification authorities must have the appropriate technical controls, and checks and balances, to prevent this from ever happening. There are plenty of certification authorities out there, and it is time to remove this one from my system and all systems I manage.

The good news is that the browser manufacturers also think this is a bad thing and are rushing to put together information on how to ensure you won’t trust this certificate.

Mozilla is updating Firefox, Seamonkey, Thunderbird, and others to remove this; they also provide a link for manual removal.
Apple hasn’t stepped up with information about it yet that I can find. If you’re running a Mac OSX machine, you should set your system to never trust the Diginotar certificate. Run Keychain Access, and on the left choose your “login” keychain. Down below, choose “All Items”. Then in the search box, search for DigiNotar. You should see one or two results for DigiNotar Root CA. Double-click it. Expand the Trust arrow, and where it says “When using this certificate:” choose Never Trust. Close the window and you will likely be prompted to enter your password to update the login keychain. Repeat for all occurrences of DigiNotar certificates. Update: It’s worse than I thought. This method does not work for EVSSL certificates in Safari. See this link for more information. Stay tuned for any updates Apple might make about this, a patch to Safari is probably necessary.
Microsoft tells you you’re protected if you’re running Vista or later. If you’re not and still running XP or Windows 2000/2003, you should remove the certificate manually. The easiest way to do this is to launch Internet Explorer, and choose Tools->Internet Options. (Or just launch “Internet Options” from your control panel.) Go to the Content tab and click the Certificates button. Click the Trusted Root Certification Authorities tab. Find the DigiNotar Root CA and double-click it. (If it’s not there, you’re safe!) Click the Details tab and click the Edit Properties… button. Choose Disable all purposes for this certificate and click OK.
Google Chrome users, you will benefit from the rapid updates to Chrome which will mark DigiNotar as untrusted. You can (should?) also take the Apple or Microsoft manual removal steps above to be sure you’re safe.

Additional good commentary (as always) from Moxie Marlinspike and Jacob Appelbaum.

Apricorn Aegis Padlock Review

Laura Raderman — Mon, 15 Aug 2011 12:46:48 +0000

Disclaimer: I requested and received an evaluation version of the Apricorn Aegis Padlock. I was sent the 250GB AES-256 version, and I need to return it to the company in 30 days.

This is a pretty sweet hard drive, but there are a few annoyances that I think can be improved upon. I was unable to test a few things just due to the time I could devote to this, the fact that I need to return the drive in working condition, and that I don’t have access to some specialized hardware to test timing attacks.

The drive is FIPS 197 validated – aka, uses AES according to NIST.

You can check out Apricorn’s site for the specs and details, but what you see on the product site is pretty much what you get. The drive draws power from your USB port, so you’ll need a powered port. The drive came with an adapter (1 USB to 2 USB) if one of your USB ports doesn’t provide enough power. I had no issues with power on my MacBook Air, but I did on my office desktop since all USB ports were already taken – easily solved with a powered USB hub.

The drive comes formatted for Windows, but my mac helpfully formatted it for me once I said “yes” to “Use this as a Time Machine drive?” The quick start sheet in the box also provides Mac formatting instructions. The actual manual is already on the drive, and my mac helpfully erased it for me during formatting. However, the “Support” section of the website has the full manual available for download. At first, you really want to have the full manual available (and not on the drive).

The drive has the capability to have an administrator PIN and up to 9 “user” PINs. Knowledge of the admin PIN can wipe the user PINs, but not change them – only users can change their PINs. The different PINs do not allow access to different parts of the drive. All PINs have access to the entire drive. PINs can be anywhere between 6 and 16 digits, the default admin PIN is 123456 and there are no user PINs. There is “drive wipe” protection, but it’s pretty lame, and wouldn’t meet most corporate policies (complaint #1). After 6 invalid PIN attempts, the drive needs to be unplugged before you can try 6 more attempts. Once you’ve gotten to 50 attempts, you have to type in a (hardcoded) PIN to try 50 more times (you still have to unplug every 6 tries). Only after 100 total attempts will the drive “wipe” itself. Given how long the wipe took during this testing, it’s probably only wiping the keys, not the whole drive (but the manual doesn’t say this is the case). While annoying, certainly not insurmountable for someone who’s really determined, but a brute force for a 6 digit PIN (the minimum) is 10^6 – well over 100, so unless the attacker has some prior knowledge, the drive will likely wipe first.

Basic operation is plug in drive, enter a valid PIN (user or admin) and the drive mounts – decrypted. When you’re done, unmount the drive from your OS, and unplug the drive. Until you unplug the drive, the data is still decrypted (complaint #2).

The administrative “interface” works, but it’s pretty complicated – hence my suggestion to keep the manual handy until you’ve got the hang of it. All commands are sent using a keypress combination or sequence. Granted, the primary interface is a keypad with a “cancel” and a lock icon in addition to the 10 digits, and you’re limited a bit. I had some trouble creating user PINs, but it seemed intermittent, so I blame it on user error instead of anything the drive did (or didn’t do).

If you forget your PINs, you’re SOL (which is as it should be – in most cases). You can reset the drive back to factory settings – again, the “wipe” is just a wipe of the keys and partition table based on the time it took. This is great for most uses, but I can see corporate folks leery about this because if a user forgets their PIN (or tries to reset their drive themselves), the company’s just lost a lot of data. The admin PIN is supposed to protect against that and as long as help desk/etc. keep that PIN, they’re safe from all but others resetting the drive.

The keypad is supposed to be wear resistant – but in the two weeks I had the drive, I can’t test that, but it feels sturdy, and the digits seem to be embedded in the rubbery keys.

The casing appears sturdy and no obvious screws (they’re probably under the rubber feet), but since I have to return it in working condition, I didn’t try too hard to break the case. There is no special padding or ruggedness to the case that you wouldn’t see in an unencrypted external drive case. However, the product page claims some protection from drops (I’ve found that most external drives can handle a small drop).

There’s also VTC (Variable Time Circuit) technology, which I’ve never heard of, but apparently helps to thwart timing attacks – again, not something I can test, because I don’t have the equipment (or time).

It’s pretty easy to use, and I used it almost daily for two weeks – mostly for play, since I don’t have a real need for external drives (except Time Machine). The drive is on my wish list, but until I get my house sold, we’re on a spending moratorium at home. It’s really not that expensive relative to unencrypted drives – the AES-256 250GB drive is listed at $109. There’s a 3 year warranty on the drive, which covers the drive and the casing.

The drive’s a bit slower than your typical external drive, but I expected that. An initial Time Machine backup of 198GB took 4.5 hours. I was using the computer while it was backing up, so that could have impacted the performance. For most uses, you won’t notice much of a difference – unless you’re moving a *lot* of data that has to be encrypted on the drive.

There are a few annoyances, but they’re really just annoyances.

1: Having to unplug the drive to lock it. There’s already a cancel button, why not use that for a “lock” button. As long as the drive is receiving power – say, while the computer has the screensaver turned on, the drive remains decrypted. Now, someone can’t easily read the drive if the screen is locked, but if someone doesn’t lock their screen? It’s available. There’s also no “timeout”. I can see why – as long as the OS has the drive mounted, it could be in use. I wonder if it’s possible for the drive to detect that it’s been unmounted and lock itself after a pre-determined time.

2: It’d be nice to have a configurable wipe after X attempts capability – or at least wipe after 10-15 attempts, which would cover most corporate policies.

3: I would love to see a Kensington style laptop lock on the drive case. The data may be protected if someone steals the drive, but it’s annoying. As I can see this drive going along to the library/coffee shop/etc. with the laptop, it’d be nice if there were some physical way to lock the drive either to the table or to the laptop. You should never leave your laptop/data/”stuff” unattended in public places, but a lot of people do it.

Encrypt your portable devices

Benjamin Hartley — Thu, 04 Aug 2011 20:45:47 +0000

I just recently bought a new netbook. Now, I know that netbooks are supposedly on the way out, but I love the low price, long battery life, and massive portability. But there’s a problem with netbooks and security. They’re massively portable – whether the person doing the porting is me or a thief. I do my best to keep my netbook safe, but being realistic I’ll admit that it could happen.

Now, the biggest loss from someone stealing my netbook is in data; the hardware really isn’t all that expensive. My netbook doesn’t just contain personal information; it’s also full of important business data. I can and do perform regular backups to make sure I don’t lose any of the data, but I don’t want anyone else reading what I’ve got, either.

That’s where file encryption comes in. If properly encrypted, my data won’t be accessible even if someone has the hard drive. So, with that in mind, I’m looking at three different utilities for encrypting my drive:

TrueCrypt – TrueCrypt is kind of the grand-daddy of Whole Disk Encryption; it’s currently on release 7. Being free for download, it’s rather popular. It offers a range of features, including the ability to perform whole disk encryption, and the ability to create hidden volumes and hidden operating systems, meaning that even if you’re compelled to divulge passwords, your attacker won’t know about these volumes and thus won’t know to get access to them. In addition, TrueCrypt comes with a pretty impressive set of encryption algorithms, including AES-256.

AxCrypt – Another piece of freeware, AxCrypt doesn’t offer quite as much as TrueCrypt. Unlike TrueCrypt, AxCrypt exists for encrypting files and doesn’t have a whole disk option. Also, it’s limited to AES-128 which is not bad but certainly not as secure as 256. It seems to have a bit more open UI, however, letting users execute scripts on it. It’s also more oriented toward online shares and network storage – so if you want to put encrypted files on online repositories, AxCrypt may be the one for you.

PGP – The third tool I’ve been looking at is Symantec’s PGP. Unlike the other two, PGP costs – roughly 90USD per license. What do you get for $90? Well, it looks like it’s not a bad piece of software. As with TrueCrypt, Whole Disk Encryption is an option. It also has centralized management options, so it seems the best of the three for large-scale implementations. In addition, it has a host of certifications, notably FIPS 140-2 compliance. If you’re in an environment where that’s required, this is likely the way to go. While the online information is not immediately forthcoming on encryption algorithms, FIPS-140-2 compliance means that at minimum it offers AES-128.

For my purposes, I’m likely going to use TrueCrypt. AxCrypt and PGP both have their place. But the most important thing? Implement something. It’s easy to put off such a step, but you never know when your mobile device might be lost or stolen.