How to use both FileVault2 and Bitlocker simultaneously on a dual-boot Mac running bootcamp

I am the proud owner of a beautifully noisy drive.

A noisy drive?!?!?!!!! Get your data off that before it dies!!!

Thanks for the concern but I’m not taking about that kind of noise.

Oh, did you get a HDD stepper to play music??

No but I think the imperial march and still alive are my favourite step-step songs.

That fine, if you don’t want to tell me I’ll go to another blog

Ok, Ok. This post is about something I have been wanting for ages and didn’t think was possible. This shows how to use both FileVault 2 and Bitlocker simultaneously on a multi-boot mac (running bootcamp). The noise I’m referring to is the pseudorandom noise of an encrypted drive (FDE) :D

What’s so special about that? Is this not an easy thing to do?

No, generally it is not possible to do this due to some good design choices both Apple and Microsoft (and other encryption providers) have employed mixed with a silly one that Apple have made.

The Microsoft and Apple boot providers require a boot loader to remain on  an unencrypted volume which then provides an mechanism to access the protected , encrypted, partition. So to use FDE on either of these Operating Systems you need 2 primary partitions. Legacy partition tables use MBR to describe the  layout of the partition scheme. This partition scheme has a limit of 4 primary partitions.

Can we not just use those four primary partitions?

Nope as the Mac has a recovery partition that you need to keep intact so there there are 3 primary partitions available. This means that typically only on of these operating system can enjoy FDE (and I’m not using containers in a OS, that’s too leaky…).

Are we going to time travel and change some specs???

Nope, luckily for us the Mac uses 2 partition tables. One is GPT and the other is MBR.

The MBR partition is used to boot the Mac encrypted boot loader which in turn provides access to the encrypted Mac partition from the GPT table.

When loading the Windows/Bootcamp parition the MBR is used to determine the availability of the windows encrypted boot loader which in turn uses the MBR to access the encrypted windows partition.

This means for a dual boot fully encrypted system we only need 3 partitions listed in the MBR. Normally the MBR partition is just a clone of the GPT one which is where the problem lies.

Happily we can use some ancient tools to edit these manually and allow dual boot of fully encrypted operating systems, while keeping our beloved restore partition.

Ok, how?

The process is as follows:

