Hypnoguard: Protecting Secrets across Sleep-wake Cycles
Lianying Zhao and Mohammad Mannan
Concordia Institute for Information Systems Engineering
Concordia University, Montreal, Canada{z_lianyi, mmannan}@ciise.concordia.ca

ABSTRACT
Attackers can get physical control of a computer in sleep(S3/suspend-to-RAM), if it is lost, stolen, or the owner isbeing coerced. High-value memory-resident secrets, including disk encryption keys, and private signature/encryption
keys for PGP, may be extracted (e.g., via cold-boot or DMA
attacks), by physically accessing such a computer. Our goal
is to alleviate threats of extracting secrets from a computerin sleep, without relying on an Internet-facing service.
We propose Hypnoguard to protect all memory-resident
OS/user data across S3 suspensions, by first performing an
in-place full memory encryption before entering sleep, andthen restoring the plaintext content at wakeup-time throughan environment-bound, password-based authentication process. The memory encryption key is effectively “sealed” in a
Trusted Platform Module (TPM) chip with the measurement of the execution environment supported by CPU’s
trusted execution mode (e.g., Intel TXT, AMD-V/SVM).
Password guessing within Hypnoguard may cause the memory content to be permanently inaccessible, while guessing
without Hypnoguard is equivalent to brute-forcing a highentropy key (due to TPM protection). We achieved fullmemory encryption/decryption in less than a second on amainstream computer (Intel i7-4771 CPU with 8GB RAM,taking advantage of multi-core processing and AES-NI), an
apparently acceptable delay for sleep-wake transitions. To
the best of our knowledge, Hypnoguard provides the firstwakeup-time secure environment for authentication and key
unlocking, without requiring per-application changes.

1.

INTRODUCTION

Most computers, especially laptops, remain in sleep(S3/suspend-to-RAM), when not in active use (e.g., as ina lid-close event); see e.g., [49]. A major concern for unattended computers in sleep is the presence of user secrets insystem memory. An attacker with physical access to a computer in sleep (e.g., when lost/stolen, or by coercion) can
launch side-channel memory attacks, e.g., DMA attacks [37,53, 6, 57] by exploiting vulnerable device drivers; common
Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others thanACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission
and/or a fee. Request permissions from permissions@acm.org.

CCS’16, October 24-28, 2016, Vienna, Austriac 2016 ACM. ISBN 978-1-4503-4139-4/16/10. . . $15.00
DOI: http://dx.doi.org/10.1145/2976749.2978372

mitigations include: bug fixes, IOMMU (Intel VT-d/AMDVi), and disabling (FireWire) DMA when screen is locked(e.g., Mac OS X 10.7.2 and later, Windows 8.1 [37]). A sophisticated attacker can also resort to cold-boot attacks byexploiting DRAM memory remanence effect [25, 22]. Simpler techniques also exist for memory extraction (e.g., [16]);some tools (e.g., [14]) may bypass OS lock screen and extract
in-memory full-disk encryption (FDE) keys.
Some proposals address memory-extraction attacks bymaking the attacks difficult to launch, or by reducing applicability of known attacks (e.g., [47, 45, 56, 23, 63, 24];
see Section 8). Limitations of these solutions include: being too application-specific (e.g., disk encryption), not being
scalable (i.e., can support only a few application-specific secrets), and other identified flaws (cf. [5]). Most solutions also
do not consider re-authentication when the computer wakes
up from sleep. If a regular re-authentication is mandated(e.g., OS unlock), a user-chosen password may not provide
enough entropy against guessing attacks (offline/online).
Protecting only cryptographic keys also appears to be fundamentally inadequate, as there exists more privacy/security sensitive content in RAM than keys and passwords. Fullmemory encryption can be used to keep all RAM content
encrypted, as used in proposals for encrypted execution (seeXOM [36], and a comprehensive survey [27]). However, mostsuch proposals require hardware architectural changes.
Microsoft BitLocker can be configured to provide coldboot protection by relying on S4/suspend-to-disk instead of
S3. This introduces noticeable delays in the sleep-wake process. More importantly, BitLocker is not designed to withstand coercion and can provide only limited defence against
password guessing attacks (discussed more in Section 8).
We propose Hypnoguard to protect all memory-resident
OS/user data across S3 suspensions, against memory extraction attacks, and guessing/coercion of user passwords
during wakeup-time re-authentication. Memory extraction
is mitigated by performing an in-place full memory encryption before entering sleep, and then restoring the plaintext
content/secrets after the wakeup process. The memory encryption key is encrypted by a Hypnoguard public key, theprivate part of which is stored in a Trusted Platform Module (TPM v1.2) chip, protected by both the user password
and the measurement of the execution environment supported by CPU’s trusted execution mode, e.g., Intel Trusted
Execution Technology (TXT [30]) and AMD Virtualization(AMD-V/SVM [2]). The memory encryption key is thusbound to the execution environment, and can be released
only by a proper re-authentication process.

Guessing via Hypnoguard may cause the memory content
to be permanently inaccessible due to the deletion of the
TPM-stored Hypnoguard private key, while guessing without Hypnoguard, e.g., an attacker-chosen custom wakeup
procedure, is equivalent to brute-forcing a high-entropy key,
due to TPM protection. A user-defined policy, e.g., threefailed attempts, or a special deletion password, determines
when the private key is deleted. As a result, either the private key cannot be accessed due to an incorrect measurementof an altered program, or the adversary takes a high risk toguess within the unmodified environment.
By encrypting the entire memory space, except a few
system-reserved regions, where no OS/user data resides, weavoid per-application changes. We leverage modern CPU’s
AES-NI extension and multi-core processing to quickly encrypt/decrypt commonly available memory sizes (up to
8GB, under a second), for avoiding degraded user experience during sleep-wake cycles. For larger memory systems(e.g., 32/64GB), we also provide two variants, for encrypting memory pages of user selected applications, or specificHypnoguard-managed pages requested by applications.
Due to the peculiarity of the wakeup-time environment,
we face several challenges in implementing Hypnoguard. Unlike boot-time (when peripherals are initialized by BIOS)
or run-time (when device drivers in the OS are active), at
wakeup-time, the system is left in an undetermined state,e.g., empty PCI configuration space and uninitialized I/O
controllers. We implement custom drivers and reuse dormant (during S3) OS-saved device configurations to restore
the keyboard and VGA display to facilitate easy user input/output (inadequately addressed in the past, cf. [46]).
Several boot-time solutions (e.g., [31, 64, 70]) also perform system integrity check, authenticate the user, and may
release FDE keys; however, they do not consider memory attacks during sleep-wake cycles. For lost/stolen computers,some remote tracking services may be used to trigger remotedeletion, assuming the computer can be reached online (withdoubtful effectiveness, cf. [13, 62]).
Contributions:
1. We design and implement Hypnoguard, a new approachthat protects confidentiality of all memory regions containing OS/user data across sleep-wake cycles. We provide defense against memory attacks when the computeris in the wrong hands, and severely restrict guessing of
weak authentication secrets (cf. [70]). Several proposals and tools exist to safeguard data-at-rest (e.g., disk
storage), data-in-transit (e.g., network traffic), and datain-use (e.g., live RAM content); with Hypnoguard, we fill
the gap of securing data-in-sleep.
2. Our primary prototype implementation in Linux uses fullmemory encryption to avoid per-application changes. The
core part of Hypnoguard is decoupled from the underlying OS and system BIOS, for better portability andsecurity. Leveraging modern CPU’s AES-NI extension
and multi-core processing, we achieve around 8.7GB/s
encryption/decryption speed for AES in the CTR modewith an Intel i7-4771 processor, leading to under a second
additional delay in the sleep-wake process for 8GB RAM.
3. For larger memory systems (e.g., 32GB), where full memory encryption may add noticeable delay, we provide protection for application-selected memory pages via the
POSIX-compliant system call mmap() (requiring minorchanges in applications, but no kernel patches). Alter-

natively, Hypnoguard can also be customized to take alist of applications and only encrypt memory pages pertaining to them (no application changes).
4. We enable wakeup-time secure processing, previously unexplored, which can be leveraged for other use-cases, e.g.,
OS/kernel integrity check.

2.

TERMINOLOGIES, GOALS AND
THREAT MODEL

We explain the terminologies used for Hypnoguard, andour goals, threat model and operational assumptions. We
use CPU’s trusted execution mode (e.g., Intel TXT, AMDV/SVM), and the trusted platform module (TPM) chip. We
provide brief description of some features as used in our
proposal and implementation; for details, see, e.g., Parno etal. [48], Intel [30], and AMD [2].

2.1

Terminologies

Hypnoguard key pair (HGpub , HGpriv ): A pair of public
and private keys generated during deployment. The private key, HGpriv , is stored in a TPM NVRAM index, protected by both the measurement of the environment and the
Hypnoguard user password. HGpriv is retrieved through the
password evaluated by TPM with the genuine Hypnoguard
program running, and can be permanently deleted in accordance with a user-set policy. The public key, HGpub , isstored unprotected in TPM NVRAM (for OS/file system
independence), and is loaded in RAM after each boot.
Memory encryption key (SK): A high entropy symmetrickey (e.g., 128-bit), randomly generated each time before entering sleep, and used for full memory encryption. Before
the system enters sleep, SK is encrypted using HGpub andthe resulting ciphertext is stored in the small non-encrypted
region of memory.
Hypnoguard user password: A user-chosen password to unlock the protected key HGpriv at wakeup-time. It needs towithstand only a few guesses, depending on the actual unlocking policy. This password is unrelated to the OS unlock
password, which can be optionally suppressed.
TPM “sealing”: For protecting HGpriv in TPM, we use
the TPM_NV_DefineSpace command, which provides environment binding (similar to TPM_Seal, but stores HGpriv
in an NVRAM index) and authdata (password) protection. We use the term “sealing” to refer to this mechanism
for simplicity.

