DE v7.1 FAQ: Hardening systems against cold boot attacks

Version 6

    General

     

    Q: As a high level overview what is this functionality?

    On modern Windows platforms capable of supporting the new Connected Standby mode, the user is provided with an instant on, iPad like experience. These systems are always in a powered-on state requiring the encryption key to be always in RAM making them susceptible to memory scrubbing attacks that can scrub the encryption key from RAM.

     

    McAfee encryption can be operated behind the scenes delivering a native Windows experience to the end user. When the device enters the connected standby state, McAfee will erase the encryption key from RAM and move it to a secure area on Intel hardware hardening the system against coldboot and memory scrubbing attacks. When the device moves into an active state,the encryption key is transparently moved back to RAM after successful user authentication into Windows.

     

    The following sections go into some of the background andmore detail, include some technical details to explain this further.

    AOAC

     

    Q: What is AOAC?

    AOAC stands for “Always On, Always Connected”. Microsoft calls it “Connected Standby” and Intel refers to it as “Smart Connect”. They all basically refer to the same high level functionality. The ability to keep a system in a low power sleep mode, whereby periodically it will be woken up to retrieve data (ie emails, FaceBook updates, etc) and then go back to sleep again. All without the user knowing, or intervening. Think of it being similar to the way your mobile phone works.

     

     

    Q: How does AOAC change Full Disk Encryption?

    Full disk encryption has historically been about protection of data at rest (when the system is powered off). Various companies are introducing AOAC functionality and driving User expectation that their system will always contain fresh content.

     

     

    Q: But the system is sleeping, doesn’t that mean the data is at rest anyway?

    Actually no, the data is never at rest with the AOAC model. The systems are not powered off; they are only in standby. The AOAC model requires the disks to remain “unlocked” because:

    • Systems may wake periodically or via a push notification
    • Applications / Services may require access to the disk during this “awake” period

     

     

    Q: What is the problem with the AOAC Model?

    With the AOAC model, the system and services need to be able to access the disk. As such it means that the encryption key for the disk remains in memory at all times. This makes systems that support AOAC more vulnerable to cold boot style attacks because their key is always in memory.  Remember the system doesn't power down; it is only in standby.

     

     

    Q: Does DE v7.1support an AOAC Model?

    Yes, DE v7.1 will support AOAC through Connected Standby. While it is in this standby mode, the Windows login is used to protect the data from unauthorized access.

     

     

    Cold Boot Attack

     

    Q: What is the coldboot attack?

    A cold boot attack is a way of extracting sensitive data from system memory when the system is powered-on or in a standby state, even if the system is protected by a Windows password. The attack involves either hard rebooting the system and running a small program on the next boot cycle that scans system memory for sensitive information or involves removing the RAM from a powered-on system and translating to another system for scanning.

     

     

    Q: How does DE v7.1 harden these systems against a cold boot attack?

    When a system enters one of these modes DE v7.1 will remove the key from memory. It is stored in a secure location that is still accessible while in Connected Standby. The system will continue to function as an end user would expect, however the system is less vulnerable to a cold boot style attack as the key is no longer in memory.

     

     

    Q: Does McAfee guarantee that key is completely gone from memory?

    This functionality hardens the system against memory style attacks. While every effort has been taken to ensure that the key is removed from memory McAfee cannot guarantee that it is completely gone due to the way Windows manages memory. Further hardening work will be done on this in future releases.

     

     

    Q: Does all of the AOAC and Connected Standby functionality still work if I enable this functionality?

    Yes. We don’t want to destroy the end user experience that is created by using this technology. It will continue to work as expected.

     

     

    Q: Can I use this functionality with Pre-Boot and/or the AutoBoot functionality?

    This functionality will work regardless of your method of authentication. McAfee does recommend however that you either use pre-boot, or if AutoBoot is chosen then TPM AutoBoot + Reactive AutoBoot, or the integration with Intel’s AMT Technology.

     

    Technical Information

     

    Q: If I use this functionality, when is the key not in memory?

    After booting the system, the key does not get moved into memory until the user first authenticates to Windows.  Up until this point, through the pre-boot authentication environment and the boot of Windows itself, the key remains in the secure area.

     

    Once a user has authenticated to Windows. the key can be removed from memory:

    • When the system is powered off.
    • When the user logs off
    • When the user locks their workstation
    • Before the system is put to standby / sleep

    The key remains out of memory until the user authenticates back into Windows via a login or a screen unlock.  In Connected Standby or SmartConnect wake-up periods, the key remains secure and not in memory.

     

    Another way of easily looking at this: If the user has authenticated and they are at their desktop the key is in memory. If the user has not authenticated, and/or is not at their desktop the key is not in memory.

     

    An Administrator can select, via policy, under what conditions the key should be removed.

     

    Q: When is it put back in memory?

    The key is put back in memory only after a user has successfully authenticated to Windows. Simply having Windows running does not put the key back into memory.

     

     

    Q: If the key is not in memory, where is it?

    The key is held in a secure storage area that is not in memory.

     

     

    Q: Do you have multiple drivers to handle this?

    No, however it does operate in one of two modes. Those two modes are Standard Crypt and Elevated Security Crypt.

     

     

    Q: What is Standard Crypt Mode?

    It is a state of the encryption driver where:

    • Uses the same algorithm implementation as in previous v7.x releases
    • Encryption key is stored in RAM
    • Not secure against RAM based or Cold Boot Style attacks
    • Highly optimized for performance

     

     

    Q: What is the Elevated Security Crypt Mode?

    It is a state of the encryption driver where:

    • Uses a new implementation of the AES256-CBC encryption algorithm
    • Encryption key is stored in a secure location, not in RAM
    • Not susceptible to RAM based or Cold Boot Style attacks
    • Comes with a significant performance penalty
    • Policy enforcement is disabled while in this state.

     

     

    Q: When does it swap between the two modes?

    It is defined by policy, but as an example DE v7.1 can swap into the Elevated Security Crypt Mode when the system is:

    • Locked
    • Logged Off
    • In a standby mode

     

     

    Q: When does it swap back to the Standard Crypt Mode?

    Standard Crypt will resume when the user has successfully authenticated to Windows.

     

     

    Q: So the performance is lower, but as the user won't be actively using their system so it doesn't matter?

    During the normal use of a system, the user will not be actively using their system at this time. Yes, updates from Connected Standby will be slower in access the disks however as the user is not actively using their system at the time it will not be noticed.

     

     

    Q: Wait, so if I was to perform a high disk intensive task and lock my workstation and go to lunch does that mean it will run slower?

    Yes it will run slower, because you've locked your workstation and the system will be running in the Elevated Security Crypt Mode where the key is not in memory. As such you will have a performance penalty in performing the work.

     

     

    Q: Wait, does this also mean that my boot time will be slower in this mode?

    Yes that is correct. From the initial boot the key will not be stored in memory until the user has successfully authenticated to Windows. This is expected. If you're using a tablet you will rarely shutdown completely so this won't always be experienced.

     

     

    Q: So using this functionality is really a security versus performance trade-off?

    Yes it is. You're getting much better security but it does come with this trade-off. The important thing to remember is that when a user is actively using their system then the normal full performance will be experienced. It is only the periods where authentication has yet to occur that will experience the performance impact.

     

     

    Q: What type of performance impact are we talking about when the driver uses the Elevated Security Crypt mode?

    Simply looking at raw algorithm performance:

    • 64-bit AES-NI Capable processor
      • Standard Crypt = 1 CPU clock cycle / byte
      • Elevated Security Crypt = 15 CPU clock cycles / byte
    • 32-bit non-AES-NI capable processor
      • Standard Crypt = 35 CPU clock cycles / byte
      • Elevated Security Crypt = 133 CPU clock cycles / byte

     

    The impact can be significantly higher than this raw algorithm performance due to the algorithm being executed with interrupts disabled.

    Looking at this another way, purely as an example: If a system was experiencing a throughput of 208Mb/Second in Standard Crypt, it can drop to 20Mb/Second in Elevated Security Crypt.

     

     

    Q: Are there any hardware requirements for using this functionality?

    The system needs to support Connected Standby and it must be either a Clover Trail tablet or a Haswell system

     

    Q: Can this functionality be used in conjunction with TPM AutoBoot?

    Yes.  In TPM Autoboot mode, the key is also not resident in RAM until the user has authenticated to Windows.

     

    Q: Why is policy enforcement suspended whilst in the elevated mode?

    We suspend policy enforcement because certain operations performed during policy enforcement require the key to be in memory. Since the key cannot be put into memory whilst in elevated security mode, policy enforcement has to be suspended.

     

    Q: Why do I see policy enforcement failures in the MfeEpe.log whilst in elevated mode?

    The way that the elevated security mode integrates into the product means that such failure logging is, at the current time, unavoidable.  Such policy enforcement failures can be disregarded as long as they occur between the following messages in the log file:

     

         Crypt security has been elevated

     

         and

     

         Normal crypt security resumed

     

    More Technical Information

     

    Q: Is there a difference between Connected Standby and Smart Connect?

    Yes there is. Smart Connect is older fashioned in the sense that it has a driver that periodically wakes the system and dials into server to pull notifications. Connected Standby is a new technology where the system goes into a new power state on the CPU.

     

    Connected Standby requires new hardware support, whereas Smart Connect does not.  So you can have Smart Connect on a Windows 7 system with older CPU and hardware.

     

    Technically speaking, Smart Connect uses the power state S3– which is Sleep. Connected Standby uses the power state RTD3, which is a different state on the CPU.

     

     

    Q: Tell me more about Connected Standby?

    Connected Standby is not really a true sleep mode. It runs in this new power state and leaves some service running that can receive notifications from the server. As such it has hardware requirements and is available on Windows 8.x systems only.

     

     

    Q: What are the hardware requirements for Connected Standby?

    Windows 8 will take advantage of Connected Standby if all of the following hardware requirements are met:

    • A firmware flag indicating support for the standard
    • The boot volume must not use a rotational disk
    • Support for NDIS 6.30 by all network devices
    • Passive cooling when Connected Standby

    There are additional security-specific requirements, for example for memory to be soldered to the motherboard to prevent cold boot attack vectors that involve removing memory from the machine, as well as support for Secure Boot.