That's not true, nothing is written to the disk without being encrypted first. If what you say is true, the same problem would exist on a spinning disk too. Filevault (pre-Lion) is simply an encrypted disk image, where any data is encrypted before it is actually written to a disk (SSD, HDD, whichever). Any fragments of the FileVault image are encrypted, and thus useless without the key.
Hi Elijaha, I agree and disagree at the same time. As you know, FileVault implementation has evolved with each edition of OS X. With 10.6, enabling File Vault automatically enables "Use Secure Virtual Memory;" so, in theory, a user's files and any temporary files and caches are encrypted when written to disk. The same principle extends to 10.5 & 10.4, but using secure virtual memory needs to be manually set (hopefully not forgotten).
The overriding problem relates to data leakage -- data that should live in the encrypted envelop doesn't always behave or stay that way. This extends to both SSD and HDDs (ssds add a wrinkle). For instance, some third party programmes don't wholly follow storing all user-related files within the home folder; or, an uninitiated user might store files outside their home folder. On the Apple side of the ledger, OS X stores WebKit - related caches outside a user's encrypted home folder.
It sounds like Lion is going to be good news all round -- hopefully leveraging Intel?s evolving hardware-based AES encryption acceleration.
Filevault in Lion shares only the name. It's a different process entirely that has everything encrypted. Of course, when you have unencrypted your data (whether at boot with Lion, or Login with Leopard) then naturally your data is unencrypted and available by the user there is simply no way around this unless you encrypt each of your files with a different password. That's the nature of actually using a machine, you can have it secured when you turn it off for if it gets stolen etc, but when it use, well you know, it's there to use...much like you cannot encrypt your screen so only you can see it. Good user practice is all that's required, password on screensaver, locking your screen or putting into sleep with password on wake etc when you walk away from it etc etc.
Hi Stuffe, You're so right, user education is tops, paying particular attention to those users who hear "encryption," think invincibility, and develop complacency.
You're actually incorrect about file vault and needing to logout. Apple has finally got rid of the fake security of your screensaver or sleep password app, and uses the loginwindow process to let you back in after screensaver runs. Apple has asked many of my friends in security consulting to bang on OS X Lion right now. Also they have one of the top security experts for Unix hired away last year work on Lion.
SSD in 10.7 has trim support, before that most people have intel SSDs which DO NOT support trim in the first place.
I just want to point out that security in 10.7 is serious this time. I have a job where one of my machines is forced to use a special RFID hard disk key to unencrypt the disk, as well as use software whole disk encryption like true crypt. I'm using 10.7 on a test notebook (11" SSD macbook air, and file vault is extremely fast)
That's great news. Speedy encryption transparent to the user. You're right. The first gen Intel SSDs don't support TRIM, as don't most of its competing drives. The second gen Intel drives do (denoted G2). For those drives without TRIM support, most manufacturers released a tailored programme to invoke a firmware command to the controller to erase its file table. On the Mac front, little is known about Apple-branded SSD controllers and firmware and I know of no such utility for their Toshiba controllers. One consequence is that any existing user data on the drive that's moved into a FileVault user folder is now indeed part of the encrypted vessel but the original unencrypted instance remains on the drive and sits, and sits, and sits until the controller sees fit to overwrite it. Naturally, garbage collection would help mitigate the problem by clearing and consolidating pages and blocks. The recent Sandforce-based controllers initiate their own block optimizations, which keeps them running lean-and-mean longer but they're not a BTO option. Perhaps you have first hand insight but from what I've read there's still a question mark whether Lion's TRIM support will extend to non Apple-branded SSDs. Have you come across anything saying Yea or Nay to third-party SSD support?
Thanks for the heads-up on the log-in routine. I'm on my way to dig in.
David Rice sounds like a great hire for Apple -- a CV with lots of cloak and dagger listings, government and private sector experience -- and hopefully he's a thrust to improve Apple's public discourse on security. Security by obscurity only goes so far; then, it bites you in the PDF.
On the crypto front, I prefer my salt open source. I like code that's been hammered by skilled people with every imaginable kind of motivation. Proprietary stuff doesn't pass my tin foil hat test, particularly when government and business work hand in hand. When the resources of the NSA -- which extols, "We don't measure computer power by the gigahertz, we measure it by the acre" -- meet the opacity of proprietary code in the business sector, the chance of a backdoor is wonderfully ripe. Unfortunately for now, TrueCrypt on OS X is still a work in progress.
No doubt your friends are hammering Lion hard. And I hope their friends are hammering, too... Who in turn are joined by their friends, and their friends, and so on, and so on... The more hammers, the greater the breadth of skill, the higher the creativity, the better the cat will be.
Parenthetically, you may have already seen it but there's a good article and research paper at Ars on SSD data cleansing. It joins the chorus on the mounting technical puzzle to managing non-magnetically stored data. Data forensics is in a real pickle. The courts are in for a real treat.
The overriding problem relates to data leakage -- data that should live in the encrypted envelop doesn't always behave or stay that way.
Lots of programs retain the Unix convention of using /tmp for scratch files rather than OSX's convention of using ~/Library/Caches/<Program>, which as you note in 10.6 and earlier FileVault causes leaking of unencrypted data.
One thing I haven't heard about is whether 10.7 FileVault is hardware accelerated; that is, does it use Nehalem's new AES-NI instructions? I am also disappointed that 10.7 FileVault only uses 128-bit keys, seeing as 10.6 encrypted sparseimages can use 256-bit keys.
1. How does Lion full disk encryption work with bootcamp?
(e.g. does it encrypt the bootcamp partition? If it does, is there a seperate password to access that space? In a multi-user setup, is bootcamp partition access given to a single user or all users?)
2. Does full disk encryption in Lion preclude the use of an OS X guest account?
Normally I would assume full disk encryption would preclude the use of a guest from using the computer (because you wouldn't want to give the guest a password that unlocks the whole disk), but since this encryption method is integrated into the OS I wonder whether Apple have built in a solution to accessing the guest account.
My son's computer screen crapped out and I took it in for repair. Normally I would wipe the disk. But with no screen I wasn't able to do so this time. The tech ask for an account password, I reluctantly gave it to him knowing there's no exploitable data on my son's computer.
If it had been a shared computer, I'd have been confident that if the tech gained root privilege, he could only access my user Filevault by maybe he resetting my account password (not certain of this, but a layman's take). Which I would be able to detect.
With Lion, if I had to give a tech a standard account access (not being able to pre-wipe the disk) and he gained root privilege, he may be able to access other account data through file permissions alone. This would not be detectable.
Comments
That's not true, nothing is written to the disk without being encrypted first. If what you say is true, the same problem would exist on a spinning disk too. Filevault (pre-Lion) is simply an encrypted disk image, where any data is encrypted before it is actually written to a disk (SSD, HDD, whichever). Any fragments of the FileVault image are encrypted, and thus useless without the key.
Hi Elijaha, I agree and disagree at the same time. As you know, FileVault implementation has evolved with each edition of OS X. With 10.6, enabling File Vault automatically enables "Use Secure Virtual Memory;" so, in theory, a user's files and any temporary files and caches are encrypted when written to disk. The same principle extends to 10.5 & 10.4, but using secure virtual memory needs to be manually set (hopefully not forgotten).
The overriding problem relates to data leakage -- data that should live in the encrypted envelop doesn't always behave or stay that way. This extends to both SSD and HDDs (ssds add a wrinkle). For instance, some third party programmes don't wholly follow storing all user-related files within the home folder; or, an uninitiated user might store files outside their home folder. On the Apple side of the ledger, OS X stores WebKit - related caches outside a user's encrypted home folder.
It sounds like Lion is going to be good news all round -- hopefully leveraging Intel?s evolving hardware-based AES encryption acceleration.
Filevault in Lion shares only the name. It's a different process entirely that has everything encrypted. Of course, when you have unencrypted your data (whether at boot with Lion, or Login with Leopard) then naturally your data is unencrypted and available by the user there is simply no way around this unless you encrypt each of your files with a different password. That's the nature of actually using a machine, you can have it secured when you turn it off for if it gets stolen etc, but when it use, well you know, it's there to use...much like you cannot encrypt your screen so only you can see it. Good user practice is all that's required, password on screensaver, locking your screen or putting into sleep with password on wake etc when you walk away from it etc etc.
Hi Stuffe, You're so right, user education is tops, paying particular attention to those users who hear "encryption," think invincibility, and develop complacency.
PeterO:
You're actually incorrect about file vault and needing to logout. Apple has finally got rid of the fake security of your screensaver or sleep password app, and uses the loginwindow process to let you back in after screensaver runs. Apple has asked many of my friends in security consulting to bang on OS X Lion right now. Also they have one of the top security experts for Unix hired away last year work on Lion.
SSD in 10.7 has trim support, before that most people have intel SSDs which DO NOT support trim in the first place.
I just want to point out that security in 10.7 is serious this time. I have a job where one of my machines is forced to use a special RFID hard disk key to unencrypt the disk, as well as use software whole disk encryption like true crypt. I'm using 10.7 on a test notebook (11" SSD macbook air, and file vault is extremely fast)
That's great news. Speedy encryption transparent to the user. You're right. The first gen Intel SSDs don't support TRIM, as don't most of its competing drives. The second gen Intel drives do (denoted G2). For those drives without TRIM support, most manufacturers released a tailored programme to invoke a firmware command to the controller to erase its file table. On the Mac front, little is known about Apple-branded SSD controllers and firmware and I know of no such utility for their Toshiba controllers. One consequence is that any existing user data on the drive that's moved into a FileVault user folder is now indeed part of the encrypted vessel but the original unencrypted instance remains on the drive and sits, and sits, and sits until the controller sees fit to overwrite it. Naturally, garbage collection would help mitigate the problem by clearing and consolidating pages and blocks. The recent Sandforce-based controllers initiate their own block optimizations, which keeps them running lean-and-mean longer but they're not a BTO option. Perhaps you have first hand insight but from what I've read there's still a question mark whether Lion's TRIM support will extend to non Apple-branded SSDs. Have you come across anything saying Yea or Nay to third-party SSD support?
Thanks for the heads-up on the log-in routine. I'm on my way to dig in.
David Rice sounds like a great hire for Apple -- a CV with lots of cloak and dagger listings, government and private sector experience -- and hopefully he's a thrust to improve Apple's public discourse on security. Security by obscurity only goes so far; then, it bites you in the PDF.
On the crypto front, I prefer my salt open source. I like code that's been hammered by skilled people with every imaginable kind of motivation. Proprietary stuff doesn't pass my tin foil hat test, particularly when government and business work hand in hand. When the resources of the NSA -- which extols, "We don't measure computer power by the gigahertz, we measure it by the acre" -- meet the opacity of proprietary code in the business sector, the chance of a backdoor is wonderfully ripe. Unfortunately for now, TrueCrypt on OS X is still a work in progress.
No doubt your friends are hammering Lion hard. And I hope their friends are hammering, too... Who in turn are joined by their friends, and their friends, and so on, and so on... The more hammers, the greater the breadth of skill, the higher the creativity, the better the cat will be.
Parenthetically, you may have already seen it but there's a good article and research paper at Ars on SSD data cleansing. It joins the chorus on the mounting technical puzzle to managing non-magnetically stored data. Data forensics is in a real pickle. The courts are in for a real treat.
http://arstechnica.com/ask-ars/2011/...1#comments-bar
The overriding problem relates to data leakage -- data that should live in the encrypted envelop doesn't always behave or stay that way.
Lots of programs retain the Unix convention of using /tmp for scratch files rather than OSX's convention of using ~/Library/Caches/<Program>, which as you note in 10.6 and earlier FileVault causes leaking of unencrypted data.
One thing I haven't heard about is whether 10.7 FileVault is hardware accelerated; that is, does it use Nehalem's new AES-NI instructions? I am also disappointed that 10.7 FileVault only uses 128-bit keys, seeing as 10.6 encrypted sparseimages can use 256-bit keys.
1. How does Lion full disk encryption work with bootcamp?
(e.g. does it encrypt the bootcamp partition? If it does, is there a seperate password to access that space? In a multi-user setup, is bootcamp partition access given to a single user or all users?)
2. Does full disk encryption in Lion preclude the use of an OS X guest account?
Normally I would assume full disk encryption would preclude the use of a guest from using the computer (because you wouldn't want to give the guest a password that unlocks the whole disk), but since this encryption method is integrated into the OS I wonder whether Apple have built in a solution to accessing the guest account.
I'm interested to know:
2. Does full disk encryption in Lion preclude the use of an OS X guest account?...
My concern is similar to #2.
My son's computer screen crapped out and I took it in for repair. Normally I would wipe the disk. But with no screen I wasn't able to do so this time. The tech ask for an account password, I reluctantly gave it to him knowing there's no exploitable data on my son's computer.
If it had been a shared computer, I'd have been confident that if the tech gained root privilege, he could only access my user Filevault by maybe he resetting my account password (not certain of this, but a layman's take). Which I would be able to detect.
With Lion, if I had to give a tech a standard account access (not being able to pre-wipe the disk) and he gained root privilege, he may be able to access other account data through file permissions alone. This would not be detectable.