none
Bitlocker first steps - first obscurities RRS feed

  • Question

  • Hello,

    I make my first experiences with Bitlocker (as FDE with Windows 10) and now some questions have arisen.

    Are the default XTS-AES 128-bit really "enough" or is it recommendable to use XTS-AES 256-bit?
    Especially because I have read that XTS-AES 128-bit is (in simple words) only 2x AES 64-bit?!
    Is there a big performance drop to expected when I use XTS-AES 256 instead of the 128 or is this
    on modern hardware (i5-8250U + SSD) not a big deal?

    Is it enough to encrypt only the used space or should I encrypt the whole disk even when there was never any data on the drive?
    But maybe it´s recommendable because of areas which is usen by the ssd controller for maintenance/wear level?
    Is this setting only for the initial encryption or has it a impact in the general usage?

    It would be nice if I could do it without a pre-boot pin/password and use only the TPM
    and a good user (windows) password. But I have read while a forced windows upgrade the drive is unencrypted/open.
    So a thief could "just" wait until a new windows version is being installed and then have full access to the data.
    But... I wonder, are gonna windows upgrades (to a new redstone for example) installed at all when no user is logged on?

    Standby (Suspend to RAM) should not be used - right?

    And at the end - which imaging software can you recommend which works without any problems with an
    encrypted drive? I have testet seagates discwizard (its based on acronis) but it seams to image the whole disk
    blockwise. The image file had the same size as the whole ssd. I avoid the windows build in tool because
    I had bad experience (problems with restores) in the past.

    Thank you for reading and any comment!
    Greetings
    Martin
    Monday, April 30, 2018 4:16 AM

