|01 Mar 2011||#1|
| || |
Encrypted SSD drive...
The SSD drives have started to show up in Enterprises, where one of the requirement is full disk encryption. Full disk encryption means sector by sector encryption, that includes empty places as well.
This didn't sound good from the get go and running couple of tests, prior and after encryption, did confirm that. The system is a Dell laptop, Samsung SATA 2 SSD, running Windows 7 32-bit.
The non-encrypted SSD with AS SSD had this result:
Looks quite alright for a SATA 2 SSD.
HD Tune had similarly alright results:
The drive had been encrypted and the actual process has taken 24 minutes for a 60GBs SSD.
The AS SSD test results dropped like a brick, and understatement according to my wife, after encryption:
This result barely reaches 20% of the unencrypted drive performance and the test has not completed; if you notice the access time is not showing in the second AS SSD test.
The HD Tune test of the encrypted SSD drive was even worse, it didn't even run:
This is the first time I've tested full disk encryption for an SSD drive and it is entirely possible that I've done something wrong. And no, I didn't mean encrypting the drive on the first place was wrong. As stated earlier, this is a laptop for an Enterprise where you don't have much of a choice.
So the question is...
Is it something which is normal with encrypted SSD drives and there are some tuning that can regain close to the original performance?
I'll do some more testing with HDD to see the performance hit with encryption, but I doubt that it'll be this bad.
|My System Specs|
|02 Mar 2011||#2|
| || |
Well, here's the performance of the same drive, encrypted by BitLocker:
Note that the benchmark did complete with BitLocker, which has not been the case with the third-party FDE software.
It seems that BitLocker is "gentler" on the SSD drive, maybe because Windows 7 is SSD aware, but the read/write performance still dropped about 50% when compared to the non-encrypted drive performance. Note that the system seems almost just as snappy speed wise as with no encryption.
I am not sure why the access time is actually less than the non-encrypted drive, but I was consistently getting the same values.
The HD Tune also showed something interesting, next to the fact that it actually ran:
The transfer rate didn't really changed much with BitLocker when compared to the non-encrypted SSD; however, the CPU utilization pretty much doubled.
So it seems that the company will change the FDE solution in place when the migration to Windows 7 will start. Unless someone could explain to me as to why the commercial FDE software performs the way it does.
|My System Specs|
|03 Mar 2011||#3|
| || |
In my own extensive testing for performance of Bitlocker, Ultimaco/Sophos EasyGuard, McAfee Endpoint Encryption, Symantec Endpoint Encryption, Pointsec FDE, and TrueCrypt, I found that only McAfee actually "keeps up" with Bitlocker, performance-wise. They were basically equal in all tests, even though Bitlocker was slightly faster at copying files to and from a Bitlocker-encrypted volume and McAfee seemed to be slightly faster at loading files from a volume (Windows boot, app start, etc). I keep this for any and all of my customers who ask which to use - better management tool interfaces with products like PointSec and McAfee EP, or (much) better performance and AD recovery integration with Bitlocker - it is worth noting that the TPM and Bitlocker are 100% scriptable as well and configurable via Group Policy, although a lot of Windows admins these days lack even those basic scripting skills. Ultimately, some customers choose Bitlocker, some choose others, but at least they can make informed decisions based on what is more important to their organizations.
The encryption algorithm used can have an effect to on encryption performance, so keep that in mind as well when testing - Bitlocker uses AES-128, whereas some of the other products you can use can be configured to use a higher-grade encryption; not entirely necessary in my humble opinion (given the possibility of a cold-boot attack on any drive-encryption system rendering even the most highly-encrypted keys wide open), but depending on security requirements in an organization this may be deemed necessary. Again, I think this is somewhat silly for almost any organization (Bitlocker is FIPS 140-2 certified, and soon to be CC EAL-4 certified), but sometimes the pointy heads and/or tinfoil hats win on this one. The higher the encryption level, the lower the performance, generally, so using AES-128 versus AES-192 or AES-256 will show that using AES-128 is faster.
The other thing that can have an effect is hardware versus software decryption - Bitlocker uses the newer Intel AES-NI acceleration functionality of newer Intel CPUs (westmere and higher, any nehalem released since January 2010 - core i3, i5, and i7; Xeon 56xx and up) to "accelerate" the encryption and decryption of keys, both during boot and while running, whereas most other applications do not offer this functionality - offloading AES decryption and encryption to the CPU when not using the Intel AES-NI instructions is *much* slower. This really can affect performance greatly, and given that McAfee Endpoint Security was the only other major product I tested that also does this, that may explain why it was the only other package to have performance on-par with Bitlocker on my i5-based laptop.
My guess is, whatever software the company is using, it is either configured to use a higher encryption algorithm, or does not support Intel AES-NI (or both!). Unless they're using McAfee EP, the latter is going to be true - the former depends on the configuration they used when deploying it, if the software allows this to be changed at all.
|My System Specs|
|03 Mar 2011||#4|
| || |
Cluberti, thanks for sharing your experience with SSD encryption and for your advise. If you don't mind, I have couple of more questions...
My test laptop also has an i5 M560 Intel CPU that explain the Bitlocker's performance adavantage. Did you get similar performance drop, about 50%, when you've encrypted the SSD with Bitlocker? I didn't reset the SSD drive after the SGN, just ran a Windows 7 installation over the Sophos encrypted drive and encrypted it with Bitlocker. I'll reset the SSD drive and do a fresh install of Windows 7 and throw Bitlocker on it. It would be nice if the performance would improve a bit more. I just cannot see having an SSD drive that acts minimally better than an HDD encrypted drive...
One issue I have with Bitlocker is that it does not integrate with the AD UID/PWD and requires TPM if boot authentication is enabled by policy. While there are ways around if TPM is not available, I'd rather not go that direction. The boot authentication type of TPM + PIN forces a password that is not easy to change, especially for the end user. Third-party products that integrates with AD UID/PWD is more desirable for the end users, it is sort of SSO for the laptop or encrypted drive.
While the recovery keys can be stored in AD, to my recollection, once Bitlocker used as such, it does loose the FIPS 140-2 compliance level. I don't recall at the moment, but Microsoft has released a Bitlocker management software for Beta testing that is intended to address this.
In your experience with HDD/SSD encryption, what do you see being the most popular one?
|My System Specs|
|03 Mar 2011||#5|
| || |
Most people go with Pointsec or Ultimaco actually, because they claim the management tools are best and "bitlocker performance is worse". While I can argue that second point (and have data to back it up - people are usually quite shocked at first, then defensive, then move on to the addmitance stage that their chosen security software just doesn't match up, performance-wise... unless of course they're using McAfee ), I can't argue the first for admins that need pretty graphs and can't write a basic vbscript to manage the TPM (/grrr). This will become less of an argument as well once MBAM (read last paragraph) becomes available, assuming the tool is as good as the others in the MDOP toolset.
As for FIPS compliance, you are correct - one of the requirements for FIPS compliance is broken when you configure a recovery password. It's a technicality, so it is function over security - however, bitlocker itself does pass FIPS compliance, just not when you allow an administrator to recover a system via an AD recovery key. Any system that enables this sort of functionality also fails the FIPS security requirements, and since pretty much all of them do (and customers *want* this), it's a moot point anyway.
Not integrating with the AD user ID/password is more a function of being able to be secure during boot, and keeping the AD database secure as well. The user's username and password hash would have to be stored in the BIOS and/or on the TPM, and while I've seen software from HP that can do this via the BIOS (you configure the pair in the UI in Windows, and it writes it out, with your fingerprint, to the BIOS and needs to be updated whenever your AD password changes) it's not industry-standard in a BIOS or TPM as to how to do that or how to store that. It's the same reason we cannot (yet) use a smartcard natively for pre-auth without an additional driver or special BIOS mod by a hardware vendor - 3rd parties have written this into their security drivers, of course, but it's limited to specific card and reader types in those cases and there is no one set standard yet. Since Microsoft only makes software that runs in a running OS (basically), until there's a hardware-based or BIOS-based standard for this it's not likely we'll see them make this possible.
As to the requirements during boot, I'm a believer that sometimes the user (just like the customer) is just not right - they want security AND convenience, and frankly these are almost *always* diametrically opposed. You move towards one, you lose the other, in both directions, plain and simple. As to Bitlocker's position in all of this, having a pin and using a TPM (6 numeric characters are too hard to remember??? ) is pretty good security, while still being fairly easy to remember and hard to crack without good hardware skills and physical access to the machine (aka, no script kiddies). One of the major reasons that it is a good compromise, in my opinion, is that in practice it should really not be that hard for a user to remember 6 numbers - and that still follows the "something you know, something you have" two-factor auth rule. As to "not going in that direction", the only other direction is use a USB key or don't use a secondary security at all - neither are as easy (or as secure, ultimately) as a simple PIN. I'd suggest getting used to it - it's secure without being onerous, whereas a USB key can be lost (or stolen) and using no PIN is akin to not running encryption at all if you lose the device.
From what I understand, Microsoft Bitlocker Administration and Monitoring is what the new tool will be called, and it will be available as part of MDOP in the future (so, free to licensees with SA on their Windows client licenses).
|My System Specs|
|04 Mar 2011||#6|
| || |
Let's just say that I've been "quite shocked" with the performance test results posted earlier. While I am sold on Bitlocker's performance, I am also quite taken back by the performance hit that encrypting an SSD drive results in. The greater than 50% performance degradation of the encrypted SSD is unacceptable. One could encrypt an HDD drive with Bitlocker, it results around 10% performance degradation, that almost has the same benchmark results as the encrypted SSD drive. While system with SSD encrypted drive still going to be faster than the HDD based counter part, it is mainly due to the access time difference between the two that heavily favors the SSD drive, even if the benchmark results for the actual transfer rate are very similar.
Hardware based drive encryption, or self encrypting drives (SED), could change that sometimes in the near future, without performance degradation. To my knowledge it is only Wave's Embassy software that provides central management for the SED based drives. It manages boot time authentication, which grants access to the SED's encryption keys to access the drive. This is very similar to hard drive password, the BIOS screen to enter the password looks almost the same as well. The OCZ Vertex Pro SSD drive is also an SED, although this is probably a stretch; it relies on BIOS hard drive password to prevent unauthorized access to the drive.
While the SED drive is not full disk encryption, only the data written to the drive is encrypted, in my opinion that is more than sufficient to protect the data on the drive. OCZ is right, there's no reason to cripple the performance of the SSD drive and decrease the life of the drive with the sector-by-sector based hard drive encryption.
Reasonably securing a single laptop is rather easy nowadays for a person with average computer knowledge. Doing the same for thousands of laptops within an Enterprise is a whole different matter. Corporations cannot rely on the end users to secure their laptops and it also requires access to the data in case the end user had been hit by the bus, or for whatever reason. Centrally managing security of the laptops that also provide unlock capabilities therefore a must. The current solutions satisfy corporate requirements, even Bitlocker in AD does minus the FIPS compliance. To my knowledge Utimaco Enterprise Manager is FIPS compliance, but I don't know about PointSec. In either case FIPS is overrated for the corporate world in my opinion, unless the company has business relation with the government. In which case FIPS level of compliance is a requirement.
I may have misstated my position on the TPM + PIN based authentication for Bitlocker, which I am perfectly fine with by the way. My point was that without TPM chip or the correct version of the chip one cannot use TPM + PIN, obviously, and has to rely on USB key for authentication at boot up time. And I was "not going in that direction".
The fact in itself that not all laptops have the TPM chip, or the correct version, prevents rolling out a single solution company wide for laptop protection. Having different solutions in place is not only confusing the end users it is also confusing the support desk. Especially when you currently have a single solution in place that covers all laptop, regardless of the TPM chip.
Your definition of two-factor authentication seems interesting. It's a stretch for sure, but I cannot say that I fully agree with it. The PIN is still a password and having a separate password for the OS is still a single factor, a.k.a. "what you know". I don't see the "what you have" or "what you are" part and I don't believe that the TPM chip would count as "what you have". Not to mention that the alleged two factor isn't actually used within the same authentication window. In the case of Bitlocker the TPM + PIN + USB key would be two factor authentication in my opinion. I could be wrong...
|My System Specs|
|04 Mar 2011||#7|
| || |
It would be interesting to see what a different SSD drive came up with, and if the results were the same. I don't have one on me to test, but it might be something specific with that drive (or the controller's) firmware, I don't know. As to what you know vs what you have, the TPM is definitely what you have, because without that VMK from the TPM the only other way to get at the contents is the recovery key (either in AD or the text file stored on a key or another unencrypted drive), which is also something you have. I would agree that USB+PIN is better (and requires you to "have" both things - the hard disk in the original machine + TPM and the USB key), but that doesn't go over well with most customers (in my experience).
If you do test another drive, let us know the results - it would be interesting to see if it is an SSD-related thing, or perhaps something specific with that drive.
|My System Specs|
|04 Mar 2011||#8|
| || |
The OCZ Vertex 2, and I believe so will the 3, uses Sandforce controller. I have not used this drive; however, SED works on the same way regardless of the type of drive.
During the manufacturing process of the drive a random encryption keys generated and by default, everyone has full access to these keys. Securing these drives requires controlling access to these keys and other than Wave or hard drive password, there aren't many options available at the current time. I've tested an Seagate's SED with the Wave Ambassador software and took some time understanding how it actually works?
The short version is that once the OS is installed, the drive is already encrypted. Not knowing this at the beginning and seeing that encrypting the drive with the software took about five seconds, it did make me wonder if the software does anything. And it does, controls access to the SED's encryption keys.
Performance wise, there had been no performance difference for the tested Seagate SED. In retrospect, that's quite obvious but coming from the software based encryption side does make things confusing.
The chances are that the same drive as HDD, without the encryption overhead, have a performance advantage, in the neighborhood of 10%. I don't see why the SSD based SED would be different, especially if compression is added prior to encryption.
As for the two factor thingy... Yeah, we could argue about that
|My System Specs|
|Similar help and support threads for2: Encrypted SSD drive...|
|When backing up a Bitlocker Encrypted drive I get pop-up...||Backup and Restore|
|Issue with Bitlocker encrypted fixed drive (non OS ) .||System Security|
|New op sys, can't access encrypted ext. hard drive||System Security|
|recovering data from partially encrypted drive||Software|
|BitLocker Encrypted drive not showing anymore||System Security|
|Can't load image from encrypted drive||Software|
|bitlocker encrypted drive||System Security|