Slashdot Mirror
Intel Launches Self-Encrypting SSD
MojoKid writes: Intel just launched their new SSD 2500 Pro series solid state drive, the follow-up to last year's SSD 1500 Pro series, which targets corporate and small-business clients. The drive shares much of its DNA with some of Intel's consumer-class drives, but the Pro series cranks things up a few notches with support for advanced security and management features, low power states, and an extended management toolset. In terms of performance, the Intel SSD 2500 Pro isn't class-leading in light of many enthusiast-class drives but it's no slouch either. Intel differentiates the 2500 Pro series by adding support for vPro remote-management and hardware-based self-encryption. The 2500 Pro series supports TCG (Trusted Computing Group) Opal 2.0 features and is Microsoft eDrive capable as well. Intel also offers an administration tool for easy management of the drive. With the Intel administration tool, users can reset the PSID (physical presence security ID), though the contents of the drive will be wiped. Sequential reads are rated at up to 540MB/s, sequential writes at up to 480MB/s, with 45K – 80K random read / write IOps.
Got some benchmarks to quote to back that up? AES in hardware is very fast.
Uh, you aren't really comparing equal things. Your post is incredibly stupid.
Self-encryption? So it encrypts itself? Wow. On my laptop I have to encrypt my drive myself. Takes ages to work out all the ciphers
My new device is designed to accept any amount of data and any rate imaginable. Once stored, the data can *never* be retrieved, no matter what is tried. And this new technology is surprising affordable. Call now for your new StorageBrick 3K!
The usual comment, if you care about your drive being able to be unencrypted when the right govt authorities decide to go snooping, it'd be best not to trust this...
Great point of reference:
https://plus.google.com/+Theod...
We all know, at this point, that these tech hardware companies are total butt-fuck buddies with clandestine government organizations.
We all know, at this point, that as a result of the aforementioned butt-fuck buddies relationship, all hardware can be considered compromised before you even open the damn box.
I don't know about you all, but I'm far more concerned that an organization with the power to take away my life and/or freedom can access my data without my permission or knowledge than infamous Russian credit card scammer "Peggy."
That be my 2 pennies.
An enigma, wrapped in a riddle, shrouded in bacon and cheese
Some of the Samsung SSD drives have encryption since 2009. I don't use it because one has to setup the ATA password to enable it, and does not feel as secure. http://www.samsung.com/global/...
... treat it as a regular unencrypted drive and apply proper encryption on top. Next.
Because you said so...? People have been using full disk encryption on normal drives for a very long time now without too much complains for most workloads. Something designed specifically for full disk encryption should have less of an impact.
It can loose it's own keys?
My current Intel SSD encrypts everything and has a special command to wipe the key to 'secure delete' the contents. So I'm not sure what's new here.
This idea is amazing.
Instead of having:
- full control over the encryption software
- full control over the encryption key
- data that goes in clear in the ram, then is never seen in clear by the hard-drive
- performance nearly identical through either hardware-enabled encryption (AES...), or even software based implementations (even a smartphone can do it transparently)
We're trading all this for:
- who knows what really happen down there
- hey, is your secure key even used for anything more than ciphering a header?
- data goes in clear in the ram, then in clear to the drive, that do whatever with it. It's so easy to make sure an SSD doesn't make invisible copy too.
- performance nearly identical through (supposedly) hardware encryption.
Yeah, no, please stop fixing problem that doesn't exist.
Exactly. Mainstream PC SSDs have been self-encrypting for a couple of years now; in Intel's case they've supported full disk encryption since the SSD 320 released in 2011. This is both to allow the easy use of encryption on the end-user side (ATA password), but it also makes it easy to wipe the drive without immediately zeroing out pages, as you have noted.
TRIM don't actually zap the data, it just mark a block as unused. This is to increase performances, because on the next write in this block, there is no need to read it, update it in memory, then write it. But until something is written there, no guarantee that the content itself is erased. Custom firmware could read it, or advanced forensics could get the chips out and get data from it or something.
I suggest encrypting everything multiple times with a more simple encryption algorithm. I find it gives me twice the security at virtually no performance loss whatsoever. Myself, I use ROT13 twice.
If we colonize Mars, it won't be the World Wide Web anymore. UWW?
Probably forced Mcafee scans.
There are two types of people in the world: Those who crave closure
It can probably be interpreted to mean that it shares architecture and/or design patterns of some type. While it's not very specific, I wouldn't call it pure marketing jargon.
Now it's self-encryption. Caveat Emptor, of this self-deceit!
I would presume that TRIM marks the block as unused, so a background erase process can zero it when the drive isn't busy. From what I remember, the main goal of TRIM was to eliminate performance bottlenecks when the SSD had to overwrite previously-used blocks which the operating system had already freed up.
It's the explicit Opal TCG encryption support. There's the internal AES encryption of previous drives, which only protects against yanking the NAND chips out and reading back the data, but not moving the whole drive to a new machine as the controller still knows the key. If I'm not mistaken, the internal AES encryption of SandForce drives is primarily a trick for reducing write amplification rather than any kind of security. Not sure if this new drive actually has the SandForce controller, but that's the difference as I understand it regarding drive encryption.
Yes, TRIM is there to improve performance when writing in a block, but it don't need to erase it, not when receiving the trim command or afterward. The performance problem comes from a write operation that is smaller thn the block. Imagine a block size of 1kB. If you want to write 200 bytes in it, you have to read the whole block, update the relevant part in memory, and write the updated 1kB. Now, if you have the knowledge that the block is completely unused by the FS, then you can skip the reading part, and just write an 1kB chunk of whatever with the correct 200 bytes. No read/update penalty, AND the ssd firmware can decide to reuse that block for transparent wear-leveling, improving both performances and lifetime. But, all this doesn't require actual deletion of the block content at all.
this "new" technology was announced in BYTE mag, some 30+ years ago... then billed as WOM (write-only memory)...
It's a bit worse than that.
You can't write a block without erasing it first.
Most NAND chips don't let you erase a single block (eg: 4k or 8k), you have to erase a group of them (eg: 512k)
To write one block that already contains data, you need to read all blocks in the group first, erase them all and write out all blocks.
Worse case, to write 1 byte, you need to read in 512k, erase it all and write back all 512k. Normal case, you attempt to write entire blocks at a time and the wear leveling algorithm picks an already erased block to write to and leaves the original block intact (and marks it as unused)
First of all this article is nothing more than a giant slashvertisement.
Second of all, essentially every SSD on the market self-encrypts, because it is how the secure wipe feature of SSDs functions. Any SSD that is locked with a password is encrypted and unreadable. This is not a new or novel feature at all, and whoever decided this was newsworthy should not be posting articles to slashdot.
Now, if you have the knowledge that the block is completely unused by the FS, then you can skip the reading part, and just write an 1kB chunk of whatever with the correct 200 bytes.
The cases you describe where a logical sector is only partially written to but luckily the sector was trimmed simply is not a frequent occurrence and even if it were it doesnt pass the smell test because it is the OS that handles writing to partial sectors. The OS always writes complete sectors to a drive (there is no "only write part of a sector" command that HDD's or SSD's understand.)
So even in the case where your scenario were amazingly frequently occurring, the OS would be handling it and not the SSD.
As for your numbers, block sizes are massive on the latest drives. For Intel's 320 series they are 2MB in size.
Also important is that block size is not to be confused with sector size (which is 4KB for the 320 series.)
This is important because READS and WRITES are in sector-sized units while ERASES are in block-sized units. A sector can only be written to once for each erase of the block that contains it.
The drive presents a logical sector layout to the outside world which is different from the physical sector layout. We really only care about the physical sectors for this discussion.
Physical sectors exist in 3 different states:
1) Mapped (contains data important to the logical drive)
2) Unmapped (waiting to be written to)
3) Trimmed (the data within the sector isnt important any more)
The OS isnt the only source of trimmed sectors. Every time the OS writes to a logical sector more than once the old physical sector assigned to that logical sector is marked as trimmed.
The performance benefit of trimmed sectors is that while the drive is idle it can erase blocks that contain only trimmed sectors producing blocks of ready-to-be-written-to unmapped sectors. This is important because erasing a block is the slowest operation a flash chip can do, and there is your performance advantage: As long as you have a pool of unmapped sectors then writes do not wait for erases.
Now dont open your mouth acting like an expert when really you know that you are fucking ignorant.
"His name was James Damore."
It's not big brother, it's anyone. All of the IPMI systems used by Intel, Dell, HP, etc, are unaudited cesspits of remote-rootkit capabilities full of buffer overflows, authorisation bugs, parser errors, and so on. It's hard to know where to begin, but here's one starting point. Hack like it's 1999.
Intel SSD's have had AES encryption built in for years, it's no big deal. What they've added with their IPMI support is a capability for remote attackers to get at the encryption, which is kind of a big deal if you're worried about your privacy.
Can I set my own key? Set and maintain my own hash? No?
Not interested.
We want true, user-controlled security, not vendor provided.
We've learned our lessons already. The trust is gone.
If the drive's software were flashable (the device could be updated with different software) and the software were Free Software, there would be no reason to fear Intel's connection to the NSA. Users would have the freedoms they need to make sure the software does what they want it to do. Proprietary encryption, no matter who writes it or distributes it, is always untrustworthy for the same reason proprietary software is untrustworthy—you don't really know what it's doing and neither does anyone you can trust to help you understand what it's doing. Furthermore you can't make it do what you want and you can't help others by distributing improved versions that respect other user's freedoms.
Digital Citizen
At the bottom of the revealed Pandora's Box of NSA horrors is this: now, even a jury of Red-State yokels have pause for belief when the defense can say to them: planting such evidence is childs' play for the organs of state security - step out of line and you may be next.
Some older drives can use the ATA password for encryption, which is presumably what you are describing. The implementation varies. Some drives store the key in plaintext where it can easily be sniffed as it travels over the the HDD's internal bus. The biggest issue though is that in most cases only laptops support the ATA password feature, with virtually no desktop BIOS implementing it.
This new standard defines how the key is to be stored securely and integrates much better with software like BitLocker. As well as being far more secure than the old ATA password method this allows companies to manage their keys. If the user forgets their password they don't lose access to the entire machine, IT can reset it. The password can be changed without wiping the drive. Hibernation and sleep support is much better too.
The old Intel encryption uses the ATA password, but they have been a bit vague on the details so it isn't know how well it works or how secure it is.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
I have a self encrypting hard drive already.
IBM Deskstar from last decade.
Unfortunately no one has the key....