2.2

Goals

We primarily consider attacks targeting extraction of secrets through physical access to a computer in S3 sleep(unattended, stolen, or when the owner is under coercion).
We want to protect memory-resident secrets against sidechannel attacks (e.g., DMA/cold-boot attacks), but we do
not consider compromising a computer in S3 sleep for evilmaid type attacks (unbeknownst to the user).
More specifically, our goals include: (G1) Any user or OS
data (secrets or otherwise), SK, and HGpriv must not remainin plaintext anywhere in RAM before resuming the OS tomake memory attacks inapplicable. (G2) The protected content (in our implementation, the whole RAM) must not be
retrieved by brute-forcing SK or HGpriv , even if Hypnoguard
is not active, e.g., via offline attacks. (G3) No guessing attacks should be possible against the Hypnoguard user pass-

word, unless a genuine copy of Hypnoguard is loaded as the
only program in execution. (G4) The legitimate user shouldbe able to authenticate with routine effort, e.g., memorization of strong passwords is not required. (G5) Guessing theuser password when Hypnoguard is active should be severely
restricted by the penalty of having the secrets deleted.
An additional goal for coercion attacks during wakeup(similar to the boot-time protection of [70]): (AG1) whendeletion is successful, there should be a cryptographic evidence that convinces the adversary that the RAM secrets
are permanently inaccessible.

2.3

Threat model and assumptions

1. The adversary may be either an ordinary person withskills to mount memory/guessing attacks, or an organization (non-state) with coercive powers, and considerable
but not unbounded computational resources. For example, the adversary may successfully launch sophisticatedcold-boot attacks (e.g., [25, 22]), but cannot brute-force
a random 128-bit AES key, or defeat the TPM chip andCPU’s trusted execution environment (for known implementation bugs and attacks, see e.g., [59, 68, 54]); seealso Item (f) in Section 7.
2. Before the adversary gains physical control, the computer
system (hardware and OS) has not been compromised.
After the adversary releases physical control, or a lost
computer is found, the system is assumed to be untrustworthy, i.e., no further use without complete reinitialization. We thus only consider directly extracting secrets from a computer in sleep, excluding any attacks
that rely on compromising first and tricking the user to
use it later, the so-called evil-maid attacks, which canbe addressed by adapting existing defenses, e.g., [20] forwakeup-time. However, no known effective defense exists
for more advanced evil-maid attacks, including hardware
modifications as in NSA’s ANT catalog [21]. Note that,
our AES-GCM based implementation can restrict modification attacks on encrypted RAM content.
3. The host OS is assumed to be general-purpose, e.g., Windows or Linux; a TXT/SVM-aware kernel is not needed.
Also, the Hypnoguard tool may reside in an untrusted filesystem and be bootstrapped from a regular OS.
4. We assume all user data, the OS, and any swap spaceused by the OS are stored encrypted on disk, e.g., using a properly configured software/hardware FDE system (cf. [44, 12]). A secure boot-time solution should be
used to enforce strong authentication (cf. [70]). The FDE
key may remain in RAM under Hypnoguard’s protection.
This assumption can be relaxed, only if the data on disk
is assumed non-sensitive, or in the case of a diskless node.
5. Any information placed in memory by the user/OS istreated as sensitive. With full memory encryption, it
is not necessary to distinguish user secrets from nonsensitive data (e.g., system binaries).
6. The adversary must not be able to capture the computer
while it is operating, i.e., in Advanced Configuration andPower Interface (ACPI [1]) S0. We assume the computer
goes into sleep after a period of inactivity, or through user
actions (e.g., lid-close of a laptop).
7. The adversary may attempt to defeat Hypnoguard’s policy enforcement mechanism (i.e., when to delete or unlock
HGpriv during authentication). With physical access, hemay intervene in the wakeup process, e.g., by tampering

Figure 1: Memory layout and key usage of Hypnoguard.
Shaded areas represent encrypted/protected data; different
patterns refer to using different schemes/key types.
with the UEFI boot script for S3 [67], and may attempt
to observe the input and output of our tool and influence
its logic. In all cases, he will fail to access HGpriv , unlesshe can defeat TXT/SVM/TPM (via an implementation
flaw, or advanced hardware attacks).
8. In the case of coercion, the user never types the correct
password but provides only deletion or incorrect passwords, to trigger the deletion of HGpriv . Coercion has
been considered recently during boot-time [70], requiring the computer to be in a powered-off state before thecoercive situation. We consider coercion during wakeup;
ideally, both systems should be used together.
9. We require a system with a TPM chip and a TXT/SVMcapable CPU with AES-NI (available in many consumergrade Intel and AMD CPUs). Without AES-NI, fullmemory encryption will be slow, and users must resort
to partial memory encryption.

3.

DESIGNIn this section, we detail the architecture of Hypnoguard,
and demonstrate how it achieves the design goals stated in
Section 2.2. Technical considerations not specific to our current implementation are also discussed.
Overview. Figure 1 shows the memory layout and key
usage of Hypnoguard across sleep-wake cycles; the transitionand execution flows are described in Section 4.1. User secrets
are made unavailable from RAM by encrypting the wholesystem memory, regardless of kernel or user spaces, with a
one-time random symmetric key SK before entering sleep.
Then SK is encrypted using HGpub and stored in systemmemory. At this point, only HGpriv can decrypt SK. HGpriv
is sealed in the TPM chip with the measurements of thegenuine copy of Hypnoguard protected by a user password.
At wakeup-time, Hypnoguard takes control in a trusted
execution session (TXT/SVM), and prompts the user for
the Hypnoguard user password. Only when the correct pass-

word is provided in the genuine Hypnoguard environment,
HGpriv is unlocked from TPM (still in TXT/SVM). Then,
HGpriv is used to decrypt SK and erased from memory immediately. The whole memory is then decrypted with SK
and the system exits from TXT/SVM back to normal OS
operations. SK is not reused for any future session.

3.1

Design choices and elements

Trusted execution mode. We execute the unlocking program in the trusted mode of modern CPUs (TXT/SVM),
where an unforgeable measurement of the execution environment is generated and stored in TPM (used to access
HGpriv ). The use of TXT/SVM and TPM ensures thatthe whole program being loaded and executed will be reflected in the measurement; i.e., neither the measurement
can be forged at the load time nor can the measured program be altered after being loaded, e.g., via DMA attacks.
The memory and I/O space of the measured environmentis also protected, e.g., via Intel VT-d/IOMMU, from any
external access attempt.
We choose to keep Hypnoguard as a standalone module
separate from the OS for two reasons. (a) Small trusted
computing base (TCB): If Hypnoguard’s unlocking programis integrated with the OS, then we must also include OS
components (at least the kernel and core OS services) in
the TPM measurement; this will increase the TCB size significantly. Also, in a consumer OS, maintaining the correct measurements of such a TCB across frequent updates
and run-time changes, will be very challenging. Unless measuring the entire OS is the purpose (cf. Unicorn [38]), a
TXT/SVM-protected application is usually a small piece ofcode, not integrated with the OS, to achieve a stable andmanageable TCB (e.g., Flicker [40]). In our case, only thecore Hypnoguard unlock logic must be integrity-protected(i.e., bound to TPM measurement). The small size may also
aid manual/automatic verification of the source code of an
implementation. (b) Portability: We make Hypnoguard lesscoupled with the hosting OS except for just a kernel driver,as we may need to work with different distributions/versionsof an OS, or completely different OSes.
TPM’s role. TPM serves three purposes in Hypnoguard:
1. By working with TXT/SVM, TPM’s platform configuration registers (PCRs) maintain the unforgeable measurement of the execution environment.
2. We use TPM NVRAM to store HGpriv safely with twolayers of protection. First, HGpriv is bound to the Hypnoguard environment (e.g., the Intel SINIT module andthe Hypnoguard unlocking program). Any binary otherthan the genuine copy of Hypnoguard will fail to access HGpriv . Second, an authdata secret, derived fromthe Hypnoguard user password, is also used to protect
HGpriv . Failure to meet either of the above two conditions will lead to denial of access.
3. If HGpriv is deleted by Hypnoguard (e.g., triggered via
multiple authentication failures, or the entry of a deletion
password), we also use TPM to provide a quote, which is adigest of the platform measurement signed by the TPM’s
attestation identity key (AIK) seeded with an arbitraryvalue (e.g., time stamp, nonce). Anyone, including theadversary, can verify the quote using TPM’s public key
at a later time, and confirm that deletion has happened.
4. For generation of the long-term key pair HGpriv andHGpub , and the per-session symmetric key SK, we need areliable source of randomness. We use the TPM_GetRandom
command to get the required number of bytes from therandom number generator in TPM [60] (and optionally,
mix them with the output from the RDRAND instruction
in modern CPUs).
Necessity of HGpriv and HGpub . Although we use random per sleep-wake cycle symmetric key (SK) for full memory encryption, we cannot directly seal SK in TPM (under the Hypnoguard password), i.e., avoid using (HGpriv ,HGpub ). The reason is that we perform the platform-bounduser re-authentication only once at the wakeup time, andwithout involving the user before entering sleep, we cannot
password-seal SK in TPM. If the user is required to enter the
Hypnoguard password every time before entering sleep, theuser experience will be severely affected. We thus keep SK
encrypted under HGpub in RAM, and involve the password
only at wakeup-time to release HGpriv (i.e., the password
input is similar to a normal OS unlock process).

