If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Comment

Sure, this would kill the SSD faster, but at least you can trust it. How can you trust the chip inside does the right thing?

in theory a suitable SSD would carry the OPAL TCG sticker, or one of the FIPS accreditations.

however, I seem to remember long ago that Intel had to offer to replace a particular model of SSD because they had bad firmware in it which didn't encrypt the data to the required standard, and due to the way the drive's microcontroller was programmed, it wasn't possible to reprogram it.

Comment

encrypting in the OS onto an SSD is bad practise. if you need disk encryption determine how to use the embedded crypto in an SSD - most have them, it's actually a useful feature so as to achieve the randomisation of data to avoid writing long contiguous 1's or 0's to flash.

what are you talking about? since when does it matter writing long continues 1s (or 0s)?

the only thing where external encryption can affect the liftetime of a ssd is on controlers that do compression. it hinders compression which means that you write more bytes than with compression. in such a case it would be better to first compress and then encrypt which means that the compression must also be dones externally (e.g. by software).

but this has nothing to do with long runs of 1s or 0s. such data is actually extremly good compressable.

maybe i understood you wrong.

Comment

encrypting in the OS onto an SSD is bad practise. if you need disk encryption determine how to use the embedded crypto in an SSD - most have them, it's actually a useful feature so as to achieve the randomisation of data to avoid writing long contiguous 1's or 0's to flash.

if your SSD doesn't allow you to easily control encryption, you bought the wrong one!

My experience is encrypting an SSD or a flash drive works fine and stays reasonablly fast as long as you set aside about a third of it as unallocated space. This makes sure that the controller can find unused blocks to erase. If you don't do this, all cheap flash drives can become very slow once the encrypted partitions have ever been filled. This problem doesn't seem to be as bad on SSDs but they still do slow down when filled in this way.

As for lifespan, for what I do an early wearout is far to be preferred to the consequences of not using encryption. I had a computer stolen by a police raid, I was damned glad that one was encrypted, so this is something I don't compromise on.

I would not trust encryption provided by the drive, since for my work the NSA is the presumed worst-case adversary and hardware back doors into that are likely, just as was the case for ATA security set passwords. There was even a criminal conviction in the US where someone thought their data was protected by setting an ATA disk access password which the FBI was able to quickly bypass with the help of some kind of master key the manufacturer provided.

If you don't encrypt the OS, there are just too many places an attacker with physical access while you are out could drop a keylogger or a replaced binary, as physicall access=root. Encryption is the only thing that can write protect a disk against an attacker booting from something else. When the OS is encrypted too, only the /boot partition can be usefully written to, in what is known as an "evil maid" attack. The /boot partition is a hell of a lot easier to hash check than a whole operating system, so long as you do not mount it after booting and before hash checking.

"Most modern SSDs come with some form of hardware encryption. On these drives with hardware encryption, it?s usually permanently turned on - all data written to the NAND is typically stored in encrypted form. This stems from the fact that all writes to NAND had to be scrambled to begin with (writing long repeated strings of data to NAND can cause problems for data retention)."

Comment

If anyone is to encrypt their data, why not do it the way it's most secure and leaves the least open risks with reasonable effort?

IMO, this excludes the proprietary mechanisms in place in practically all current SSD's that have some sort of built-in encryption functionality. Mostly because the built-in features are almost impossible to enable unless you've bought a corporate laptop or desktop that already has all the required components in it. Secondly, because government controlled backdoors are not fantasy:

Comment

OCZ Vertex 2 is a SandForce SSD, SandForce Chips are slower when data can't be compressed.

So part of the performance hit is the SSD Controller, not the CPU

I do agree encrypting in the OS onto an SSD is bad practise. It ain't ethical to target the controllers.There is a lot that goes into this & there could be some undisclosed SF compatibility issues with the hardware manufacturerers

Comment

If you don't encrypt the OS, there are just too many places an attacker with physical access while you are out could drop a keylogger or a replaced binary, as physicall access=root. Encryption is the only thing that can write protect a disk against an attacker booting from something else. When the OS is encrypted too, only the /boot partition can be usefully written to, in what is known as an "evil maid" attack. The /boot partition is a hell of a lot easier to hash check than a whole operating system, so long as you do not mount it after booting and before hash checking.

If you use a program installed on /boot to hash check /boot you are no better off.

You really need to keep /boot on a USB drive that you always keep with you and boot from that.

Also, a keylogger could be installed into the BIOS or EFI firmware so you need Secure Boot and a TPM to prevent firmware modifications.

And none of that protects against low tech but effective key logger attacks like putting something slightly sticky and UV glowy on the case so you get it on your fingers and then type on the keys. Then they've got your likely passphrase when they bust in and confiscate everything.

Comment

If you use a program installed on /boot to hash check /boot you are no better off.

You really need to keep /boot on a USB drive that you always keep with you and boot from that.

Also, a keylogger could be installed into the BIOS or EFI firmware so you need Secure Boot and a TPM to prevent firmware modifications.

And none of that protects against low tech but effective key logger attacks like putting something slightly sticky and UV glowy on the case so you get it on your fingers and then type on the keys. Then they've got your likely passphrase when they bust in and confiscate everything.

You just can't be too paranoid! :-)

Well, you CAN be so paranoid you assume no defense is possible, so you use none and get on Facebook with Windows and hope the cops raid someone else. Short of that, you structure your setup to put as little trust in your hardware and the environment around it as is necesary to operate it. I've already had one encrypted machine taken in a raid beat attempts by the cops to get into it, I must be doing something right.

Whenever there is a hardware you buy vs open source software choice to be made, go with the software every time. This reduces the number or possible hardware-based attack vectors and increases the odds that your opponent can't get in because the controller of that backdoor can't admit to having it. That last consideration does NOT apply to "Top Secret" but applies to all lower classifications of data.

A TPM is hardware-and a lot more likely the NSA and "Trusted Computing Group" would admit to a backdoor in a TPM in a courtroom than that a motherboard maker would be willing to admit to keylogging all their customers so the FBI can get video of, say, protesters storming a fur shop.

Since /boot is considered easily compromised, a hash check after booting with a program living on encrypted / makes the attack much more difficult, though not impossible. You detect the attack, you change the pasphrase and re-image the OS. Anyone setting up a raid, BTW, will greatly fear the
detection of this sort of preparation, as this means staging a raid where the attackers are expected.

The flash drive approach is good, used it myself in some highly untrusted environments, but it does not protect against the "evil cook" BIOS reflash. Neither does my hash check, but to attack the BIOS requires one visit to determine the board in use, another to change the BIOS, then the harvest raid.

Obviously the ROOM in which a machine is used is an attack vector, a camera is more reliable than glowing UV dust likely to get on every key. Public places, idenify cameras and sit where they can't see the screen. Home and offices, "sweep" the areas from which the keyboard can be seen for cameras. Consider all "smartphones" etc to be malicious, don't let them watch you boot!

One more thing: when they can't get into an encrypted machine, they might offer to give it back. That should ALWAYS be considered malicious, harboring at least a keylogging BIOS. Take it so they can't keep working on it, then SMASH it and throw it in the dumpster.