Self-Encrypting Drives (SEDs) (pdf)

Self-Encrypting Drives
Jon Tanguy
Senior SSD Technical Marketing Engineer
Micron Technology, Inc.
February 14, 2014
What is Encryption?
In the classic ROT13 method, each letter in the plain
text is substituted with a corresponding letter 13 places
further ahead in the alphabet.
In its simplest form, encryption is a mechanism used to
obscure data from any unintended audiences. Methods
of encrypting data range from the simple (ROT13), to
the complex (ENIGMA), to the extremely complex and
robust (AES).
There are many well known, proven encryption mechanisms, and most operate in a similar manner.
Factors Driving Adoption
Simple Encryption Example: ROT13
More and more data storage applications are adopting—and even requiring—encrypted solutions, especially in mobile computing. In the past, thieves would
steal laptop notebooks for the pure value of the
notebook. Today, it is normal for the dollar value of the
data on a storage device to be more valuable than the
hardware itself—sometimes, a lot more valuable. As a
One of the simplest (and oldest) encryption mechanisms
is rotation. In rotation encryptions like ROT13, values
in the original, unencrypted message (plain text) are
substituted for new values, which creates the encrypted
message (cipher text). This substitution follows fixed
rules that are known to the recipient of the cipher text
so that the message can be decrypted.
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y
Z
The arrows show the prescribed letter replacement: “A” is replaced with
“N” (and “a” is replaced with “n”; case doesn’t matter).
Using ROT13, “hello” becomes “oryyb.”
Plain text
H
E
L
Cipher text
L
O
ROT13
U
R
Y
Y
B
ROT13 isn’t very sophisticated, but it illustrates a key principle found in
all encryption/decryption methods:
Input (plain text) [ Encryption Engine/Processing [ Output (cipher text)
Figure 1: Simple Encryption
1
Self-Encrypting Drives
result, the target of theft has moved from the notebooks themselves to the data stored on them. There are
many publicized examples of mobile workers losing a
notebook that contains sensitive information like client
Social Security numbers, credit card information, and
even business research and intelligence. All sensitive
data is at risk.
In the case of a PC (notebook, server, or desktop—it
doesn’t matter), the most obvious place to start is the
hard drive. The hard drive spans three high-level uses:
boot area, operating system area, and user file and
directory area. Disk encryption schemes protect some or
all of these areas of the disk but are commonly divided
into two basic types: file/folder encryption and full disk
encryption (FDE).
Even systems that are kept in close control by their owners are vulnerable. Computer hacking has graduated
from an annoyance to big business. Instead of wanting
to impress their peers, hackers today are out to compromise a system and steal sensitive (and valuable) data,
which they can then sell to the highest bidder.
In Figure 2, the sections of the disk shown in yellow are
unencrypted. Because this system has no encryption
implemented, all sections of the disk are vulnerable: the
boot sector, the operating system, and the user data.
In Figure 3, only the user’s files and the directories
they’ve created are encrypted. This section of the disk
is safe because we assume that whatever means of
encryption employed are sufficiently robust enough to
make encrypted data essentially inaccessible to unintended users.
The sheer volume of these data intrusions are now driving changes to corporate policy and legal governance,
demanding solutions to the problem. Federal litigation
(such as Sarbanes/Oxley) puts the responsibility of data
protection on both the end user and the corporate
officer, with dire consequences if that protection is
insufficient. Even internal corporate documents, such as
security policy and processes, need to be kept private.
If this encryption is extended to the operating system
itself, as shown in figure 4, all of the OS bits are encrypted as well as the data that the OS creates—temporary or permanent. In this example, assuming the OS is
Windows, the core .dll files, executables, user settings,
the registry, and even the swap file would be protected.
Data Encryption: File Level vs.
Full Disk
When encryption is extended to the next logical level—
the entire disk—it is commonly referred to as full disk
encryption or FDE, as shown in figure 5.
When considering data encryption in a computing environment, it is important to think about where data is
stored and accessed and how those areas are protected
with common encryption techniques.
User file and directory area
User file and directory area
User file and directory area
Operating system area
Operating system area
Operating system area
Boot area
Boot area
Boot area
Figure 2: No Encryption –
Entire Disk Vulnerable
Figure 3: Partial Encryption –
User Files and Directories Protected
2
Figure 4: Partial Encryption –
User Files and Directories, OS Protected
Self-Encrypting Drives
selves are encrypted independent of the media on
which they are stored, the protection is extended to
data in transit, as shown in Figure 6.
With FDE, all portions of the disk are encrypted and,
hence, protected from unauthorized access. From the
boot area, to the operating system, to the user data
files and folders—everything is protected. Full disk
encryption is the most sophisticated and secure method
of data encryption on a local drive.
In this example, each user is employing file/folder encryption. The user on the left will transmit an encrypted
file to the user on the right via email. The file stored in
the system on the left is protected by file-level encryption and does not need to be decrypted prior to transmission because it is transmitted as cipher text (shown
in blue). Once received by the user on the right, the file
(still encrypted) can be decrypted for use, assuming the
user on the right has the correct credentials.
User file and directory area
Operating system area
Boot area
Figure 5: Full Encryption – Entire Disk Protected
Data Transmission
(cipher text)
Benefits of Folder and File
Encryption
Encrypted
data
Implementing encryption at the folder and/or file level
has some advantages:
• Data encryption can be implemented on local drives
or network shares, giving consistent security regardless of the storage type (local or network). To implement FDE on a network share, the hardware that
serves the share must implement FDE.
• Because the same protection can be implemented
on shared and local drives, it can be governed by
consistent network and security policies, such as
access control lists (ACLs) and authentication mechanisms (passwords, biometrics, etc.), and it can be
easily managed from a central location (policy server,
biometric record server, etc.).
• The user can specify which files/folders to encrypt.
• This scheme protects data stored off drive on a USB
key or sent via e-mail.
Data remains encrypted
prior to transmission
File-level
protection
Encrypted
data
Data remains encrypted
after transmission
File-level
protection
Figure 6: Folder and File Encryption
Folder- and file-level encryption offer a key advantage
compared to FDE. Folder/file encryption is capable of
protecting data in transit, whether sent via e-mail,
shared via a removable drive, such as a USB stick drive,
or burned to optical media. Because the files them-
3
Self-Encrypting Drives
Benefits of Full Disk Encryption
be plain text data, yielding a potentially unprotected
transmission. Similarly, data that is intentionally transported (via e-mail, ftp, http, etc.) is not encrypted in
FDE schemes, as shown in Figure 7.
Full disk encryption (FDE) has significant benefits over
other levels of encryption, including:
Encryption methods for data storage devices should
only be one part of an overall data security regime. FDE
does not eliminate the need for data security methods
such as user authentication, software and hardware
firewalls, and antivirus applications.
• The encryption mechanism itself can be implemented
in hardware or software, offering design flexibility
and cost reduction options.
• Every bit on the HDD is encrypted: the operating
system, user and program data, the applications
themselves (and the data they create during normal
operation), as well as the OS swap file (which may
contain data otherwise held in memory).
• A given hard disk can be married to a given platform
via a trusted platform module, making drives that
are removed from the platform less vulnerable. (See
the TPM section.)
Full Disk Encryption vs. Self-Encrypting Drive
The terms full disk encryption (FDE) and self-encrypting
drive (SED) are sometimes used interchangeably; however, there are some distinct differences. FDE is a more
generic term that can be used to describe full encryption of a storage device’s data accomplished by either
software or hardware methods. SED is a method of FDE
that is always hardware-based.
However, FDE is not a panacea. Other system-level
vulnerabilities may exist that can’t be addressed with
FDE—for example, having malware installed on a user’s
system, which transmits data unknown to the user via
the built-in wireless network. Since the data must be
decrypted in order for the user to access it, it has to
An SED will always have a hardware-based encryption
engine onboard—often integrated into the drive’s
controller. Micron’s SEDs support the Trusted Computing Group (TCG) protocols for hardware-encrypted
storage devices. Specifically, Micron’s personal storage
SSDs support the TCG Storage Subsystem Class Opal
protocol while its enterprise storage SSDs are beginning
to support the TCG Storage Subsystem Class Enterprise
protocol. (Contact your Micron sales representative to
determine which protocols are supported for a specific
Micron model number.)
Data Transmission
(plain text)
Unprotected
user data
Unprotected
user data
Data decrypted
prior to transmission
(cipher textplain text)
Implementation Options: Software
vs. Hardware
Data encrypted prior to
storage on FDE drive
(plain textcipher text)
Full disk, partial disk, or file-level encryption can be
implemented in hardware or software, each of which
has its own considerations.
Considerations for Hardware Encryption
FDE-protected
data
Ease of Deployment:
Hardware encryption methods can be extremely easy
to deploy, even in enterprises with large numbers of
notebook computers. Generally, SEDs will always encrypt the data written to the storage media, regardless
of whether data protection is deployed. Thus, providing data protection is as simple as installing a software
FDE-protected
data
Figure 7: Full Disk Encryption
4
Self-Encrypting Drives
application and clicking “Enable.” Software encryption,
on the other hand, can take hours for first-time encryption of user data.
Keys stored in memory are vulnerable:
Software encryption mechanisms typically decrypt information “on the fly” as it is read from storage media.
To perform this decryption with the least amount of
system performance degradation possible, these encryption mechanisms typically store the decryption information in the system’s memory. Although one might
expect system memory to be secure—perhaps more
secure than a disk—there is at least one well documented example of how a system that stores decryption keys
in-memory can be compromised, even when the power
is turned off. Briefly, here’s what happens:
Inflexible Deployment:
Because hardware encryption is implemented at the
device level, changes in the encryption algorithm or key
length are not easily implemented and usually require
new devices. Given that Moore’s Law shows few signs of
being broken, we can expect more powerful computing
platforms in the near future and, hence, more powerful
tools that will be able at break encryption techniques.
Key lengths that were considered secure just a few
years ago are now easily broken and vulnerable. A
40-bit key, for example, is easily broken via brute force
because newer computing platforms have so much
additional capability to increase the number of brute
force attacks (password guesses) per second with each
new introduction. Today’s modern 256-bit encryption
keys are widely considered to be unbreakable. However, it is conceivable that future development will
lead to enough supercomputing power to break a long
encryption key in a reasonable amount of time. Such a
development would potentially require new encryption
engines in hardware, which is an expensive redeployment.
• In the course of normal operation, the decryption
key is loaded into the system’s memory and the decryption process executes to decrypt data on the fly.
• At the end of a user session, the user closes the operating system and powers down the computer.
• Data stored in system memory, including the decryption key (stored in system memory as plain text),
remains for some amount of time, gradually decaying until the data is lost.
• If the system is compromised after power-down but
before the system memory data dies away completely, some data (such as a decryption key) can be recovered and exploited. The amount of data that can
be recovered is inversely proportional to the time
between power-down and compromise and inversely
proportional to temperature. (System memory data
can be preserved for long periods of time if the compromised system is chilled quickly.)
Encryption Key Security:
In hardware encryption, particularly for SEDs, the encryption key resides in hardware on the storage device.
The encryption key never leaves the device and, thus, is
never exposed to intrusion or detection.
Upgrade paths can be difficult:
Just as hardware encryption can be disruptive (installing new hardware), software encryption methods can
be subject to interoperability concerns among software
applications, operating systems, patch levels, and other
software elements essential to an end user’s productivity.
Considerations for Software Encryption
Performance can be degraded:
Software encryption mechanisms often rely on CPU
and memory resources in the host system. Therefore,
software encryption usually results in a significant and
noticeable reduction in data throughput performance.
End-to-end software encryption management requires
encryption of data blocks that are not in use (in addition to user data), which adds even more performance
overhead. This is especially important for SSDs because end-to-end encryption can result in an SSD that
behaves as if it was 100% full. Micron has observed as
much as a 20% degradation in data throughput, especially for write speeds, due to software encryption.
Most software encryption deployments prohibit certain
firmware updates. All user data must first be decrypted
(leaving it temporarily vulnerable) before an update is
performed—and then re-encrypted after the update is
complete. Even on a very fast SSD, the decrypt and encrypt steps can take significant time. Encrypting 25GB
of user data can take more than one hour—even on a
very fast system.
5
Self-Encrypting Drives
PC (Notebooks, Desktops, Servers)
I/O
Executive
Security
Enablement
Opt-in
(default is “off”)
Key Generation
Storage
Nonvolatile
Secured Storage
HASH
Secure Platform
Configuration
Registers
Secure Platform
Excecution
Engine
Random # Generator
Platform ID Keys
Figure 8: TPM
The Role of the Trusted Platform
Module
A time-consuming decryption step is also required
when cloning a drive because cloning an encrypted
drive to a new drive results in a drive full of unreadable
data (because the two drives will have different encryption keys).
The trusted platform module (TPM) is a hardware device that is tamper-resistant, permanently affixed to the
system mainboard, helps integrate basic security management functions, and helps thwart common attacks.
The TPM provides several essential functions that help
make encryption easier to implement and more robust.
Functions such as platform identification (to ensure
that the platform accessing the data is what it claims to
be), random number and hash generation, encryption/
decryption key generation, secure subsystem (to ensure
a hardened area within the host), key storage, and platform configuration definitions (registers) are all part of
the TPM, as shown in Figure 8.
Software can be added to existing hardware and
platforms:
Fortunately, software typically does not require additional hardware to be deployed, so it can easily be
added to existing environments with less disruption
and less cost compared to hardware-based encryption.
Often, software encryption methods can be integrated
into the operating system.
Hard disk
Encrypted data
Figure 9: System Comparison
Encrypted key
System without TPM
6
Hard disk
Security chip
Encrypted data
Encrypted key
System with TPM
Self-Encrypting Drives
In a system with a TPM, the decryption key comes from
the TPM itself. If the drive is removed from the system,
the TPM and drive are “decoupled”; and since the
decryption key is stored on the TPM, it is not possible to
read the data.
The following essential functions are all housed inside
the TPM chip that is soldered to the mainboard of a
notebook, desktop, server, or storage array:
•
•
•
•
•
•
Nonvolatile, secure storage
Platform configuration data
Opt in/out switch
Hardened execution partition
Key, HASH, and random number generators
Unique platform ID keys
The Role of the Trusted Computing Group
Who is the Trusted Computing Group (TCG) and how
do they factor into encryption and authentication?
One essential function of the TPM is to establish the
identity of the system itself with respect to the encrypted data. The TPM and the disk drive can be married to
one another. The data storage system (e.g., the internal disk drive) and the system mainboard are closely
coupled through the use of stored decryption keys.
Once the disk drive and the TPM are married, it is nearly
impossible to read the data on that hard drive when the
drive is removed from the original system and installed
in another. The TPM signatures don’t match and the
data won’t decrypt.
Founded in 2003 TCG is, at its core, a standards organization. Membership driven, TCG’s primary role is to
gain consensus from membership, develop standards,
publish them, and drive their adoption in the industry.
Organized by functional area, standards are developed
and proposed by groups within TCG whose members
are experts in a given area. Once a standard is published, TCG drives the adoption of the standard within
the developer community and end-user markets.
As a standards body, the TCG plays an essential role in
getting the different encryption and authentication
methods to work together (via standards).
When data is encrypted, the key used to decrypt the
data must be stored somewhere. For ease of use, the
key should always be readily accessible to the user and
be tamper-resistant. An ideal place for key storage
is the TPM itself; it provides both a secure platform
execution engine and the capability to generate keys
and random numbers (essential functions), as well as a
tamper-resistant storage area for those keys.
The Role of the OS
What role does the OS play in data encryption? In
some cases, the OS is more of a bystander, ensuring
that it doesn’t get in the way when encryption is accomplished by add-on components. In other cases (like
Microsoft’s BitLocker), its role is integral. To understand
the difference, we’ll examine BitLocker more closely.
BitLocker is a data encryption and user authentication
In a system without a TPM (below), the decryption keys
are stored on the local hard disk— the same media that
should be protected with encryption. Storing the key
and the data on the same media makes unauthorized
access easier.
Windows startup files (boot sector)
Windows non-startup files (user data,
registsry, Windows core, etc.)
TPM (permanently affixed to the system)
User startup key (typically USB fob,
biometric, etc.)
User-supplied ID (typically PIN,
password, etc.)
Figure 10: Role of the OS
7
Self-Encrypting Drives
feature first built into Windows Vista Enterprise, Vista
Ultimate, and Server 2008. BitLocker ideally—but not
necessarily—integrates with a TPM to ensure that the
data on the drive is encrypted and that the system is not
tampered with when offline. This check is performed via
an early boot integrity checking mechanism.
BitLocker drive encryption protects data by securing the
Windows file system from attack via a lost PC, decommissioned PC, or a malicious attack. BitLocker encrypts
the entire volume, including the swap file and the disk
hibernate image. When the system fails to start due to
tampering or authentication failure, the data remains
encrypted and is protected.
To understand how BitLocker unlocks a system during
the boot process, consider the process of enabling the
following components of BitLocker on a PC or notebook.
The data integrity checking/early boot checker ensures
that disk decryption only takes place when the hardware has not been tampered with and the drive being
decrypted is installed in the correct system (protecting
against disk theft).
Windows Startup Files: Data on the hard drive that Windows uses to boot; contains the command interpreter,
core system files, and other components necessary for
successful Windows startup.
Key Storage: One downside of BitLocker is key storage.
In order to use a BitLocker-protected drive, a decrypt
key must be stored somewhere. On systems without a
TPM, this is most commonly a USB thumb drive. If the
thumb drive is compromised—stolen, lost, duplicated,
tampered with—the data may no longer be secure.
Keys can also be stored in an active directory, but the
directory may be compromised and have its stored keys
downloaded to a USB drive.
Windows Non-Startup Files: The (larger) section of the
drive that is used to store Windows files that are not part
of the first boot sequence (such as, the registry), files
that were installed by Windows applications and system
devices (.dll files, drivers, etc.), and user data.
TPM: The tamper-resistant, hardened security device
permanently affixed to the system board.
Important BitLocker Developments in Windows 8: In
previous versions of Windows, BitLocker only provided
software encryption. Beginning with Windows 8,
BitLocker provides integrated support for either
software encryption (like in Windows 7) or hardware
encryption using an SED.
User Startup Key (typically used in non-TPM
enabled systems): A removable storage device—typically a USB fob—on which one authentication factor (the
startup key) is stored.
User-Supplied ID: A password or PIN that users enter
as the final step to authenticate themselves and enable
data decryption.
Microsoft deploys hardware encryption under the
moniker “eDrive.” An eDrive must meet the following
criteria:
Win7/BitLocker/TPM Startup Sequence:
1.
2.
1.System powers up.
2. TPM uses platform configuration registers of selected
(and configurable) elements of the boot sequence (including the CRTM, BIOS, MBR, and other components)
to determine if something has been tampered with.
If not, the boot sequence proceeds normally. If any
monitored files have been tampered with, the system
does not start, which alerts the user to tampering.
3. User inserts startup key (optional with TPM-enabled
systems, mandatory without TPM), and the startup
key is validated. If the startup key has been tampered
with, the system does not start, which alerts the user
to tampering.
4. User supplies ID (password or PIN). If the user supplied
ID is incorrect, the system fails to start.
It must be an SED that meets the TCG Opal 2.0
protocol requirements.
It must follow the IEEE-1667 protocol for authentica‑
tion of removable storage devices.
Micron’s newer SEDs meet both requirements and
can be seamlessly integrated into a hardware encryption system under BitLocker in Windows 8.x Enterprise
and Professional versions. Contact your Micron sales
representative to determine which Micron SSDs support
eDrive.
Microsoft provides support documentation with important system-level requirements. Visit microsoft.com and
search for “encrypted hard drive.”
8
Self-Encrypting Drives
Universal Adoption of
File Encryption
Despite some concerns over vulnerability, clearly an
encrypted file/drive is more secure than an unencrypted
file/drive. With security garnering so much attention
lately, why isn’t file encryption or FDE universally adopted? The Ponemon Institute, a pre-eminent research
center dedicated to privacy, data protection, and information security policy, conducted an end-user survey to
try and answer this. Concerns over system performance,
complexity, and cost are among the top reasons stated.
Why Isn’t Encryption
Universally Adopted?
80%
70%
69%
60%
50%
40%
30%
20%
10%
0%
• Performance: Hardware encryption does not
incur the CPU and memory overhead that software encryption does and, therefore, maximizes
performance.
Hardware encryption will seem invisible to the
user.
• Total Cost of Ownership (TCO): SEDs offer the
lowest TCO for encryption solutions with the
best performance, lowest acquisition costs,
higher user productivity, and simplest IT management and deployment. (Source: Report by
Trusted Computing Group, Sept. 2010)
• Data Security: 256-bit hardware-based self-encryption and user authentication offer superior
protection against data breaches, loss, and theft
compared to software-based encryption, which
is vulnerable to attack through the memory
device, operating system, and BIOS. Hardwarebased encryption is performed in the hardware—user authentication is performed by the
drive before it will unlock, independent of the
operating system.
44%
Conclusion
25%
System
Performance
Installation
Complexity
Expense
Figure 11: Perceived Impediments to Encryption Adoption
The Trend Toward
Hardware-Based Encryption
Data encryption is an essential part of data security.
Options for protecting data on PCs include file and
folder, full disk, hardware-assisted, pure software,
add-on packages, and operating system-level integration—with hardware-based encryption (based on SEDs)
emerging as a superior choice.
Hardware-based encryption is superior to softwarebased encryption in these three major categories
discussed in the Ponemon study above:
Starting with the M500 SED, Micron provides the
full benefits of hardware-based encryption to its
personal storage SSDs by enabling hardware encryption according to the TCG Opal protocol or the
ATA Security Suite. Micron’s family of SEDs provide
an ideal solution for any application that needs easily integrated, cost-effective data protection.
Featuring an AES-256 encryption engine coupled
with powerful firmware algorithms, Micron’s SEDs
provide hardware-based data encryption—with
no loss of SSD performance—in accordance with
industry standards for trusted peripherals and
government data security regulations. Micron’s
SEDs are designed to work with mainstream thirdparty independent software vendor (ISV) encryption management tools to provide a complete data
security system. Micron’s SEDs are also certified
under the Windows Hardware Certification Kit
(WHCK), and therefore, compatible with Windows
8.x BitLocker.
Visit micron.com/ssd for more information.
micron.com
Products are warranted only to meet Micron’s production data sheet
specifications. Products and specifications are subject to change
without notice.
Micron and the Micron logo are trademarks of Micron Technology, Inc. All other trademarks are
the property of their respective owners. ®2013 Micron Technology, Inc. All rights reserved. 2/14
9

Download Report