3.2

Unlock/deletion policy and deployment

Unlocking policy. A user-defined unlocking policy will
determine how Hypnoguard reacts to a given password, i.e.,
what happens when the correct password is entered vs. whena deletion or invalid password is entered. If the policy allows many/unlimited online (i.e., via Hypnoguard) guessing
attempts, a dictionary attack might be mounted, violating
goal G5 ; the risk to the attacker in this case is that he might
unknowingly enter the deletion password. If the compositionof the allowed password is not properly chosen (e.g., different character sets for the correct password and the deletion
password), an adversary may be able to recognize the typesof passwords, and thus avoid triggering deletion.
Static policies can be configured with user-selected passwords and/or rule-based schemes that support evaluating anentered password at run-time. Security and usability tradeoffs should be considered, e.g., a quick deletion trigger vs.
tolerating user mistyping or misremembering (cf. [11]). During setup, both unlocking and deletion passwords are chosen by the user, and they are set as the access passwords forcorresponding TPM NVRAM indices: the deletion password
protects an index with a deletion indicator and some random
data (as dummy key), and the unlocking password protects
an index containing a null indicator and HGpriv (similar
to [70]). Note that, both the content and deletion indicatorof an NVRAM index are protected (i.e., attackers cannot
exploit the indicator values). Multiple deletion passwords
can also be defined. We also use a protected monotonic
counter to serve as a fail counter, sealed under Hypnoguard,
and initialized to 0. We use a regular numeric value sealedin NVRAM (i.e., inaccessible outside of Hypnoguard); theTPM monotonic counter facility can also be used. The failcounter is used to allow only a limited number of incorrect
attempts, after which, deletion is triggered; this is specifically important to deal with lost/stolen cases.
At run-time, only when the genuine Hypnoguard programis active, the fail counter is incremented by one, and a typed
password is used to attempt to unlock the defined indices,sequentially, until an index is successfully opened, or all theindices are tried. In this way, the evaluation of a password
is performed only within the TPM chip and no information
about any defined plaintext passwords or HGpriv is leaked
in RAM—leaving no chance to cold-boot attacks. If a typed
password successfully unlocks an index (i.e., a valid pass-

word), the fail counter is decremented by one; otherwise,
the password entry is considered a failed attempt and theincremented counter is not decremented. When the counterreaches a preset threshold, deletion is triggered. The counteris reset to 0 only when the correct password is entered (i.e.,
HGpriv is successfully unlocked). Thus, a small threshold (e.g., 10) may provide a good balance between security(quick deletion trigger) and usability (the number of incorrect entries that are tolerated). For high-value data, thethreshold may be set to 1, which will trigger deletion immediately after a single incorrect entry.
Deployment/setup phase. With a setup program in theOS, we generate a 2048-bit RSA key pair and save HGpub
in TPM NVRAM (unprotected), and ask the user to create
her passwords for both unlocking and deletion. With theunlocking password (as authdata secret), HGpriv is stored
in an NVRAM index, bound to the expected PCR valuesof the Hypnoguard environment at wakeup (computed analytically); similarly, indices with deletion indicators are allocated and protected with the deletion password(s). Thereis also certain OS-end preparation, e.g., loading and initializing the Hypnoguard device drivers; see Section 4.1.

3.3

How goals are achieved

Hypnoguard’s goals are defined in Section 2.2. G1 is fulfilled by Hypnoguard’s full memory encryption, i.e., replacement of all plaintext memory content, with corresponding
ciphertext generated by SK. As the OS or applications are
not involved, in-place memory encryption can be performed
reliably. SK resides in memory encrypted under HGpub(right after full memory encryption is performed under SK).
HGpriv can only be unlocked with the correct environment
and password at wakeup-time, and is erased from RAM rightafter its use in the trusted execution mode.
A random SK with adequate length generated each time
before entering sleep, and a strong public key pair (HGpub ,HGpriv ) generated during setup guarantee G2.
TPM sealing (even with a weak Hypnoguard user password) helps achieve G3. Without loading the correct binary,
the adversary cannot forge the TPM measurement and trick
TPM to access the NVRAM index (cf. [30, 60]); note that,learning the expected PCR values of Hypnoguard does nothelp the attacker in any way. The adversary is also unable
to brute-force the potentially weak user password, if he iswilling to program the TPM chip without Hypnoguard, as
TPM ensures the consistent failure message for both incorrect passwords and incorrect measurements.
The user is required to memorize a regular password forauthentication. If the adversary keeps the genuine environment but does not know the correct password, he may be
only left with a high risk of deleting HGpriv . The legitimate
user, however, knows the password and can control the riskof accidental deletion, e.g., via setting an appropriate deletion threshold. Therefore G4 is satisfied.
When the adversary guesses within Hypnoguard, the password scheme (unlocking policy) makes sure that no (or only
a few, for better usability) guessing attempts are allowed
before deletion is triggered. This achieves G5.
The additional goal for coercion attacks is achieved throughthe TPM Quote operation. The quote value relies on mainly
two factors: the signing key, and the measurement to besigned. An RSA key pair in TPM called AIK (Attestation
Identity Key) serves as the signing key. Its public part issigned by TPM’s unique key (Endorsement Key, aka. EK,
generated by the manufacturer and never leaves the chip in
any operations) and certified by a CA in a separate process(e.g., during setup). This ensures the validity of the signature. The data to be signed is the requested PCR values. In
TXT, the initial PCR value is set to 0, and all subsequent
extend operations will update the PCR values in an unforgeable manner (via SHA1). As a result, as long as the quote
matches the expected one, the genuine copy of the program
must have been executed, and thus AG1 is achieved.

4.

IMPLEMENTATIONIn this section, we discuss our implementation of Hypnoguard under Linux using Intel TXT as the trusted execution provider. Note that Hypnoguard’s design is OSindependent, but our current implementation is Linux specific; the only component that must be developed for other
OSes is HypnoOSService (see below). We also performed
an experimental evaluation of Hypnoguard’s user experience (for 8GB RAM); no noticeable latency was observed
at wakeup-time (e.g., when the user sees the lit-up screen).
We assume that a delay under a second before entering sleep
and during wakeup is acceptable. For larger memory sizes(e.g., 32GB), we implement two variants to quickly encrypt
selected memory regions.

4.1

Overview and execution steps

The Hypnoguard tool consists of three parts: HypnoCore (the unlocking logic and cipher engine), HypnoDrivers(device drivers used at wakeup-time), and HypnoOSService(kernel service to prepare for S3 and HypnoCore). HypnoCore and HypnoDrivers operate outside of the OS, andHypnoOSService runs within the OS. The approximate code
size of our implementation is: HypnoCore, 7767 LOC (inC/C++/assembly, including reused code for TPM, AES, RSA,
SHA1); HypnoDrivers, 3263 LOC (in C, including reusedcode for USB); HypnoOSService, 734 LOC in C; GCM,
2773 LOC (in assembly, including both the original and ouradapted constructions); and a shared framework between
the components, 639 LOC in assembly.
Execution steps. Figure 2 shows the generalized execution steps needed to achieve the designed functionalities
on an x86 platform. (a) The preparation is done by HypnoOSService at any time while the OS is running before S3
is triggered. HypnoCore, HypnoDrivers, ACM module for
TXT, and the TXT policy file are copied into fixed memory locations known by Hypnoguard (see Section 4.3). Also,
HypnoOSService registers itself to the OS kernel so that if
the user or a system service initiates S3, it can be invoked.
(b) Upon entry, necessary parameters for S3/TXT are prepared and stored (those that must be passed from the active
OS to Hypnoguard), and the kernel’s memory tables are replaced with ours, mapped for HypnoCore and HypnoDrivers.
(c) Then, HypnoCore encrypts the whole memory in a very
quick manner through multi-core processing with AES CTR
mode using SK. SK is then encrypted by HGpub (an RSA2048 key). Before triggering the actual S3 action by sending
commands to ACPI, Hypnoguard must replace the original
OS waking vector to obtain control back when the machine
is waken up. (d) At S3 wakeup, the 16-bit realmode entry,
residing below 1MB, of Hypnoguard waking vector is triggered. It calls HypnoDrivers to re-initialize the keyboard
and display, and prepares TXT memory structures (TXT

Figure 2: Simplified execution steps of Hypnoguardheap) and page tables. (e) Then the user is prompted fora password, which is used to unlock TPM NVRAM indices
one by one. Based on the outcome and the actual unlocking
policy, either deletion of HGpriv happens right away and aquote is generated for further verification (and the system
is restarted), or if the password is correct, HGpriv is unlocked into memory. After decrypting SK, HGpriv is erased
promptly from memory. HypnoCore then uses SK to decrypt the whole memory. (f) TXT is torn down, and the OS
is resumed by calling the original waking vector.
Machine configuration. We use an Intel platform running
Ubuntu 15.04 (kernel version: 3.19.0). The development
machine’s configuration includes: an Intel Core i7-4771 processor (3.50 GHz, 4 physical cores), with Intel’s integrated
HD Graphics 4600, Q87M-E chipset, 8GB RAM (Kingston
DDR3 4GBx2, clock speed 1600 MHz), and 500GB Seagate
self-encrypting drive. In theory, our tool should work on
most machines with TPM, AES-NI and Intel TXT (or AMD
SVM) support, with minor changes, such as downloading thecorresponding SINIT module.

