HT4790: OS X: About FileVault 2

Learn about OS X: About FileVault 2
MeMeMeMeMe

Q: Diskutil eject does not 're-lock' Filevault encrypted volumes on external drive

Man documentation for diskutil...

 

http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/ man8/diskutil.8

 

... states that the diskutil eject command can be used to "re-lock" a corestorage volume that has been previously unlocked:

 

"To 're-lock' the volume, make it offline again by ejecting it, e.g. with diskutil eject."

 

I have an external hard drive with several Filevault 2 encrypted partitions (OSX 10.8.3) .  Once a volume is unlocked using diskutil corestorage unlockVolume, when the volume is subsequently ejected using diskutil eject, it  shows the disk as unlocked after ejecting.  After ejecting, I can look with diskutil corestorage list and find:

 

|               Encryption status:      Unlocked

 

Indeed, after ejecting, the disk can be re-mounted and the files accessed without re-entering the Filevault password for the volume.

 

The only means I have for restoring the disk to the locked status is to restart the machine.

 

What is the correct way to "re-lock" a corestorage volume?

 

Below is the output for the drive using diskutil corestorage list after unlocking with diskutil corestorage unlockVolume and then ejecting with diskutil eject.

 

 

+-- Logical Volume Group ####

|   =========================================================

|   Name:        ####

|   Status:       Online

|   Size:         498058510336 B (498.1 GB)

|   Free Space:   0 B (0 B)

|   |

|   +-< Physical Volume ####

|   |   ----------------------------------------------------

|   |   Index:    0

|   |   Disk:     disk1s4

|   |   Status:   Online

|   |   Size:     498058510336 B (498.1 GB)

|   |

|   +-> Logical Volume Family ####

|       ----------------------------------------------------------

|       Encryption Status:       Unlocked

|       Encryption Type:         AES-XTS

|       Conversion Status:       Complete

|       Conversion Direction:    -none-

|       Has Encrypted Extents:   Yes

|       Fully Secure:            Yes

|       Passphrase Required:     Yes

|       |

|       +-> Logical Volume ####

|           ---------------------------------------------------

|           Disk:               disk2

|           Status:             Online

|           Size (Total):       497739735040 B (497.7 GB)

|           Size (Converted):   -none-

|           Revertible:         No

|           LV Name:            ####

|           Volume Name:        ####

|           Content Hint:       Apple_HFS

Mac mini, OS X Mountain Lion (10.8.3)

Posted on Apr 2, 2013 1:41 AM

Close

Q: Diskutil eject does not 're-lock' Filevault encrypted volumes on external drive

  • All replies
  • Helpful answers