<disclaimer: this guide is provided as is, and has no warranty. If you  suffer data-loss, damage etc then this is your responsibility so be a mature person and accept that>

  • Partition the disk using the Disk utility in OS X
  • Enable Filevault
  • Reboot
  • Get a list of partition parameters from the GPT partition table
  • Erase and recreate the MBR table, including only the windows partitions and the Mac encrypted loader partition
  • Run the windows installer
  • Edit the windows recovery/encrypted loader partition
  • Install windows
  • Allow TPM-free bitlocker use
  • Enable bitlocker
  • Smile

    Partition the disk using the Disk utility in OS X

    Reduce the size of the OS X partition to make room for windows, here I am giving OS X 98GB

    1

    Then create 2 new partitions:

    • One for the windows partition
    • One for the Bitlocker boot loader (around a 200 MB – 1gb)

    2

    Enable Filevault and Reboot

    Go to System Preferences > Security & Privacy > [Filevault] and turn it on. Remember to responsibly store your recovery key, mine is on an encrypted backup…. not stored with Apple.

    3

    Then reboot to enable/verify the encryption.

    Get a list of partition parameters from the GPT partition table

    Open the terminal and run the following command to get the details of the GPT table.

       1:  sudo gpt -rv show -l disk0

    5

    Take note of the start point, size and type of partition.

    Erase and recreate the MBR table, including only the windows partitions and the Mac encrypted loader partition

    The windows partitions and mac encrypted loader are the items at indexes 1, 4 and 5. On your system this may differ but index 1 should remain the same.

    Go to a terminal and open fdisk in edit mode

       1:  sudo fdisk -e /dev/disk0

    Erase the MBR table

       1:  erase

    Add a new table and then a new entry for the mac bootloader

       1:  add 1

    Edit this partition to match the OS X encrypted loader partition, the details are from index 1 above but should be identical to this (as of OS X 10.9 in a standard scenario)

       1:  edit 1
       2:  Partition id : EE
       3:  CHS mode : no
       4:  Partition offset: 1
       5:  Partition size:  409600

    Then add the first windows partition, I got the offset and size from index 4 above – this will be different on your systems so pay attention to YOUR start and size parameters and ensure its the the correct windows partition.

       1:  edit 2
       2:  Partition id : 07 
       3:  CHS mode : no
       4:  Partition offset: 193085424
       5:  Partition size: 296059568

    Now add the second windows partition, I got the offset and size from index 5 above – this will be different on your systems so pay attention to YOUR start and size parameters and ensure its the the correct windows partition.

       1:  edit 3
       2:  Partition id : 07 
       3:  CHS mode : no
       4:  Partition offset: 489407136
       5:  Partition size: 827576

    Then write the MBR table using the command

       1:  write

    When you issue the print command a table similar to the following will be displayed (the exact details will be different as appropriate for your disk layout)

    6

    Now that the tough stuff is done we only need to install windows, pop in a windows install disk and do the following.

  • Reboot the machine and run the windows installer
  • Edit the windows recovery/encrypted loader partition – format it
  • Install windows
  • Allow TPM-free bitlocker use

    Open the group policy editor by running gpedit.msc

    In the group policy editor open:

    Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives.

    Then open the entry for Require additional authentication at startup

    This will bring up an editor for this policy where you can enable the option by clicking the Enabled radio button and then on the options panel click the  Allow BitLocker without a compatible TPM  checkbox.

  • Enable bitlocker
  • Smile

    Enjoy your dual-boot, encrypted work-capable machine :)

  • Software Encrypted SSD Performance – A Surprising outcome

    Seriously? Are you surprised at the speed increase provided by an SSD?

    No I’m not, actually I was a little disappointed in my SSDs Performance.

     

    Did you buy a no-Brand SSD from some shady eBay seller?

    Well, Kind of… I bought a Dell OEM branded edition of a Samsung PM830 from a reputable eBay seller… in person to avoid ebay charges for him, this drive is reported to be a High performance part by trusted sources. I then used Diskcryptor to provide protection against unauthorised access to my files from konboot, ntpasswd, linux live disks  or any other number of NTFS access based attacks.

    Ahhh! I know what happened…. your SSD performance was limited by a less capable CPU that could only encrypt at low rate!

    Actually, no the laptop hosting this drive has a recent model intel core chip that in benchmarks can easily encrypt twofish at a rate that could saturate the reported  550mb/s  max speed of this drive.

     

    After some investigation and what seemed like an endless series of setting tweaks the issue seemed to stem from a problem that plagued the first generations of SSDs…. Wastage due to deleted flash memory blocks not being released cleanly back to the drive controller for reuse. This performance issue was overcome with the introduction of the TRIM command which ‘recycles’ deleted data blocks (explained here and here).

     

    How did the Software based Full Disk Encryption (FDE) intefere with TRIM?

    At a low level FDE intercepts file system operations from the Operating system to the Disk and turns them into what looks like random gibberish, so instead of a disk populated with nice sensibly structured file system the stored data  looks like nothing comprehensible until the appropriate encryption key is applied (these are usually derived from a password using something like PBKDF2).

     

    This encryption provider that intercepts File system commands is where the performance degradation problem lies (at least in the case of diskcryptor) as it appears to interfere with the operation of the TRIM command.

    This could be for many reasons but I would guess that the most likely culprit is that:

    The  TRIM command issued by the Operating System (OS) provides a set of LBAs where files previously were deleted from, these blocks do not exist as a structure in the FDE container and mapping from the OS specified blocks to the FDE blocks can not happen due to various reasons related to the abstraction of the encrypted data on the SSD into a virtual HDD  (e.g potential storage errors due to  lack of discreet block level representation of files meaning that a TRIM command would wipe out a block of data  representing a segment of  the encrypted container and so would have a corrupting effect on subsequent data in that container) so the encryption provider may likely strip the TRIM command out to ensure integrity.

     

    Should you not have known this?

    I thought this would have been the case BUT there was so much anecdotal evidence on online forum sites stating that late editions of solutions such as Truecrypt and Diskcryptor would not  degrade performance on SSDs so I thought it was worth a check.

    On initial encryption the performance was on par with its unencrypted throughput so I thought I had proven the online observations correct in this case.

    My blind trust in the then ‘proven’ software solution is also why I spent a lot time looking @ other factors on my beta operating system before removing encryption especially as I installed an Intel chipset driver on this Win 8 edition around the time of the performance degradation and assumed a bug showed its face.

     

    So is it a case of Speed or Security

    Happily no, most modern SSD units support some form of strong encryption (e.g the PM830 has AES256, The Intel 320 has AES128 ) that can be ‘enabled’ (this is likely always on as there is no long initial encryption process) by adding a HDD password in the BIOS.

    This has one major pro and huge negative:

    Pro – The encryption is performed by the SSD controller so there is no host machine performance degradation due to the removal of an encryption overhead.

    Con – The HDD password on the Samsung PM830 is 8 characters MAX, much weaker than my previous 37 character diskcryptor password (this is the reason I wanted to used a software approach in the first place).

     

    So whats the outcome

    Major laziness on my part came back back to bite me ,  I should have  checked the  performance of the software encrypted SSD  after filling and then removing data from it and not just shortly after I encrypted it and should not have assumed that the on-line anecdotes and my intital benchmark were correct.

    Lesson learned and I am peeling the egg of my face but enjoying my again speedy SSD .