4.2

Instrumenting the S3 handler

Hypnoguard needs to gain control at wakeup-time before
the OS resume process begins. For simplicity, we follow
the method as used in a similar scenario in Intel tboot [31].
An x86 system uses ACPI tables to communicate with thesystem software (usually the OS) about power management
parameters. The firmware waking vector, contained in the
Firmware ACPI Control Structure (FACS), stores the address of the first instruction to be executed after wakeup;
and to actually put the machine to sleep, certain platformspecific data, found in the Fixed ACPI Description Table(FADT), must be written to corresponding ACPI registers.
We must register Hypnoguard with an OS callback for replacing the waking vector, so as not to interfere with normal
OS operations. In Linux, the acpi os prepare sleep() callback can be used, which will be invoked in the kernel space
before entering sleep. However, we cannot just replace thewaking vector in this callback and return to the OS, as Linux
overwrites the waking vector with its own at the end of S3
preparation, apparently, to ensure a smooth resume. Fortunately, the required data to be written to ACPI registers isalready passed in as arguments by the kernel, and as the OS
is ready to enter sleep, we put the machine to sleep without
returning to the OS.

4.3

Memory considerations

To survive across various contexts (Linux, non-OS native,

initial S3 wakeup and TXT), and not to be concerned withpaging and virtual memory addressing, we reserve a region
from the system memory by providing a custom version of
the e820 map, so that Linux will not touch it afterwards.
This is done by appending a kernel command line parameter memmap. In Windows, this can be done by adding
those pages to BadMemoryList. 1 MB space at 0x900000 isallocated for HypnoCore, HypnoDrivers and miscellaneous
parameters to be passed between different states, e.g., the
SINIT module, original waking vector of Linux, policy data,
stack space for each processor core, and Intel AES-NI library(see Section 5).
Full memory coverage in 64-bit mode. To support
more than 4GB memory sizes, we need to make Hypnoguard
64-bit addressable. However, we cannot simply compile theHypnoguard binary into 64-bit mode as most other modules, especially those for TXT and TPM access, are only
available in 32-bit mode, and adapting them to 64-bit will
be non-trivial (if possible), because of the significantly different nature of 64-bit mode (e.g., mandatory paging).
We keep HypnoCore and HypnoDrivers unchanged, andwrite a trampoline routine for the 64-bit AES-NI library,where we prepare paging and map the 8GB memory before
switching to the long mode (64-bit). After the AES-NI library call, we go back to 32-bit mode. Also, the x86 calling
conventions may be different than x86-64 (e.g., use of stackspace vs. additional registers). A wrapper function, before
the trampoline routine goes to actual functions, is used to
extract those arguments from stack and save them to corresponding registers. In this way, the 64-bit AES-NI libraryruns as if the entire HypnoCore and HypnoDrivers binary is
64-bit, and thus we can access memory regions beyond 4GB,
while the rest of Hypnoguard still remains in 32-bit mode.

4.4

User interaction

In a regular password-based wakeup-time authentication,
the user is shown the password prompt dialog to enter the
password. In addition to the password input, we also needto display information in several instances, e.g., interactingwith the user to set up various parameters during deployment, indicating when deletion is triggered, and displaying
the quote (i.e., proof of deletion). Providing both standard
input and output is easy at boot-time (with BIOS support),
and within the OS. However, resuming from S3 is a special
situation: no BIOS POST is executed, and no OS is active. At this time, peripherals (e.g., PCI, USB) are left in
an uninitialized state, and unless some custom drivers are
implemented, display and keyboard remain nonfunctional.

For display, we follow a common practice as used in Linuxfor S3 resume (applicable for most VGA adapters). HypnoDrivers invoke the legacy BIOS video routine using “lcallw
0xc000,3” (0xc0000 is the start of the VGA RAM where thevideo BIOS is copied to; the first 3 bytes are the signatureand size of the region, and 0xc0003 is the entry point).
For keyboard support, the S3 wakeup environment is morechallenging (PS/2 keyboards can be easily supported via a
simple driver). Most desktop keyboards are currently connected via USB, and recent versions of BIOS usually havea feature called “legacy USB support”. Like a mini-OS, aspart of the power-on check, the BIOS (or the more recent
UEFI services) would set up the PCI configuration space,
perform USB enumeration, and initialize the class drivers(e.g., HID and Mass Storage). But when we examined the
USB EHCI controller that our USB keyboard was connected
to, we found that its base address registers were all zeros at
wakeup-time, implying that it was uninitialized (same forvideo adapters). As far as we are aware, no reliable mechanisms exist for user I/O after wakeup. TreVisor [46] resorted
to letting the user input in a blank screen (i.e., keyboard was
active, but VGA was uninitialized). Note that the actual
situation is motherboard-specific, determined mostly by theBIOS. We found that only one out of our five test machines
has the keyboard initialized at wakeup-time.
Loading a lightweight Linux kernel might be an option,
which would increase the TCB size and (potentially) introduce additional attack surface. Also, we must execute thekernel in the limited Hypnoguard-reserved space. Instead,
we enable USB keyboard support as follows:
1. Following the Linux kernel functions pci save state() andpci restore config space(), we save the PCI configuration
space before entering S3, and restore it at wakeup-time
to enable USB controllers in Hypnoguard.
2. We borrow a minimal set of functions from the USB stackof the GRUB project, to build a tiny USB driver only for
HID keyboards operating on the “boot protocol” [61].
3. There are a few unique steps performed at boot-time
for USB initialization that cannot be repeated during S3
wakeup. For instance, a suspended hub port (connecting the USB keyboard) is ready to be waken up by thehost OS driver and does not accept a new round of enumeration (e.g., getting device descriptor, assigning a new
address). We thus cannot reuse all boot-time USB initialization code from GRUB. At the end, we successfullyreconfigure the USB hub by initiating a port reset first.
With the above approach, we can use both the USB keyboard and VGA display at wakeup-time. This is hardwareagnostic, as restoring PCI configuration simply copies existing values, and the USB stack as reused from GRUB follows
a standard USB implementation. We also implement an
i8042 driver (under 100 LOC) to support PS/2 keyboards.
Our approach may help other projects that cannot rely on
the OS/BIOS for input/output support, e.g., [46, 15].

4.5

Moving data aroundHypnoguard operates at different stages, connected by
jumping to an address without contextual semantics. Conventional parameter passing in programming languages andshared memory access are unavailable between these stages.
Therefore, we must facilitate binary data transfer between
the stages. To seamlessly interface with the host OS, weapply a similar method as in Flicker [40] to create a sysfs

object in a user-space file system. It appears in the directory“/sys/kernel” as a few subdirectories and two files: data (foraccepting raw data) and control (for accepting commands).
In HypnoOSService, the sysfs handlers write the received
data to the 1MB reserved memory region. When S3 is triggered, HypnoDrivers will be responsible for copying the required (portion of) binary to a proper location, for instance,
the real-mode wakeup code to 0x8a000, SINIT to the BIOSdetermined location SINIT.BASE and the LCP policy to the
OsMleData table, which resides in the TXT heap preparedby HypnoDrivers before entering TXT.

4.6

Unencrypted memory regions

In our full memory encryption, the actual encrypted addresses are not contiguous. We leave BIOS/hardware reserved regions unencrypted, which fall under two categories.
(a) MMIO space: platform-mapped memory and registers of
I/O devices, e.g., the TPM locality base starts at 0xfed40000.
(b) Platform configuration data: memory ranges used by
BIOS/UEFI/ACPI; the properties of such regions vary significantly, from read-only to non-volatile storage.
Initially, when we encrypted the whole RAM, including
the reserved regions, we observed infrequent unexpected system behaviors (e.g., system crash). As much as we are awareof, no user or OS data is stored in those regions (cf. [33]), andthus there should be no loss of confidentiality due to keeping those regions unencrypted. Hypnoguard parses the e820
(memory mapping) table to determine the memory regions
accessible by the OS. In our test system, there is approximately 700MB reserved space, spread across different ranges
below 4GB. The amount of physical memory is compensatedby shifting the addresses, e.g., for our 8GB RAM, the actual
addressable memory range goes up to 8.7GB.

5.

HIGH-SPEED FULL MEMORY ENCRYPTION AND DECRYPTION

The adoptability of the primary Hypnoguard variant basedon full memory encryption/decryption mandates a minimal
impact on user experience. Below, we discuss issues related
to our implementation of quick memory encryption.
For all our modes of operation with AES-NI, the processing is 16-byte-oriented (i.e., 128-bit AES blocks) and handled in XMM registers. In-place memory encryption/decryption is intrinsically supported by taking an input blockat a certain location, and overwriting it with the output of
the corresponding operation. Therefore, no extra memoryneeds to be reserved, and thus no performance overhead fordata transfer is incurred.

5.1

Enabling techniques