All replies

  • Hi,

    For encryption methods, please read this article

    Bitlocker: AES-XTS (new encryption type)

    https://blogs.technet.microsoft.com/dubaisec/2016/03/04/bitlocker-aes-xts-new-encryption-type/

    "Encrypt Used Disk Space Only" means a much shorter time for BitLocker to complete the initial encryption process for new volumes.  For volumes that already have data on them, it is recommended that the ‘Encrypt entire drive’ option be used.

    Do I have to decrypt my BitLocker-protected drive to download and install system updates and upgrades?

    No user action is required for BitLocker in order to apply updates from Microsoft, including Windows quality updates and feature updates.  Users need to suspend BitLocker for Non-Microsoft software updates, such as:  

    • Computer manufacturer firmware updates
    • TPM firmware updates
    • Non-Microsoft application updates that modify boot components

    Note:  If you have suspended BitLocker, you can resume BitLocker protection after you have installed the upgrade or update. Upon resuming protection, BitLocker will reseal the encryption key to the new values of the measured components that changed as a part of the upgrade or update. If these types of upgrades or updates are applied without suspending BitLocker, your computer will enter recovery mode when restarting and will require a recovery key or password to access the computer.

    Here is a BitLocker FAQ for you:

    BitLocker frequently asked questions (FAQ)

    https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-frequently-asked-questions


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, April 30, 2018 8:57 AM
    Moderator
  • Hi.

    Is XTS-AES128 enough... well, ask Microsoft. They will say, it is the default, because it is secure enough "for most people" which will not help judging this. You should use 256 when you feel you have the need for the best protection available. The performance needs to be measured by you - we cannot decide what feels "big" for you. I did not notice a difference between the two, but I did no benchmarking.

    --

    Used space only is fine when there is no data around that got deleted before that was sensitive.

    --

    Your scenario is correct, if you only wait long enough, windows should auto-upgrade some day and then the drive is unlocked (all protectors disabled) no matter if a preboot PIN is set or not. This is no big problem in professional environments, since those normally don't let users use the internet to download feature upgrades but use different deploymnet services like WSUS.

    --

    Suspend to RAM allows cold boot attacks to happen that would not be possible if you shutdown or hibernate your machine and use PBA with it.

    --

    The windows internal tool worked here in tests, but we use drive snapshot which even allows restoring in an encrypted form (no need to re-encrypt). To achieve that, you would initiate the restore online, not offline, which this software makes possible even for c:




    Monday, April 30, 2018 9:55 AM
  • "Encrypt Used Disk Space Only" means a much shorter time for BitLocker to complete the initial encryption process for new volumes.  For volumes that already have data on them, it is recommended that the ‘Encrypt entire drive’ option be used.

    I understand, so on a brand new or secure erased disk it should be ok to encrypt only the used spaced when I enable Bitlocker immediately after the installation.
    The existing and future saved data will be then encrypted.
    Or is it possible that there are chunks left (for example maintenance/wear level chunks which has been created by the ssd controller) which not are identified as "used disk space" and they so are not to be encrypted?

    Wednesday, May 2, 2018 3:27 AM
  • Thank you for your answer!

    > Is XTS-AES128 enough... well, ask Microsoft. They will say, it is the default, because it is secure enough "for most people" which will not help judging this.
    I just wonder why then the Microsoft Security baseline is recommends XTS-AES-256 for operating system drives and fixed drives and AES-CBC-256 for removable drives.

    > Bitlocker is suspended during a inplace upgrade
    Pre-boot auth should prevent the machine from updating - or not?

    In my view it is a big deal, not all Bitlocker users are professionals respectively all (very) small companies are using deployment services.
    With this "feature" Bitlocker is almost useless.
    But with 1803 there is
    apparently a solution for this behavior
    https://blog.win-fu.com/2016/11/every-windows-10-in-place-upgrade-is.html?showComment=1525192307793#c8706595552165848031

    > The windows internal tool worked here in tests, but we use drive snapshot (...)

    The Windows internal "Create a system image" now works - I had first testet it on an old build (16299.19) where it was broken (it were fixed with a later update).
    I like drivesnapshot too, but has a few problems when i tested it with bitlocker.
    But I think it was a problem with the machine - in the meantime it works perfect as usual.

    Have a nice day,
    greetings

    Martin
    Wednesday, May 2, 2018 4:00 AM
  • The security baseline will recommend mostly hard measures. For removable drives however, you should not use XTS-AES, since that cannot be read on OS' pre win10, thus use AES_CBC.

    --

    During the upgrade, all protectors are disabled - no preboot authentication!

    --

    "But with 1803 there is apparently a solution for this behavior" - great to read that! Funny that it takes Microsoft so many years to realize and stop that behavior.

    Wednesday, May 2, 2018 7:01 AM
  • > The security baseline will recommend mostly hard measures.
    I think I will go with XTS-AES-256 since on modern hardware the performance loss seems to be negligible.

    > For removable drives however, you should not use XTS-AES (...)
    Jep, default is AES-CBC 128-bit.

    >>> Bitlocker is suspended during a inplace upgrade
    > Pre-boot auth should prevent the machine from updating - or not?
    >
    During the upgrade, all protectors are disabled - no preboot authentication
    I know, but I wonder if a pre-boot auth prevents the machine from obtaining a upgrade?
    Because that would be a solution for
    non-managed devices (my problem).

    I will just prevent that a thief gives the machine a internet connection, waits until the next upgrade and has then (meanwile the upgrade) access to the data.

    Wednesday, May 2, 2018 8:54 AM
  • "I know, but I wonder if a pre-boot auth prevents the machine from obtaining a upgrade?" - please accept a "no". Bitlocker is suspended, it does not matter if preboot auth is configured or not. You might be lucky (please test) by

    adding the lines

    [SetupConfig]
    BitLocker=TryKeepAlive

    to %systemdrive%\Users\Default\AppData\Local\Microsoft\Windows\WSUS\SetupConfig.ini

    (advice taken from the Microsoft blog entry)

    Wednesday, May 2, 2018 9:27 AM
  • "I know, but I wonder if a pre-boot auth prevents the machine from obtaining a upgrade?" - please accept a "no". Bitlocker is suspended, it does not matter if preboot auth is configured or not. You might be lucky (please test) by

    adding the lines

    [SetupConfig]
    BitLocker=TryKeepAlive

    to %systemdrive%\Users\Default\AppData\Local\Microsoft\Windows\WSUS\SetupConfig.ini

    (advice taken from the Microsoft blog entry)

    I think we talk past each other.
    When the upgrade was started then of course bitlocker is suspended (if not set differently with the new "/BitLocker ForceKeepActive" option).

    But I will simply prevent that a thief can start the machine and wait until a upgrade is downloaded and installed. Which then would leads the possibility to gain access to the data.

    So my question is - should not prevent a pre-boot auth this possibility anyway?
    And is (obtain and install) a upgrade (not a update!) from windows online without a user is logged on a thing at all?
    I have to admit that I not seen a machine doing that ever, but presumably I have (yet) to few win10 devices around me. 

    Wednesday, May 2, 2018 11:37 AM
  • If the thief steals a running machine, then you have a problem. If it is not running, of course preboot auth. stops him from starting.
    Wednesday, May 2, 2018 11:39 AM
  • If the thief steals a running machine, then you have a problem. If it is not running, of course preboot auth. stops him from starting.

    So pre-boot auth prevents him from getting a upgrade also - right?

    But without pre-boot auth (only TPM) he can boot and then fails at windows logon.
    I had read it is possible to then get a upgrade (not a only a update!) from
    windows online without a user is logged on and without any endorsement from the user.
    So a thief could wait until this upgrade is being installed, bitlocker is suspended
    and ta-da full access to the data.

    Is this (obtain and install) a upgrade (not a update!) from windows online without a user is logged on really possible?
    Can it be switched off?


    • Edited by m.fessler Friday, May 4, 2018 9:30 AM
    Friday, May 4, 2018 9:17 AM
  • "So pre-boot auth prevents him from getting a upgrade also - right?" - I am about to ask you "do I speak chinese?" :-)

    if the device is powered down when stolen, all is well. if it is powered up and windows is running but locked, the thief only needs to wait for the upgrade to happen some day and the preboot auth does not help since the upgrade process suspends bitlocker.

    "Is this (obtain and install) a upgrade (not a update!) from windows online without a user is logged on really possible?" - yes!

    "Can it be switched off?" - presumably yes! I wrote down before, that "BitLocker=TryKeepAlive" should be the key, which keeps bitlocker always on, preventing suspension. Can the ability to download upgrades be switched off? No, not without disabling updating altogether.

    Monday, May 7, 2018 7:02 AM
  • > I am about to ask you "do I speak chinese?" :-)
    Sorry english is not my native language, but chinese would be even worse,
    so please stay in english. ;-)

    > (...) the thief only needs to wait for the upgrade to happen some day and the
    > preboot auth does not help since the upgrade process suspends bitlocker.
    But how can he receive the upgrade at all when pre-boot auth is active?
    He can not boot the machine...?!

    >> "Is this (obtain and install) a upgrade (not a update!) from windows online without a user is logged on really possible?"
    > yes!
    Woow that is then really a problem and leads encrypting with bitlocker almost to absurdity.
    By the way - is then only the system partition "open" or every other partition or internal drive as well?

    > Can the ability to download upgrades be switched off? No, not without disabling updating altogether.
    A simple fix would be a gpo to disable the possibility to get a upgrade when no user
    is logged on. A (security) update, ok - for my sake - but not an upgrade.

    >> Can it be switched off?" - presumably yes! I wrote down before, that "BitLocker=TryKeepAlive" should be the key (...)
    The line in the SetupConfig.ini... I understand.
    Anything official about this?
    Unfortunately, that's hard to test.
    Monday, May 7, 2018 3:07 PM
  • You write "He can not boot the machine...?!" which is true, when it was off, when stolen. That's the distinction I am trying to emphasize the whole time. When it's off, then that preboot auth will help.

    "Anything official about this?" - just the blog entry I found: https://blogs.technet.microsoft.com/mniehaus/2018/05/02/new-upgrade-to-windows-10-1803-without-suspending-bitlocker/ Last section:

    --

      • For servicing-based approaches (WU, WUfB, WSUS, ConfigMgr Windows 10 Servicing), create a SetupConfig.ini file (roughly as described at https://blogs.technet.microsoft.com/mniehaus/2016/08/23/windows-10-1607-keeping-apps-from-coming-back-when-deploying-the-feature-update/), with a line that specifies:

        [SetupConfig]
        BitLocker=TryKeepAlive

        ->That last link says: "The SetupConfig.ini file, [as well as the batch file itself,] needs to be on the PC before running the upgrade.  The SetupConfig.ini needs to be placed at “%systemdrive%\Users\Default\AppData\Local\Microsoft\Windows\WSUS\SetupConfig.ini.” "

      • "is then only the system partition "open" or every other partition or internal drive as well?" - only the system partition.


    Monday, May 7, 2018 3:25 PM
  • You write "He can not boot the machine...?!" which is true, when it was off, when stolen. That's the distinction I am trying to emphasize the whole time. When it's off, then that preboot auth will help.

    I'm aware that I better have to lock the safe when I leave the house. :-)

    It´s just goofy that my landlord has a key to open the safe in case he wants to renovate the building
    without informing or asking me and even when I am not at home.
    But if a safety lock at the front door will prevents that, then I will go with this solution until finally my landlord does change his behaviour.

    Enough of this. :-)

    Ronald - thank you very much - you helped me a lot!
    Wednesday, May 9, 2018 1:29 AM
  • You are welcome.
    Wednesday, May 9, 2018 8:34 AM