XPost: comp.sys.mac.system
Ant <
ant@zimage.comANT> wrote:
On 2/25/2017 6:58 PM, David Empson wrote:
Ant <ant@zimage.comANT> wrote:
While messing around a 15" early 2008 MBP in installing a new Mac
OS X v10.11.x/El Capitan OS from a 64 GB PNY USB flash drive into
its old original internal HDD, I noticed different results when
encrypting its internal old HDD:
1. Encrypt (FileVault -- took a couple hours) after installing and
updating Mac OS X v10.11.5 from an USB flash drive into a
reformatted HDD with case sensitive journaled Mac OS FS. Mac OS X
even told me to save a recovery key (used local, not cloud).
Booting up MBP shows Mac OS X's user accounts login screen.
2. Encrypt while formatting a non-case sensitive journal Mac OS FS
(took like a minute) before installing Mac OS X v10.11.6
(redownloaded and remade my bootable USB installer). Booting up the
HDD show disk password instead of Mac OS X's login screen. Mac OS X
says FileVault is enabled. Mac OS X never told me to save a
recovery key.
Why the different results between these two encrypted disk orders
if FileVault's encryption is used? Thank you in advance. :)
In the second case you've used the method typically used with an
external drive, not the startup drive. The normal method for the
startup drive is to turn on FileVault in System Preferences, after installing the OS.
Ah. I did it during it format because it takes forever to encrypt.
You don't need to wait for it to fully encrypt the drive. Encryption
happens in the background, and you can use the drive normally (including installing an operating system or copying user data) while the
encryption is in progress.
Any data written will be encrypted during this phase, as documented by
Apple for FileVault (but it is the same for manually encrypted drives):
https://support.apple.com/HT204837
If you decide later that you want to decrypt the drive (i.e. disable the encryption), the sequence is similar: it decrypts in the background,
working its way through the whole volume/partition.
(You can't start the decryption process until the encryption process has finished.)
I was assuming it was using FileVault's method which I did see it was
enabled after installing and rebooting.
As I said later in my post, the underlying mechanism is the same, only
the details around passwords differ.
For a single-user computer it doesn't make a huge difference, but
there is an important difference for a multi-user computer.
OK, I noticed that before and after doing a long encrypted Time Machine restore for kicks with admin, standard, and guest accounts.
Method 1 (FileVault) allows you to have multiple accounts able to
unlock the disk, using just the account password.
[...]
Method 2 (encrypted disk created with Disk Utility or encryption
enabled in Finder) sets a single disk password. That password needs
to be known by everyone who needs to be able to unlock the disk. If
used on a startup disk, the password needs to be entered before the
disk can be mounted at startup, so there is an additional password
prompt (unlock disk, then log in) unless you use auto-login.
I noticed non-admin accounts can be granted to unlock disk. My brand new admin account doesn't even show up. I do see a "Disk Unlock" account which was made when I formatted the drive as encrypted Mac OS FS yesterday with
the USB installer.
That's a detail I hadn't seen before as I've never tried installing an
OS on a manually encrypted disk.
In order to mount an encrypted startup disk, the OS has to use the same
boot sequence as FileVault, which actually does a double boot: the
initial login or password prompt is displayed after doing a partial boot
from the recovery partition (which is not encrypted). Once the password
has been entered, it is used to get the copy of the AES key which can
then be used to unlock the main partition. The system then boots
normally from the main partition.
If you use FileVault, the second stage boot bypasses the login screen
because you already entered your username and password at the unlock
login screen, and the OS saves them for reuse at account login.
If you manually encrypted the disk, the system needs to display the
normal login screen, because it doesn't have a username and account
password yet (assuming you haven't used auto login).
If you change the disk password, you need to tell all users the new password.
Wait, where is this change disk password? I don't see it in both Mac OS
X's user accounts and Disk Utility. I assume it can be removed too? Or
does that require a reformat?
For a manually encrypted volume on an external drive, the Change
Password command is in the File menu of Disk Utility, when you select
the indented icon for the volume/partition (not the leftmost icon for
the drive itself).
In older versions of Disk Utility (up to Yosemite) there was also a
"Turn off Encryption" command there, but it is missing in the rewritten
Disk Utility for El Capitan and later.
In all OS versions which support full disk encryption, Finder has an
"Encrypt" or "Decrypt" command in the contextual menu for external
volumes (but not in its File menu).
These are not offered for FileVault volumes (current startup disk),
because they don't have a disk password which could be changed (only
account passwords), and decryption is done by turning off FileVault in
System Preferences.
I don't know what options appear for a manually encrypted startup disk.
For non-startup disks, it is possible to store the disk password in
your keychain, so you don't need to enter it each time the disk is
mounted. The system doesn't offer to store the password in the
keychain when encryption is first set up, but it does when you next
mount the disk.
I have used external non-startup and startup drives with their Mac OS encryptions. I didn't use their keychains though.
It isn't "their" keychain, it is "your" keychain - the keychain is
associated with a user account. You can use keychain to save passwords
for various things, including encryption passwords for mounted volumes.
The keychain is protected using your account password (or a separate
keychain password if you set it up specially).
If there are multiple user accounts involved, each one has their own
keychain, so each person who might need to mount the volume could
independently decide whether to save the password in their own keychain.
This only affects whether the system asks for a password when the volume
is mounted - if the password is in the current user's keychain it mounts automatically.
This is obviously no help for an encrypted startup disk, because the
keychain is on the disk and can't be accessed until the disk has been
unlocked.
In both cases, the underlying encryption mechanism is identical
(using AES, with a symmetric encryption/decryption key). The only difference is how the decryption key is stored and accessed. The key
is stored on the volume but is encrypted (using a one-way encryption method) with the disk password for a manually encrypted disk, or
multiple copies encrypted with each account password and recovery key
for FileVault.
That means the weakest password is the weakest link for decrypting
the drive. For FileVault, all account passwords must be "strong
enough" or someone stealing the drive or computer could guess one of
them and decrypt the drive.
OK amd thanks. :)
So wait, FileVault is not encrypting the whole drive but formatted
encrypted drive is?
As I said, FileVault and manual encryption use exactly the same
underlying method. The entire logical volume (partition) is encrypted in
both cases (once the background encryption pass has finished).
The only low level difference is how user accounts and passwords relate
to the process of getting the AES key to unlock the disk.
For either variant, once the drive has been unlocked by any valid
password or recovery key, all data on the drive is accessible to the
same degree it would be on a drive which is not encrypted (protected by permissions as usual, but those are bypassable for an admin user). The
AES key is held in memory by the OS until shutdown (or the drive is
unmounted, in the case of an external disk).
Therefore with a FileVault-encrypted drive, any easily guessed user
account password for an account which can unlock the drive would allow a
bad actor to unlock the drive and bypass the encryption.
Therefore all users which can unlock the drive need good passwords.
If so, then what exactly is FileVault not encrypting then?
Everything on the partition is encrypted.
The recovery partition is not encrypted, but it contains no user data
and it can't access anything on the main partition unless you have (or
can guess) any password which can unlock the main partition. (The
recovery partition could erase the main partition without unlocking it.)
--
David Empson
dempson@actrix.gen.nz
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)