Native execution. We cannot perform in-place memory
encryption when the OS is active, due to OS memory protection and memory read/write operations by the OS. Thus,
the OS must be inactive when we start memory encryption.
Likewise, at wakeup-time in TXT, there is no OS run-time
support for decryption. We need to perform a single-block
RSA decryption using HGpriv to decrypt the 128-bit AES
memory encryption key SK. On the other hand, we need fast
AES implementation to encrypt the whole memory (e.g.,8GB), and thus, we leverage new AES instructions in modern CPUs (e.g., Intel AES-NI). AES-NI offers significant performance boost (e.g., about six times in one test [8]). Al-though several crypto libraries now enable easy-to-use support for AES-NI, we cannot use such libraries, or the kernelshipped library, as we do not have the OS/run-time support. We use Intel’s AES-NI library [52], with minor but
non-trivial modifications (discussed in our tech report [71]).
OS-less multi-core processing. Outside the OS, no easyto-use parallel processing interface is available. With one
processor core, we achieved 3.3–4GB/s with AES-NI, which
would require more than 2 seconds for 8GB RAM (still lesssatisfactory, considering 3 cores being idle). Thus, to leverage multiple cores, we develop our own multi-core processing
engine, mostly following the Intel MultiProcessor Specification [32]. Our choice of decrypting in TXT is non-essential,
as SK is generated per sleep-wake cycle and requires no TXT
protection; however, the current logic is simpler and requires
no post-TXT cleanup for native multi-core processing.
Modes of operation. Intel’s AES-NI library offers ECB,CTR and CBC modes. We use AES in CTR mode as thedefault option (with a random value as the initial counter);compared to CBC, CTR’s performance is better, and symmetric between encryption and decryption speeds (recall
that CBC encryption cannot be parallelized due to chaining). In our test, CBC achieves 4.5GB/s for encryption and
8.4GB/s for decryption. In CTR mode, a more satisfactory performance is achieved: 8.7GB/s for encryption and
8.5GB/s for decryption (approximately).
When ciphertext integrity is required to address content
modification attacks, AES-GCM might be a better trade-off
between security and performance. We have implemented aHypnoguard variant with a custom, performance-optimized
AES-GCM mode; for implementation details and challenges,
see our tech report [71].

5.2

Performance analysis

Relationship between number of CPU cores and performance. For AES-CTR, we achieved 3.3–4GB/s (3.7GB/s
on average), using a single core. After a preliminary evaluation, we found the performance is not linear to the numberof processor cores, i.e., using 4 cores does not achieve thespeed of 16GB/s, but at most 8.7GB/s (8.3GB/s on 3 coresand 7.25GB/s on 2 cores).
A potential cause could be Intel Turbo Boost [9] that
temporarily increases the CPU frequency when certain limits are not exceeded (possibly when a single core is used).
Suspecting the throughput of the system RAM to be theprimary bottleneck (DDR3), we performed benchmark tests
with user-space tools, e.g., mbw [28], which simply measures
memcpy and variable assignment for an array of arbitrary
size. The maximum rate did not surpass 8.3GB/s, possibly
due to interference from other processes.
During the tests with GCM mode, our observation demonstrates the incremental improvement of our implementation:
2.5GB/s (1-block decryption in C using one core), 3.22GB/s(1-block decryption in C using four cores), 3.3GB/s (4-block
decryption in C using four cores), 5GB/s (4-block decryption in assembly using four cores), and 6.8GB/s (4-block
decryption in assembly with our custom AES-GCM [71]).
The encryption function in assembly provided by Intel already works satisfactorily, which we do not change further.
The performance numbers are listed in Table 1.
At the end, when ciphertext integrity is not considered(the default option), 8.7GB/s in CTR mode satisfies ourrequirement of not affecting user experience, specifically, forsystems up to 8GB RAM. When GCM is used for ciphertext
integrity, we achieve 7.4GB/s for encryption and 6.8GB/s
for decryption (i.e., 1.08 seconds for entering sleep and 1.18
seconds for waking up, which is very close to our 1-second
delay limit). Note that, we have zero run-time overhead,after the OS is resumed.

6.

VARIANTS

For systems with larger RAM (e.g., 32GB), Hypnoguard
may induce noticeable delays during sleep-wake cycles, if thewhole memory is encrypted. For example, according to ourcurrent performance (see Section 5), if a gaming system has
32GB RAM, it will take about four seconds for both entering sleep and waking up (in CTR mode), which might beunacceptable. To accommodate such systems, we propose
two variants of Hypnoguard, where we protect (i) all memory pages of selected processes—requires no modifications
to applications; and (ii) selected security-sensitive memory
pages of certain processes—requires modifications. Note
that, these variants require changes in HypnoOSService, but
HypnoCore and HypnoDrivers remain unchanged (i.e., unaffected by the OS-level implementation mechanisms).
(i) Per-process memory encryption. Compared to thedesign in Section 3, this variant differs only at the choiceof the encryption scope. It accepts a process list (e.g.,
supplied by the user) and traverses all memory pages allocated to those processes to determine the scope of encryption. We retrieve the virtual memory areas (VMA, of type− mm −>− mmap of each provm area struct) from task −>cess. Then we break the areas down into memory pages (inour case, 4K-sized) before converting them over to physicaladdresses. This is necessary even if a region is continuous
as VMAs, because the physical addresses of corresponding
pages might not be continuous. We store the page list in
Hypnoguard-reserved memory.
Our evaluation shows that the extra overhead of memory traversal is negligible. This holds with the assumptionthat the selected apps are allocated a small fraction of alarge memory; otherwise, the full memory or mmap-based
variant might be a better choice. For smaller apps such as
bash (38 VMAs totaling 1,864 pages, approximately 7MB),
it takes 5 microseconds to traverse through and build thelist. For large apps such as Firefox (723 VMAs totaling
235,814 pages, approximately 1GB), it takes no more than
253 microseconds. Other apps we tested are Xorg (167 microseconds) and gedit (85 microseconds). We are yet to fully
integrate this variant into our implementation (requires amore complex multi-core processing engine).
(ii) Hypnoguard-managed memory pages via mmap().
There are also situations where a memory-intensive application has only a small amount of secret data to protect.
Assuming per-application changes are acceptable, we implement a second variant of Hypnoguard that exposes a filesystem interface compliant with the POSIX call mmap(),
allowing applications to allocate pages from a Hypnoguardmanaged memory region.
The mmap() function is defined in the file operations structure, supported by kernel drivers exposing a device node in
the file system. An application can request a page to bemapped to its address space on each mmap call, e.g., insteadof calling malloc(). On return, a virtual address mappedCTR (1-core)
CTR
CBC
GCM-C1 (1-core) GCM-C1 GCM-C4 GCM-A4 GCM-A4T
Encryption
3.7GB/s
8.7GB/s 4.5GB/s————
7.4GB/s
Decryption
3.7GB/s
8.7GB/s 8.4GB/s
2.5GB/s
3.22GB/s 3.3GB/s
5GB/s
6.8GB/s
Table 1: A comparative list of encryption/decryption performance. Column headings refer to various modes of operation,
along with the source language (when applicable; A represents assembly); the trailing number is the number of blocks processed
at a time. A4T is our adapted GCM implementation in assembly processing 4 blocks at a time, with delayed tag verification(see [71]); — means not evaluated.
into the application’s space is generated by Hypnoguard using remap pfn range(). An application only needs to callmmap(), and use the returned memory as its own, e.g., tostore its secrets. Then the page is automatically protectedby Hypnoguard the same way as the full memory encryption,i.e., encrypted before sleep and decrypted at wakeup. The
application can use multiple pages as needed. We currently
do not consider releasing such pages (i.e., no unmap()), as
we consider a page to remain sensitive once it has been used
to store secrets. Note that, no kernel patch is required tosupport this variant. We tested it with our custom application requesting pages to protect its artificial secrets. We
observed no latency or other anomalies.

7.

SECURITY ANALYSIS

