News Focus
News Focus
Followers 38
Posts 777
Boards Moderated 0
Alias Born 11/30/2003

Re: barge post# 190894

Tuesday, 03/16/2010 7:16:24 PM

Tuesday, March 16, 2010 7:16:24 PM

Post# of 252539
barge, no need to get nasty.

Do you recall what you wrote to Ramsey, and what this discussion is really about? Let me refresh your memory.

"Bashing is not hyperbole in your case. Sorry, but review your posts on the topic. Just because you write in a dense and uncolorful manner does not preclude you from bashing other conceptual frameworks. Let's all try to be respectful! Ty!!!

Anyway, for starts why not review the literature re: mandated encrypted SSDs for the upcoming consumer TPM Netbooks.

Do you think the SSDs will use software or hardware encryption?

And if hardware encrytion do you think Wave has an excellent chance of being in the Google netbook box?
"


Well, I know you didn't ask me, but I will answer anyway...I think it is Linux-based software encryption. Here's why:

>>>
Solution: Encryption

Since Chromium OS is built on Linux, we can leverage existing solutions for encrypting the user's data at the underlying operating system level. Given the available implementation choices, many possible approaches were considered (see Appendix D for details). Of those approaches, we chose a solution that provides file system-level encryption of home directories for each user on a device.
<<<
http://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-user-data

>>>
Appendix D: Designs considered

Per-user block-based encryption: This approach would use a random key to encrypt a partition per-user that is protected by the user's passphrase (and a Google-held backup key). This approach would ensure that a user's data will be accessible only when the user has logged in, and it allows for easy remote wipe (removing the key for the partition). This does add more pain when it comes to device management. Each data partition would need to be separated into preallocated regions for each simultaneously cached user stored on the system (that is, data_space / n = users_space). Note: This should not be visible to the user unless he tries to log in with the new passphrase while he is offline.

Per-user file system-based encryption: This approach would make use of encfs, cryptofs, or ecryptfs to add a layered encrypted file system on top of a preconfigured block device. Barring ecryptfs, the performance is quite painful with userland solutions like encfs and cryptofs. If the kernel-based ecryptfs provided good performance, it would allow for an approach similar to above (guaranteeing per-user privacy and offline defenses) without requiring preallocated block devices per user.

Whole disk encryption with TPM: This would use a TPM-protected key to unlock a drive. This would mean that with the whole device, the data would be exposed to OS-level attacks once booted, unless some form of pre-boot authentication was used. This is not the user experience we are looking for, and this would expose data trivially to a physical attacker. The disk would only be protected if removed from the device.

Whole data partition encryption: This would simplify the space utilization problem by putting all users on one encrypted partition. Normal access controls could keep users out of each other's data, but adding a new user to the encrypted drive without requiring another user to "authorize" the new user at login time is a challenge under this scheme. The reason this is an issue is because each user's passphrase-derived key is used to armor the disk encryption key. Even if a user authorizes another user to access the drive, the new user would be required to type the original passphrase immediately (or at next login), or a secondary key would need to be in play to allow for the encryption key to be decrypted and re-encrypted without the first user present. There are no clean ways around this.
<<<
http://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-user-data

Two Linux encryption tools were benchmarked. They are:

dm-crypt
http://en.wikipedia.org/wiki/Dm-crypt

eCryptfs
http://www.linuxjournal.com/article/9400

Now then, if you have any actual proof that self-encrypting SSDs will be used, please post it.

Otherwise, you might consider apologizing to Ramsey, Doma, and me.

Regards

SL


"RTFM"

Discover What Traders Are Watching

Explore small cap ideas before they hit the headlines.

Join Today