Page 1 Next
  • by Linc Davis,

    Linc Davis Linc Davis Apr 2, 2013 6:54 PM in response to MeMeMeMeMe
    Level 10 (207,983 points)
    Applications
    Apr 2, 2013 6:54 PM in response to MeMeMeMeMe

    That's an interesting observation. The man page lies.

  • by Topher Kessler,

    Topher Kessler Topher Kessler Apr 2, 2013 7:02 PM in response to MeMeMeMeMe
    Level 6 (9,866 points)
    Apr 2, 2013 7:02 PM in response to MeMeMeMeMe

    Do you by chance have the volume's password stored in your keychain?

  • by MeMeMeMeMe,

    MeMeMeMeMe MeMeMeMeMe Apr 11, 2013 4:35 AM in response to Topher Kessler
    Level 1 (0 points)
    Apr 11, 2013 4:35 AM in response to Topher Kessler

    No.  Password is not in my keychain for the logged in account.

  • by Linc Davis,

    Linc Davis Linc Davis Apr 11, 2013 6:56 AM in response to MeMeMeMeMe
    Level 10 (207,983 points)
    Applications
    Apr 11, 2013 6:56 AM in response to MeMeMeMeMe

    Whether or not the password is saved in the keychain is irrelevant to the lock status of the volume. The volume is unlocked when the key is in memory, and locked otherwise. Your diskutil output shows an unlocked volume, and I confirmed the behavior. That makes it even more important to secure a system that handles encrypted HFS data from local attack. At a minimum, the screen must be locked whenever you're away from the machine.

  • by Topher Kessler,

    Topher Kessler Topher Kessler Apr 16, 2013 7:15 AM in response to MeMeMeMeMe
    Level 6 (9,866 points)
    Apr 16, 2013 7:15 AM in response to MeMeMeMeMe

    Bizarre. If there is no keychain entry for the volume then it should not automatically unlock if and when detected by the system (ie, the keychain password is quite relevant to the unlock status of an encrypted drive).

     

    Since you do not have such a password in yoru keychain, if you eject and then disconnect the drive does it show a locked status if you then reconnect it? Additionally, if you try to directly mount the drive in Disk Utility does it automatically mount or does it require a password regardless of the unlock status designated in the corestorage volume list?

  • by MeMeMeMeMe,

    MeMeMeMeMe MeMeMeMeMe May 12, 2013 2:56 PM in response to Topher Kessler
    Level 1 (0 points)
    May 12, 2013 2:56 PM in response to Topher Kessler

    Topher Kessler wrote:

     

    Bizarre. If there is no keychain entry for the volume then it should not automatically unlock if and when detected by the system (ie, the keychain password is quite relevant to the unlock status of an encrypted drive).

     

    Since you do not have such a password in yoru keychain, if you eject and then disconnect the drive does it show a locked status if you then reconnect it? Additionally, if you try to directly mount the drive in Disk Utility does it automatically mount or does it require a password regardless of the unlock status designated in the corestorage volume list?

     

    It doesn't unlock automatically.  What I'm saying is, if you unlock it once by manually entering the password (it is not in my keychain), then it is forever unlocked until the machine is rebooted.  OSX documentation says that "diskutil eject" should re-lock the volume, but it doesn't.  The volume can be re-mounted without re-entering the password (even though it is not in the keychain).  The password must remain stored in memory somewhere even after the "diskutil eject" command is issued.

     

    As I said in the original post, after issuing the "diskutil eject" command, the status of the drive still shows an unlocked status when running "diskutil corestorage list", even after the disk has been ejected.

     

    The same behavior occurs if mount a locked disk and then unmount it using the graphical interface Disk Utility.  No password stored in keychain.  Manually enter the password, the disk mounts.  Unmount the disk.  It can be re-mounted from disk utility without entering the password a second time.

     

    I tried logging out the user too.   It doesn't matter.  The only thing that re-locks the volume that I can discover is rebooting the computer.

     

    This seems like a pretty big security hole for FileVault.  Is Apple acknowledging this problem and working on a fix?  How to bring it to their attention?

  • by MeMeMeMeMe,

    MeMeMeMeMe MeMeMeMeMe May 12, 2013 6:21 PM in response to Linc Davis
    Level 1 (0 points)
    May 12, 2013 6:21 PM in response to Linc Davis

    Linc Davis wrote:

     

    Whether or not the password is saved in the keychain is irrelevant to the lock status of the volume. The volume is unlocked when the key is in memory, and locked otherwise. Your diskutil output shows an unlocked volume, and I confirmed the behavior. That makes it even more important to secure a system that handles encrypted HFS data from local attack. At a minimum, the screen must be locked whenever you're away from the machine.

     

    I only have filevault enabled on my external drive.

     

    You confirmed the behavior, but is yours an external or internal drive?  Not sure it even matters.  Could it be a problem with both?

  • by M. Anthony Aiello,

    M. Anthony Aiello M. Anthony Aiello May 23, 2013 10:15 AM in response to MeMeMeMeMe
    Level 1 (30 points)
    May 23, 2013 10:15 AM in response to MeMeMeMeMe

    This is a major issue. It's incredible to me that a) more people have not identified this problem and b) Apple is not saying anything about it.

     

    Note that not only does `diskutil eject` not work as advertised, ejecting the volume in Finder also does not lock it. There appears to be absolutely not way, short of disconnecting the media (e.g., yanking the USB/FireWire/Thunderbolt cable or pulling the disk from the enclosure) of re-enabling encryption.

     

    How is this okay? How did Apple let this happen? And why hasn't anyone else identified it?

  • by MeMeMeMeMe,

    MeMeMeMeMe MeMeMeMeMe Jun 9, 2013 5:23 AM in response to M. Anthony Aiello
    Level 1 (0 points)
    Jun 9, 2013 5:23 AM in response to M. Anthony Aiello

    M. Anthony Aiello wrote:

     

    This is a major issue. It's incredible to me that a) more people have not identified this problem and b) Apple is not saying anything about it.

     

    Note that not only does `diskutil eject` not work as advertised, ejecting the volume in Finder also does not lock it. There appears to be absolutely not way, short of disconnecting the media (e.g., yanking the USB/FireWire/Thunderbolt cable or pulling the disk from the enclosure) of re-enabling encryption.

     

    How is this okay? How did Apple let this happen? And why hasn't anyone else identified it?

     

    Maybe we're asking the wrong people.  NSA?  What do you think?

  • by jasonmoorman,

    jasonmoorman jasonmoorman Jun 14, 2013 7:12 AM in response to MeMeMeMeMe
    Level 1 (0 points)
    Jun 14, 2013 7:12 AM in response to MeMeMeMeMe

    I'm having the same issue, but with an encrypted disk image, full of sensative financial docs.  I tried encrypting an actual external drive and behaves the same as the DMG. 

     

    I'm not 100% certain, but I DON'T think Disk Utility used to behave this way, but rather actually DID relock encrypted volumes upon unmounting them.  I'm not sure if Lion or Mountain Lion is responsible for the change in behavior, but I seriously doubt it's working as intended.

     

    Apple needs to fix this before someone gets his identity stolen or worse, due to this gaping security hole and the false belief that encrypted volumes are actually secure in the current OSX + Disk Utility versions.

  • by CagleRacing,

    CagleRacing CagleRacing Jul 20, 2013 3:29 PM in response to MeMeMeMeMe
    Level 1 (0 points)
    Jul 20, 2013 3:29 PM in response to MeMeMeMeMe

    I'm having the same issue with an external drive and the issue is what brought me to this page. 

     

    I'm running Mountain Lion 10.8.4 on a late 2012 27" iMac.  Has anyone tested an encrypted, but unlocked, external drive on another Mac running Lion or Mountain Lion?  I'm curious to know just how unprotected these drives have become.

  • by cobrabytemac,

    cobrabytemac cobrabytemac Sep 27, 2013 7:01 AM in response to MeMeMeMeMe
    Level 1 (0 points)
    Sep 27, 2013 7:01 AM in response to MeMeMeMeMe

    I, too, am seeing this behavior with all the latest updates under 10.8.4.

     

    Has Apple really just ignored this security issue? Even CNET wrote about it back in April (http://reviews.cnet.com/8301-13727_7-57589396-263/insignificant-bug-keeps-encryp ted-disks-unlocked-after-ejecting-in-os-x/).

     

    Can we get an official response from Apple on this?

  • by MeMeMeMeMe,

    MeMeMeMeMe MeMeMeMeMe Oct 24, 2013 8:00 PM in response to MeMeMeMeMe
    Level 1 (0 points)
    Oct 24, 2013 8:00 PM in response to MeMeMeMeMe

    Still not fixed with OSX 10.9 (Mavericks).  What's the deal here?

  • by fred724,

    fred724 fred724 Nov 4, 2013 5:22 AM in response to MeMeMeMeMe
    Level 1 (15 points)
    Nov 4, 2013 5:22 AM in response to MeMeMeMeMe

    The best work around for this issue is to format the external drive using HFS+ journaled encrypted from the diskutil options.  Set your password and be sure to not save to keychain.  My external encrypted drives always ask for the pw again after I unmount and remount them (in the same session). 

     

    ed724

Page 1 Next