Below, we discuss potential attacks against Hypnoguard;
see also Sections 2.3 and 3.3 for related discussion.
(a) Cold-boot and DMA attacks. As no plaintext secrets exist in memory after the system switches to sleep
mode, cold-boot or DMA attacks cannot compromise memory confidentiality; see Section 3.3, under G1. Also, thepassword evaluation process happens inside the TPM (asTPM receives it through one command and compares with
its preconfigured value; see Section 3.2), and thus the correct password is not revealed in memory for comparison.
At wakeup-time, DMA attacks will also fail due to memory
access restrictions (TXT/VT-d).
(b) Reboot-and-retrieve attack. The adversary can
simply give up on waking back to the original OS session,and soft-reboot the system from any media of his choice, todump an arbitrary portion of the RAM, with most content
unchanged (the so-called warm boot attacks, e.g., [10, 66,65]). Several such tools exist, some of which are applicableto locked computers, see e.g., [16]. With Hypnoguard, as
the whole RAM is encrypted, this is not a threat any more.
(c) Consequence of key deletion. The deletion of HGpriv
severely restricts guessing attacks on lost/stolen computers.
For coercive situations, deletion is needed so that an attacker
cannot force users to reveal the Hypnoguard password after
taking a memory dump of the encrypted content. Although
we use a random AES key SK for each sleep-wake cycle,
simply rebooting the machine without key deletion may not
suffice, as the attacker can store all encrypted memory content, including SK encrypted by HGpub . If HGpriv can belearned afterwards (e.g., via coercion of the user password),
the attacker can then decrypt SK, and reveal memory content for the target session.
If a boot-time anti-coercion tool, e.g., Gracewipe [70] is
integrated with Hypnoguard, the deletion of HGpriv may
also require triggering the deletion of Gracewipe secrets.
Hypnoguard can easily trigger such deletion by overwriting TPM NVRAM indices used by Gracewipe, which wehave verified in our installation. From a usability perspective, the consequence of key deletion in Hypnoguard is toreboot and rebuild the user secrets in RAM, e.g., unlock-ing an encrypted disk, password manager, or logging backinto security-sensitive websites. With Gracewipe integration, triggering deletion will cause loss of access to disk data.
(d) Compromising the S3 resume path. We are unaware of any DMA attacks that can succeed when the system
is in sleep, as such attacks require an active protocol stack(e.g., that of FireWire). Even if the adversary can use DMA
attacks to alter RAM content in sleep, bypassing Hypnoguard still reveals no secrets, due to full memory encryption
and the unforgeability of TPM measurements. Similarly,
replacing the Hypnoguard waking vector with an attacker
chosen one (as our waking vector resides in memory unencrypted), e.g., by exploiting vulnerabilities in UEFI resume
boot script [33, 67] (if possible), also has no effect on memory
confidentiality. Any manipulation attack, e.g., insertion ofmalicious code via a custom DRAM interposer, on the encrypted RAM content to compromise the OS/applications
after wakeup is addressed by our GCM mode implementation (out of scope for the default CTR implementation).
(e) Interrupting the key deletion. There have been a
few past attacks about tapping TPM pins to detect the deletion when it is triggered (for guessing without any penalty).
Such threats are discussed elsewhere (e.g., [70]), and can beaddressed, e.g., via redundant TPM write operations.
(f ) Other hardware attacks. Ad-hoc hardware attacks
to sniff the system bus for secrets (e.g., [7]) are generally
inapplicable against Hypnoguard, as no secrets are processed
before the correct password is entered. For such an example
attack on Xbox, see [29], which only applies to architectureswith LDT (HyperTransport) bus, not Intel’s FSB.
However, more advanced hardware attacks may allow direct access to the DRAM bus, and even extraction of TPM
secrets with an invasive decapping procedure (e.g., [59], seealso [26] for more generic physical attacks on security chips).
Note that the PC platform (except the TPM chip to someextent) cannot withstand such attacks, as components fromdifferent manufactures need to operate through common interfaces (vs. more closed environment such as set-top boxes).
With TPMs integrated into the Super I/O chip, and specifically, with firmware implementation of TPM v2.0 (fTPM
as in Intel Platform Trust Technology), decapping attacks
may be mitigated to a significant extent (see the discussionin [50] for discrete vs. firmware TPMs). Hypnoguard shouldbe easily adapted to TPM v2.0.

8.

RELATED WORKIn this section, we primarily discuss related work on memory attacks and preventions. Proposals for addressing changeof physical possession (e.g., [55, 17]) are not discussed, as
they do not consider memory attacks.
Protection against cold-boot and DMA attacks. Solutions to protecting keys exposed in system memory havebeen extensively explored in the last few years, apparently,
due to the feasibility of cold-boot attacks [25]. There have

been proposals based on relocation of secret keys from RAM
to other “safer” places, such as SSE registers (AESSE [43]),
debug registers (TRESOR [45]), MSR registers (Amnesia [56]), AVX registers (PRIME [18]), CPU cache and debug
registers (Copker [23]), GPU registers (PixelVault [63]), anddebug registers and Intel TSX (Mimosa [24]).
A common limitation of these solutions is that specificcryptographic operations must be offloaded from the protected application to the new mechanism, mandating perapplication changes. They are also focused on preventing
leakage of only cryptographic keys, which is fundamentally
limited in protecting RAM content in general. Also, somesolutions do not consider user re-authentication at wakeuptime (e.g., [18, 23]). Several of them (re)derive their mastersecret, or its equivalent, from the user password, e.g., [43,45]; this may even allow the adversary to directly guess themaster secret in an offline manner.
Memory encryption. An ideal solution for memory extraction attacks would be to perform encrypted execution:
instructions remain encrypted in RAM and are decryptedright before execution within the CPU; see XOM [36] for an
early proposal in this domain, and Henson and Taylor [27]for a comprehensive survey. Most proposals for memory encryption deal with data in use by an active CPU. Our use
of full memory encryption involves the sleep state, when the
CPU is largely inactive. Most systems require architecturalchanges in hardware/OS and thus remain largely unadopted,
or designed for specialized use cases, e.g., bank ATMs. Using dedicated custom processors, some gaming consoles also
implement memory encryption to some extent, e.g., Xbox,
Playstation. Similar to storing the secrets in safer places,
memory encryption schemes, if implemented/adopted, may
address extraction attacks, but not user re-authentication.
Forced hibernation. YoNTMA [34] automatically hibernates the machine, i.e., switch to S4/suspend-to-disk, whenever it detects that the wired network is disconnected, or
the power cable is unplugged. In this way, if the attacker
wants to take the computer away, he will always get it in a
powered-off state, and thus memory attacks are mitigated.
A persistent attacker may preserve the power supply by using off-the-shelf hardware tools (e.g., [39]). Also, the attacker can perform in-place cold-boot/DMA attacks.
BitLocker. Microsoft’s drive encryption tool BitLocker
can seal the disk encryption key in a TPM chip, if available. Components that are measured for sealing include:
the Core Root of Trust Measurement (CRTM), BIOS, Option ROM, MBR, and NTFS boot sector/code (for the fulllist, see [42]). In contrast, Hypnoguard measures components that are OS and BIOS independent (may include the
UEFI firmware in later motherboard models). In its mostsecure mode, Microsoft recommends to use BitLocker withmulti-factor authentication such as a USB device containing
a startup key and/or a user PIN, and to configure the OS to
use S4/suspend-to-disk instead of S3/suspend-to-RAM [41].
In this setting, unattended computers would always resume
from a powered-off state (cf. YoNTMA [34]), where no secrets remain in RAM; the user needs to re-authenticate with
the PIN/USB key to restore the OS.
BitLocker’s limitations include the following. (1) It undermines the usability of sleep modes as even with faster
SSDs it still takes several seconds to hibernate (approx. 18
seconds in our tests with 8GB RAM in Windows 10 ma-

chine with Intel Core-i5 CPU and SSD). Wakeup is also
more time-consuming, as it involves the BIOS/UEFI POST
screen before re-authentication (approx. 24 seconds in our
tests). On the other hand, RAM content remains unprotected if S3 is used. (2) It is still vulnerable to password
guessing to some extent, when used with a user PIN (butnot with USB key, if the key is unavailable to the attacker).
Based on our observation, BitLocker allows many attempts,
before forcing a shutdown or entering into a TPM lockout(manufacturer dependent). A patient adversary can slowly
test many passwords. We have not tested if offline password
guessing is possible. (3) BitLocker is not designed for coercive situations, and as such, it does not trigger key deletion
through a deletion password or fail counter. If a user is captured with the USB key, then the disk and RAM content
can be easily accessed. (4) Users also must be careful about
the inadvertent use of BitLocker’s online key backup/escrowfeature (see e.g., [4]).
Recreating trust after S3 sleep. To re-establish a secure state when the system wakes up from S3, Kumar etal. [35] propose the use of Intel TXT and TPM for recreating the trusted environment, in the setting of a VMM withmultiple VMs. Upon notification of the S3 sleep, the VMM
cascades the event to all VMs. Then each VM encrypts
its secrets with a key and seal the key with the platform
state. The VMM also encrypts its secrets and seals its context. Thereafter, the VMM loader (hierarchically higher
than the VMM) encrypts the measurement of the wholememory space of the system with a key that is also sealed.
At wakeup-time, all checks are done in the reversed order.
If any of the measurements differ, the secrets will not be
unsealed. This proposal does not consider re-authentication
at wakeup-time and mandates per-application/VM modifications. More importantly, sealing and unsealing are performed for each sleep-wake cycle for the whole operating
context: VMM loader, VMM, VMs. Depending on how thecontext being sealed is defined, this may pose a severe performance issue, as TPM sealing/unsealing is time-consuming;
according to our experiment, it takes more than 500ms toprocess only 16 bytes of data.
Unlocking with re-authentication at S2/3/4 wakeup.
When waking up from one of the sleep modes, a locked device such as an FDE hard drive, may have already lost its
security context (e.g., being unlocked) before sleep. Rodriguez and Duda [51] introduced a mechanism to securely
re-authenticate the user to the device by replacing the original wakeup vector of the OS with a device specific S3 wakeup
handler. The user is prompted for the credential, which is directly used to decrypt an unlock key from memory to unlock
the device (e.g., the hard drive). This approach does not use
any trusted/privileged execution environment, such as IntelTXT/AMD SVM. Without the trusted measurement (i.e.,
no sealed master key), the only entropy comes from the user
password, which may allow a feasible guessing attack.
Secure deallocation. To prevent exposure of memorybound secrets against easy-to-launch warm-reboot attacks,
Chow et al. [10] propose a secure deallocation mechanism(e.g., zeroing freed data on the heap) to limit the lifetimeof sensitive data in memory. This approach avoids modifications in application source, but requires changes in compilers, libraries, and OS kernel in a Linux system (and also
cannot address cold-boot attacks). Our solution is also effec-

tive against warm-reboot attacks, but requires no changes
in applications and the OS stack.
Relevant proposals on mobile platforms. Considering
their small sizes and versatile functionalities, mobile devices
are more theft-prone and more likely to be caught with sensitive data present when the user is coerced. CleanOS [58] is
proposed to evict sensitive data not in active use to the cloudand only retrieve the data back when needed. Sensitive information is pre-classified and encapsulated into sensitive
data objects (SDOs). Access to SDOs can be revoked in thecase of device theft and audited in normal operations. TinMan [69] also relies on a trusted server, but does not decrypt
confidential data in the device memory to avoid physicalattacks. Keypad [19], a mobile file system, provides finegrained access auditing using a remote server (which also
hosts the encryption keys). For lost devices, access can beeasily revoked by not releasing the key from the server. All
these proposals require a trusted third party. Also, undercoercion, if the user is forced to cooperate, sensitive data
will still be retrieved. Moreover, the protected secrets in
Hypnoguard might not be suitable for being evicted as they
may be used often, e.g., an FDE key.
Gracewipe. For handling user secrets in the trusted
execution environment, we follow the methodology fromGracewipe [70], which operates at boot-time and thus canrely on BIOS and tboot. In contrast, Hypnoguard operates during the sleep-wake cycle, when no BIOS is active,
and tboot cannot be used for regular OSes (tboot assumes
TXT-aware OS kernel). Gracewipe assumes that the attacker can get physical possession of a computer, only when
it is powered-off, in contrast to Hypnoguard’s sleep state,
which is more common. Gracewipe securely releases sensitive FDE keys in memory, but does not consider protecting
such keys against memory extraction attacks during sleepwake. Gracewipe addresses an extreme case of coercion,
where the data-at-rest is of utmost value. We target unattended computers in general, and enable a wakeup-time secure environment for re-authentication and key release.
Intel SGX. Intel Software Guard Extensions (SGX [3]) allows individual applications to run in their isolated context,
resembling TXT with similar features but finer granularity (multiple concurrent secure enclaves along with the insecure world). Memory content is fully encrypted outside
the CPU package for SGX-enabled applications. Considering the current positioning of Hypnoguard, we believe thatTXT is a more preferable choice, as running either the protected programs or the entire OS in SGX would introduce
per-application/OS changes. TXT also has the advantageof having been analyzed over the past decade, as well as its
counterpart being available in AMD processors (SVM).

9.

CONCLUDING REMARKSAs most computers, especially, laptops, remain in sleep
while not actively used, we consider a comprehensive listof threats against memory-resident user/OS data, securitysensitive or otherwise. We address an important gap left
in existing solutions: comprehensive confidentiality protection for data-in-sleep (S3), when the attacker has physicalaccess to a computer in sleep. We design and implement
Hypnoguard, which encrypts the whole memory very quickly
before entering sleep under a key sealed in TPM with the
integrity of the execution environment. We require no per-application changes or kernel patches. Hypnoguard enforcesuser re-authentication for unlocking the key at wakeup-timein a TXT-enabled trusted environment. Guessing attacks
bypassing Hypnoguard are rendered ineffective by the properties of TPM sealing; and guessing within Hypnoguard will
trigger deletion of the key. Thus, Hypnoguard along witha boot-time protection mechanism with FDE support (e.g.,
BitLocker, Gracewipe [70]) can enable effective server-lessguessing resistance, when a computer with sensitive data islost/stolen. We plan to release the source code of Hypnoguard at a later time, and for now it can be obtained bycontacting the authors.

Acknowledgements
This paper was significantly improved by the insightful comments and suggestions from the anonymous reviewers of
CCS 2016, USENIX Security 2016 and EuroSys 2016, as
well as Jonathan McCune. We also appreciate the help we
received from the members of Concordia’s Madiba Security
Research Group. The second author is supported in part by
an NSERC Discovery Grant.

10.

REFERENCES[1] ACPI.info. Advanced configuration and powerinterface specification. Revision 5.0a (Nov. 13, 2013).
http://www.acpi.info/spec.htm.
[2] AMD. AMD64 architecture programmer’s manual
volume 2: System programming. Technical article(May 2013). http://developer.amd.com/wordpress/
media/2012/10/24593 APM v21.pdf.
[3] Anati, I., Gueron, S., Johnson, S. P., andScarlata, V. R. Innovative technology for CPU
based attestation and sealing. In Hardware andArchitectural Support for Security and Privacy(HASP’13) (Tel-Aviv, Israel, June 2013).
[4] ArsTechnica.com. Microsoft may have yourencryption key; here’s how to take it back. News
article (Dec. 29, 2015).
[5] Blass, E.-O., and Robertson, W.
TRESOR-HUNT: Attacking CPU-bound encryption.
In ACSAC’12 (Orlando, FL, USA, Dec. 2012).
[6] Böck, B. Firewire-based physical security attacks on
windows 7, EFS and BitLocker. Secure Business
Austria Research Lab. Technical report (Aug. 13,
2009). https://www.helpnetsecurity.com/dl/articles/
windows7 firewire physical attacks.pdf.
[7] Boileau, A. Hit by a bus: Physical access attacks
with Firewire. Ruxcon 2006.
http://www.security-assessment.com/files/
presentations/ab firewire rux2k6-final.pdf.
[8] Calomel.org. AES-NI SSL performance: A study of
AES-NI acceleration using LibreSSL, OpenSSL.
Online article (Feb. 23, 2016).
https://calomel.org/aesni ssl performance.html.
[9] Charles, J., Jassi, P., Ananth, N. S., Sadat, A.,
and Fedorova, A. Evaluation of theIntel R coreTM i7 Turbo Boost feature. In IEEE
International Symposium on Workload
Characterization (IISWC’09) (Austin, TX, USA, Oct.
2009).
[10] Chow, J., Pfaff, B., Garfinkel, T., andRosenblum, M. Shredding your garbage: Reducing

data lifetime through secure deallocation. In USENIX
Security Symposium (Baltimore, MD, USA, Aug.
2005).
[11] Clark, J., and Hengartner, U. Panic passwords:
Authenticating under duress. In USENIX HotSec’08(San Jose, CA, USA, July 2008).
[12] Czeskis, A., Hilaire, D. J. S., Koscher, K.,
Gribble, S. D., Kohno, T., and Schneier, B.
Defeating encrypted and deniable file systems:
TrueCrypt v5.1a and the case of the tattling OS andapplications. In USENIX HotSec’08 (San Jose, CA,
USA, 2008).
[13] Diesburg, S. M., and Wang, A.-I. A. A survey ofconfidential data storage and deletion methods. ACM
Computing Surveys (CSUR) 43, 1 (2010), 2:1–2:37.
[14] Elcomsoft.com. Elcomsoft forensic disk decryptor:
Forensic access to encrypted BitLocker, PGP and
TrueCrypt disks and containers.
https://www.elcomsoft.com/efdd.html.
[15] Filyanov, A., McCuney, J. M., Sadeghiz, A.-R.,
and Winandy, M. Uni-directional trusted path:
Transaction confirmation on just one device. In
IEEE/IFIP Dependable Systems and Networks(DSN’11) (Hong Kong, June 2011).
[16] Forensicswiki.org. Tools:memory imaging. http://www.forensicswiki.org/wiki/Tools:Memory Imaging.
[17] Frank, M., Biedert, R., Ma, E., Martinovic, I.,
and Song, D. Touchalytics: On the applicability oftouchscreen input as a behavioral biometric forcontinuous authentication. IEEE TIFS 8, 1 (Jan.
2013), 136–148.
[18] Garmany, B., and Müller, T. PRIME: Private
RSA infrastructure for memory-less encryption. In
ACSAC’13 (New Orleans, LA, USA, 2013).
[19] Geambasu, R., John, J. P., Gribble, S. D.,
Kohno, T., and Levy, H. M. Keypad: an auditing
file system for theft-prone devices. In EuroSys’11(Salzburg, Austria, 2011).
[20] Götzfried, J., and Müller, T. Mutual
authentication and trust bootstrapping towards secure
disk encryption. ACM TISSEC 17, 2 (Nov. 2014),
6:1–6:23.
[21] Gov1.info. NSA ANT product catalog.
https://nsa.gov1.info/dni/nsa-ant-catalog/.
[22] Gruhn, M., and Müller, T. On the practicability ofcold boot attacks. In Conference on Availability,
Reliability and Security (ARES’13) (Regensburg,
Germany, Sept. 2013).
[23] Guan, L., Lin, J., Luo, B., and Jing, J. Copker:
Computing with private keys without RAM. In
NDSS’14 (San Diego, CA, USA, Feb. 2014).
[24] Guan, L., Lin, J., Luo, B., Jing, J., and Wang, J.
Protecting private keys against memory disclosureattacks using hardware transactional memory. In
IEEE Symposium on Security and Privacy (San Jose,
CA, USA, May 2015).
[25] Halderman, J. A., Schoen, S. D., Heninger, N.,
Clarkson, W., Paul, W., Calandrino, J. A.,
Feldman, A. J., Appelbaum, J., and Felten,
E. W. Lest we remember: Cold boot attacks on
encryption keys. In USENIX Security Symp. (Boston,
MA, USA, 2008).

[26] Helfmeier, C., Nedospasov, D., Tarnovsky, C.,
Krissler, J., Boit, C., and Seifert, J.-P. Breaking
and entering through the silicon. In ACM CCS’13(Berlin, Germany, Nov. 2013).
[27] Henson, M., and Taylor, S. Memory encryption: A
survey of existing techniques. ACM Computing
Surveys (CSUR) 46, 4 (Mar. 2014), 53:1–53:26.
[28] Horvath, A., and Slocum, J. M. Memory
bandwidth benchmark. Open source project.
https://github.com/raas/mbw.
[29] Huang, A. Keeping secrets in hardware: The
Microsoft XboxTM case study. In Workshop on
Cryptographic Hardware and Embedded Systems(CHES’02) (San Francisco, CA, USA, Aug. 2002).
[30] Intel. Intel Trusted Execution Technology (Intel
TXT): Measured launched environment developer’s
guide. Technical article (July 2015). http://www.intel.
com/content/dam/www/public/us/en/documents/
guides/intel-txt-software-development-guide.pdf.
[31] Intel. Trusted boot (tboot). Version: 1.8.0.
http://tboot.sourceforge.net/.
[32] Intel. The MultiProcessor specification (MP spec),
May 1997. http://www.intel.com/design/archives/
processors/pro/docs/242016.htm.
[33] IntelSecurity.com. Technical details of the S3
resume boot script vulnerability. Technical report(July 2015). http://www.intelsecurity.com/advanced-threat-research/content/WP Intel ATR S3 ResBS Vuln.pdf.
[34] iSECPartners. YoNTMA (you’ll never take mealive!). https://github.com/iSECPartners/yontma.
[35] Kumar, A., Patel, M., Tseng, K., Thomas, R.,
Tallam, M., Chopra, A., Smith, N., Grawrock,D., and Champagne, D. Method and apparatus tore-create trust model after sleep state, 2011. US
Patent 7,945,786.
[36] Lie, D., Thekkath, C., Mitchell, M., Lincoln,P., Boneh, D., Mitchell, J., and Horowitz, M.
Architectural support for copy and tamper resistantsoftware. In Architectural Support for Programming
Languages and Operating Systems (ASPLOS-IX)(Cambridge, MA, USA, Nov. 2000).
[37] Maartmann-Moe, C. Inception. PCI-based DMA
attack tool. https://github.com/carmaa/inception.
[38] Mannan, M., Kim, B. H., Ganjali, A., and Lie, D.
Unicorn: Two-factor attestation for data security. In
ACM CCS’11 (Chicago, IL, USA, Oct. 2011).
[39] Maximintegrated.com. Switching between battery
and external power sources, 2002. http://pdfserv.maximintegrated.com/en/an/AN1136.pdf.
[40] McCune, J. M., Parno, B. J., Perrig, A., Reiter,
M. K., and Isozaki, H. Flicker: An execution
infrastructure for TCB minimization. In EuroSys’08(Glasgow, Scotland, Apr. 2008).
[41] Microsoft.com. BitLocker frequently asked
questions (FAQ). Online article (June 10, 2014). https://technet.microsoft.com/en-ca/library/hh831507.aspx.
[42] Microsoft.com. ProtectKeyWithTPM method of
the Win32 EncryptableVolume class. Online reference.
https://msdn.microsoft.com/en-us/library/windows/
desktop/aa376470(v=vs.85).aspx.

[43] Müller, T., Dewald, A., and Freiling, F. C.
AESSE: A cold-boot resistant implementation of AES.
In European Workshop on System Security(EuroSec’10) (Paris, France, Apr. 2010).
[44] Müller, T., and Freiling, F. C. A systematic
assessment of the security of full disk encryption.
IEEE TDSC 12, 5 (September/October 2015),
491–503.
[45] Müller, T., Freiling, F. C., and Dewald, A.
TRESOR runs encryption securely outside RAM. In
USENIX Security Symposium (San Francisco, CA,
USA, Aug. 2011).
[46] Müller, T., Taubmann, B., and Freiling, F. C.
TreVisor: OS-independent software-based full disk
encryption secure against main memory attacks. In
Applied Cryptography and Network Security(ACNS’12) (Singapore, June 2012).
[47] Pancoast, E. T., Curnew, J. N., and Sawyer,
S. M. Tamper-protected DRAM memory module,
December 2012. US Patent 8,331,189.
[48] Parno, B., McCune, J. M., and Perrig, A.
Bootstrapping Trust in Modern Computers. Springer,
2011.
[49] Pixley, J. E., Ross, S. A., Raturi, A., andDowns, A. C. A survey of computer power modes
usage in a university population, 2014. California Plug
Load Research Center and University of California,
Irvine. http://www.energy.ca.gov/2014publications/
CEC-500-2014-093/CEC-500-2014-093.pdf.
[50] Raj, H., Saroiu, S., Wolman, A., Aigner, R.,
Cox, J., England, P., Fenner, C., Kinshumann,
K., Loeser, J., Mattoon, D., Nystrom, M.,
Robinson, D., Spiger, R., Thom, S., and Wooten,
D. fTPM: a firmware-based TPM 2.0 implementation.
Tech. Rep. MSR-TR-2015-84, Microsoft Research,
Nov. 2015.
[51] Rodriguez, F., and Duda, R. System and method
for providing secure authentication of devices
awakened from powered sleep state, 2008. US Patent
20080222423.
[52] Rott, J. Intel AESNI sample library. Source code
(May 11, 2011), available at:https://software.intel.com/en-us/articles/
download-the-intel-aesni-sample-library.
[53] Sevinsky, R. Funderbolt: Adventures in Thunderbolt
DMA attacks. Black Hat USA, 2013.
[54] Sharkey, J. Breaking hardware-enforced security
with hypervisors. Black Hat USA, 2016.
[55] Sim, T., Zhang, S., Janakiraman, R., and Kumar,
S. Continuous verification using multimodal
biometrics. IEEE Transactions on Pattern Analysis
and Machine Intelligence 29, 4 (Apr. 2007), 687–700.
[56] Simmons, P. Security through Amnesia: A
software-based solution to the cold boot attack on disk
encryption. In ACSAC’11 (Orlando, FL, USA, 2011).
[57] Stewin, P. Detecting Peripheral-based Attacks on the
Host Memory. PhD thesis, Technischen Universität
Berlin, July 2014.

[58] Tang, Y., Ames, P., Bhamidipati, S., Bijlani, A.,
Geambasu, R., and Sarda, N. CleanOS: Limiting
mobile data exposure with idle eviction. In USENIX
Operating Systems Design and Implementation(OSDI’12) (Hollywood, CA, USA, Oct. 2012).
[59] Tarnovsky, C. Hacking the smartcard chip. BlackHat DC, 2010.
[60] Trusted Computing Group. TPM Main: Part 1
Design Principles. Specification Version 1.2, Level 2
Revision 116 (March 1, 2011).
[61] Usb.org. Universal serial bus (USB), device classdefinition for human interface devices (HID).
Firmware Specification (June 27, 2001). http://www.usb.org/developers/hidpage/HID1 11.pdf.
[62] Uz, A. S. The effectiveness of remote wipe as a valid
defense for enterprises implementing a BYOD policy.
Master’s thesis, University of Ottawa, 2014.
[63] Vasiliadis, G., Athanasopoulos, E.,
Polychronakis, M., and Ioannidis, S. PixelVault:
Using GPUs for securing cryptographic operations. In
ACM CCS’14 (Scottsdale, AZ, USA, Nov. 2014).
[64] Vasudevan, A., Chaki, S., Jia, L., McCune, J.,
Newsome, J., and Datta, A. Design,
implementation and verification of an eXtensible andmodular hypervisor framework. In IEEE Symposium
on Security and Privacy (Berkeley, CA, USA, 2013).
[65] Vidas, T. AfterLife: USB based memory acquisition
tool targeting “warm boot” machines with 4GB of
RAM or less. http://sourceforge.net/projects/aftrlife/.
[66] Vidas, T. Volatile memory acquisition via warm bootmemory survivability. In Hawaii International
Conference on System Sciences (HICSS’10)(Honolulu, HI, USA, Jan. 2010).
[67] Wojtczuk, R., and Kallenberg, C. Attacking
UEFI boot script, 2014.
http://events.ccc.de/congress/2014/Fahrplan/system/
attachments/2566/original/venamis whitepaper.pdf.
[68] Wojtczuk, R., Rutkowska, J., and Tereshkin,
A. Another way to circumvent Intel Trusted Execution
Technology: Tricking SENTER into misconfiguring
VT-d via SINIT bug exploitation. Technical article(Dec., 2009). http://theinvisiblethings.blogspot.com/
2009/12/another-txt-attack.html.
[69] Xia, Y., Liu, Y., Tan, C., Ma, M., Guan, H.,
Zang, B., and Chen, H. TinMan: Eliminating
confidential mobile data exposure with security
oriented offloading. In EuroSys’15 (Bordeaux, France,
Apr. 2015).
[70] Zhao, L., and Mannan, M. Gracewipe: Secure andverifiable deletion under coercion. In NDSS’15 (San
Diego, CA, USA, Feb. 2015).
[71] Zhao, L., and Mannan, M. Hypnoguard: Protecting
secrets across sleep-wake cycles. Tech. Rep. 981477,
Concordia University, Aug. 2016.
http://spectrum.library.concordia.ca/981477/.