[ Pobierz całość w formacie PDF ]
J Comput Virol
DOI 10.1007/s11416-007-0062-0
SSTIC 2007 BEST ACADEMIC PAPERS
Improving virus protection with an efficient secure architecture
with memory encryption, integrity and information leakage
protection
Guillaume Duc
·
Ronan Keryell
Received: 5 January 2007 / Revised: 15 July 2007 / Accepted: 18 August 2007
© Springer-Verlag France 2007
Abstract
Malicious software and other attacks are a major
concern in the computing ecosystem and there is a need to
go beyond the answers based on untrusted software. Trusted
and secure computing can add a new hardware dimension
to software protection. Several secure computing hardware
architectures using memory encryption and memory integ-
rity checkers have been proposed during the past few years
to provide applications with a tamper resistant environment.
Some solutions, such as hide, have also been proposed to
solve the problem of information leakage on the address bus.
We propose the CryptoPage architecture which implements
memory encryption, memory integrity protection checking
and information leakage protection together with a low per-
formance penalty (3% slowdown on average) by combining
the Counter Mode of operation, local authentication values
and Merkle trees. It has also several other security fea-
tures such as attestation, secure storage for applications and
program identification. We present some applications of the
CryptoPage architecture in the computer virology field as a
proof of concept of improving security in presence of viruses
compared to software only solutions.
secure operating systems and some applications that use these
methods, but all of them rely on a strong hypothesis: the
underlying software and hardware themselves need to be
secure. However this critical hypothesis is never verified,
except for small applications that can fit onto a smartcard,
for example.
Software applications, such as anti-virus or operating sys-
tems, can be used to verify the integrity of the execution con-
text or even repair it, but their execution themselves must be
protected. Furthermore, software architectures have grown
to a size far beyond what can be proved as inherently cor-
rect and contains unfortunately many errors, bugs
So, it is
interesting to add specific hardware support to improve the
global security of the system.
During the last few years, several hardware architectures
(such as Xom [
27
–
29
], Aegis [
36
,
37
] and CryptoPage
[
8
,
12
,
14
,
21
,
26
]) have been proposed to provide computer
applications with a secure computing environment. These
architectures use memory encryption and memory integrity
checking to guarantee that an attacker cannot hinder the oper-
ation of a secure process, or can only obtain as little infor-
mation as possible about the code or the data manipulated
by this process. These secure architectures try to prevent, or
at least detect, physical attacks against the components of
a computer (for example, the Microsoft X-Box video game
console was attacked in [
19
] by sniffing the bus of the pro-
cessor with a logic analyzer) or logical attacks (for example,
the administrator of the machine or a virus tries to steal or
modify the code or the data of an application).
Such architectures can, for instance, be very useful in dis-
tributed computing environments. Currently, companies or
research centers may be reluctant to use the computing power
provided by third-party computers they do not control on a
grid, because they fear that the owners of these computers
might steal or modify the algorithms or the results of the
...
1 Introduction
Many computer applications need certain levels of security,
confidentiality and confidence that are beyond the scope of
current software and hardware architectures. Of course, there
are
many
cryptographic
algorithms,
network
protocols,
B
G. Duc (
R. Keryell
ENST Bretagne, CS 83818, 29238 Brest Cedex 3, France
e-mail: Guillaume.Duc@enst-bretagne.fr
R. Keryell
e-mail: Ronan.Keryell@enst-bretagne.fr
)
·
123
 G. Duc, R. Keryell
distributed application. If each node of the grid uses a secure
computing architecture that guarantees the integrity and the
confidentiality of the distributed application results, these
security issues disappear.
However, as the address bus is not modified in these secure
architectures, the memory access patterns are accessible to
the attacker. Zhuang et al. in [
39
] show that these memory
access patterns can be sufficient to identify certain algorithms
and so to obtain information about the code of a secure appli-
cation, in spite of the encryption.
To stop this information leakage, they present Hide (Hard-
ware-support for leakage-Immune Dynamic Execution), an
infrastructure for efficiently protecting information leakage
on the address bus [
39
]. However, the impact of this infra-
structure on encryption and memory checking is not studied.
In this paper, we present the CryptoPage extension of
the Hide infrastructure to provide, in addition to the pro-
tection of the address bus, memory encryption and memory
checking. We also study the impact of this architecture on
the computer virology field.
The rest of this paper is organized as follows. Section
2
describes the CryptoPage architecture. Section
3
presents
some applications that can benefit from this architecture.
Section
4
studies the relationships between this architecture
and the computer virology field. Section
5
presents infor-
mation about the performance of this system while Sect.
6
presents related work in this field.
respect to an operating system adapted to the architecture
but not necessarily secure or trusted. One key hypothesis is
that the operating system itself does not need to be trusted. It
may be compromised, or at least, be too large to be bug-free.
We assume that everything outside the chip of the proces-
sor (for instance the memory bus, the hard drive, the operat-
ing system, etc.) is under the full control of an attacker. For
instance, he can inject bogus values in the memory, mod-
ify the operating system to wiretap processor registers or to
modify hardware contexts, execute secure and non-secure
processes of his choice, etc.
However, the attacker cannot directly or indirectly probe
inside the processor. In particular, we consider that timing
attacks [
22
], differential power analysis (dpa [
23
]) attacks,
etc. are avoided by other means beyond the scope of this arti-
cle. Moreover, we do not consider denial of service attacks
because they cannot be avoided (the attacker can choose not
to supply power to the processor).
The attacker can also modify the execution of system calls
but we consider that these attacks are similar to denial of
service attacks and that this problem should be taken into
account at the application level.
We want to protect the integrity and confidentiality of a
secure application against hardware attacks but we do not
protect it against itself. If the secure application contains
security holes, they can be exploited to modify its behavior.
2.2 Key mechanisms
2 Architecture
In this section we describe the key mechanisms of the Cryp-
toPage architecture implemented to achieve the security
objectives described above. The low-level details of these
mechanisms can be found in [
7
–
14
,
21
,
26
].
Figure
1
summarizes the CryptoPage architecture. The
blocks in grey are those which are present in a normal pro-
cessor and the other blocks are specific to the CryptoPage
architecture. In spite of the fact that there are many new mech-
anisms, they are relatively cheap to implement in hardware
compared to the number of transistors in existing processors.
Each CryptoPage processor is unique and has an embed-
ded private key used to decrypt the symmetric keys of secure
applications and to sign results. A certificate, signed by the
manufacturer of the processor, attests to the authenticity of
the corresponding public key. The private key can only be
used by the security mechanisms of the processor and is not
accessible by any attacker.
In this section, we present the security objectives and the key
components of the CryptoPage architecture.
2.1 Objectives of the architecture
The objective of our architecture is to allow the execution of
secure processes. We consider two properties:
•
confidentiality
: an attacker must obtain as little informa-
tion as possible about the code or the data manipulated by
the process;
•
integrity
: the proper execution of the process must not be
altered by an attack. If an attack is detected, the processor
must stop the program.
The processor has two new execution environment in
addition to the normal non-secure execution environment.
The first one protects the confidentiality and the integrity of
the secure processes that are running in this environment. The
second one only protects the integrity of the secure processes.
The processor must be able to execute secure processes
in parallel with other normal (non-secure) processes with
2.2.1 Confidentiality
In order to guarantee the confidentiality property, the Cryp-
toPage architecture makes intensive use of encryption at
different levels. The basic idea is that everything that is out-
side of the processor, and so under the control of an attacker,
123
Improving virus protection with an efficient secure architecture with memory encryption, integrity and information leakage protection
Fig. 1
The CryptoPage
architecture
SHA-1
unit
Identification
buffer
Data
AES CM +
CBC-MAC
Caches
Permutation
unit
Processor
MMU
Addresses
Permutation
Permutation
buffer
(e)
(i)
R
c,p,
R
c,p,
TLB
ETLB
AES CBC
MERKLE
tree
Verifier
MERKLE
tree
cache
K
pid,i,
K
pid,d,
K
pid,m
Hardware
context
butter
(plaintext)
Hardware
context
butter
(encrypted)
AES CBC
verifier
K
proc,e
K
proc,m
Initial
hardware
context
(encrypted)
AES
RSA
Random
number
generator
Secure
storage
tree
verifier
SK
proc
Root
K
proc,s
Chip
must be encrypted. This includes the code and the data of
the secure processes when they are stored in the executable
file or in memory, and the hardware contexts of the secure
processes during interrupts.
As the processor is supposed to be impossible to be wire-
tapped and to be tampered, the information that is inside the
processor (data or code in caches for instance) can be stored
unencrypted for better performances.
the pad is generated in the same way and combined with the
encrypted block to generate the decrypted block.
The main advantage of this mode is that, if the counter
used to encrypt a block is known, the pad can be computed
in advance without the data block itself. This is, in partic-
ular, useful during read operation from memory because,
if the counter is known, the pad can be computed while
the encrypted block is read from memory. If the encryption
engine is faster than the memory access, when then encrypted
block arrives in the processor, the end of the decryption only
requires one clock cycle (in the counter mode, the final oper-
ation is a simple
bitwise exclusive or
). So the latency added
by the decryption process is negligible.
In the CryptoPage architecture, the counter used to
encrypt a line is composed of the virtual address of the line
and a random number chosen for the memory page of the line
(see section on information leakage below). They are always
available before the memory access so our architecture ben-
efits from the advantage of the counter mode.
Memory encryption
First, the code and the data of a secure
process that is running in the execution environment that
protects the integrity and the confidentiality, are encrypted
while they are outside of the processor. Each secure process
has two symmetric keys,
K
pid
,
i
and
K
pid
,
d
used to encrypt,
respectively, its code and its data.
The encryption unit takes place on the processor between
the highest level cache and the memory bus. As the unit of
transfer between the processor and the memory is a line, the
encryption engine works on lines. When a line is read from
memory, it is first decrypted and then stored in the cache.
When a line is unloaded from the cache, it is encrypted before
leaving the processor.
The encryption algorithm used is the aes [
32
]inthe
counter mode of operation [
33
]. In this mode, a counter is
encrypted using the aes algorithm to generate a pad and this
pad is combined with the block, with a simple
bitwise exclu-
sive or
, to generate the encrypted block. To decrypt a block,
Interrupts
During an interrupt, the hardware context of a
secure process (the hardware context contains the state of the
process, i.e., the values of all the registers of the processor)
is saved to one of several special buffers inside the proces-
sor called hardware context buffers. Only the processor has
access to these buffers so the operating system cannot wire-
tap the state of the process. If the number of secure processes
scheduled by the operating system is greater than the number
123
 G. Duc, R. Keryell
of hardware context buffers in the processor, the operating
system can ask the processor to encrypt the hardware context
of a secure process and to store it in memory. It can also ask
the processor to load an encrypted hardware context from
memory and to decrypt it to a hardware context buffer. So,
even if an hardware context is in memory, the operating sys-
tem, or some other processes cannot access it thanks to the
encryption mechanism.
During an interrupt, after the storage of the hardware con-
text of the secure process in an hardware context buffer, the
content of the registers of the processor is erased so the oper-
ating system cannot access it. However, a secure process can
ask the processor not to erase the content of some registers,
for instance to allow the storage of the arguments of system
calls.
sor detects that the cache (or one set of the cache, depending
on its structure) is almost full, it begins a background per-
mutation. With this mechanism, the performance penalty is
negligible (1.3% according to [
39
]).
In the CryptoPage architecture, the secure processes are
protected with hide. The chunks used are the memory pages.
In addition, during the permutation of a page, two random
numbers are chosen by the processor. They are used by the
mechanisms that protect the integrity (they are included in
the computation of the mac) and confidentiality (they are
included in the computation of the counter used to perform
the encryption) of the data of the page.
2.2.2 Integrity
In this section, we describe how the integrity of a secure
process is protected.
Information leakage on the address bus
The Crypto-
Page architecture is based on the hide infrastructure [
39
].
This infrastructure reduces the information leakage that exists
on the address bus because, even if all the code and data of
a secure process is encrypted while they are transferred and
stored in memory, the address bus is not modify so an attacker
can retrieve the memory access patterns. Zhuang et al. in [
39
]
have shown that these memory access patterns can be suf-
ficient to identify certain algorithms and so to obtain infor-
mation about the code of a secure application, in spite of the
encryption and so, to violate the confidentiality property.
The hide infrastructure, as described in [
39
], memorizes
the sequence of addresses accessed by the processor and per-
mutes the memory space before an address recurs. More
precisely, the protected memory space is divided into sev-
eral chunks. This protection is implemented by modifying
the cache mechanism of the processor. Whenver a line that
belongs to a protected chunk is read from memory (during a
cache miss), it is stored in the cache, as usual, but it is also
locked. While locked, this line cannot be replaced or written
back to memory. Whenver a line needs to be flushed because
there is no space left in the cache for a new line and all lines
are locked, a permutation of the chunk occurs.
During this permutation, all the lines belonging to the
chunk that is being permuted are read (from memory or from
the cache), then the addresses of these lines are permuted and
the lines are unlocked and re-encrypted. So between each per-
mutation, a line is written to memory and read from memory
only once. In addition, the re-encryption of the lines pre-
vents an attacker from guessing the new address of a given
line inside a chunk after a permutation. With this mechanism,
an attacker cannot learn that one line has been read more than
another nor can he find interesting memory access patterns
at a grain finer than the chunk size. The current permutation
table for a chunk is encrypted and stored in memory.
To reduce the cost of the permutations, Zhuang et al. [
39
]
proposes to do the latter in the background. When the proces-
Memory integrity
In the CryptoPage architecture, the
integrity of the code and the data of a secure process is pro-
tected by computing a
Message Authentication Code
(mac)
with a symmetric key
K
pid
,
m
, specific to a secure process.
Since an attacker does not know this key, it cannot inject a
piece of data in memory because it cannot compute a valid
mac for it. In addition, the address of the data protected is
also included in the computation of the mac so an attacker
cannot permute two pieces of data in memory.
However, to protect the integrity of a line against replay
attacks (i.e., an attacker that puts, at a given address in mem-
ory, a value and its mac that were previously stored at this
address), the mac is not sufficient in itself. To solve this
problem, the computation of the mac also includes a random
number that is specific to a memory page and chosen during
each permutation of the page.
The random number used to compute the mac of the lines
of a memory page is stored with the other information of this
page (for instance, the permutation table needed by hide).
To speed up the access to these information, they are stored
in an extension of the
Translation Lookaside Buffers
(tlb),
called etlb.
However, if an attacker can replay these pieces of informa-
tion (and so the random number that protects the integrity), it
can replay data in memory. So the CryptoPage architecture
has a mechanism to protect the information with respect to
a page against replay attacks. This mechanism is based on
hash trees (Merkle tree).
A binary tree is built. Each node of the tree contains a
cryptographic hash of the content of its children. The leaves
of the tree contain a cryptographic hash of the information
about a page. The root of the tree is stored inside the proces-
sor so it cannot be replayed. When the information about a
memory page is load from memory to the etlb, the corre-
sponding branch of the tree (from the leaf that corresponds to
123
Improving virus protection with an efficient secure architecture with memory encryption, integrity and information leakage protection
the page to the root) is checked. When they are modified, the
corresponding branch is updated. As the root of the tree is
unalterable, with this mechanism, an attacker cannot replay
the information about a page and so it cannot replay data in
memory.
Program identification
In some cases, for instance elec-
tronic voting or open-source digital rights management appli-
cations, it may be useful to have access to the code source (for
example to check that there is no backdoor in the program)
of a secure process that runs in the execution environment
that protects the integrity and confidentiality of its code and
data (because it manipulates sensitive data).
The CryptoPage architecture has a mechanism that
allows the user to know if an encrypted binary file contains
the same program that a non-encrypted binary file. So, if
the user is provided with exactly the same build environ-
ment that the one used to generate the secure application, it
can recompile it from the source and use this mechanism to
know whether the result of this recompilation is the same as
the secure process in spite of the encryption.
The processor computes a cryptographic hash over the
initial code and data of the secure process and returns it to
the user so it can compare it with the one computed over the
program it has rebuilt.
Interrupts
The integrity of any hardware context is pro-
tected with a mac computed with a symmetric key embedded
in the processor, so an attacker cannot modify them, even if
the hardware contexts has to be stored outside of the proces-
sor.
An optional mechanism, based on a log storing informa-
tion about the storage of hardware context outside of the
processor, prevents an attacker from replaying an old hard-
ware context (i.e., trying to reload a secure process in a past
state).
2.2.3 Other mechanisms
Other mechanisms that can be useful to secure applications
are implemented in the CryptoPage architecture.
Attestation
In some cases, a secure application may have to
prove to an external entity that it is running on a Crypto-
Page architecture and so that its confidentiality and integrity
are protected.
In the execution mode that protects both the integrity
and confidentiality, this feature is not necessary because the
secure application can hold secrets (for instance asymmet-
ric keys and certificates) directly embedded in its code (and
hence encrypted). These secrets can be used to established
a secure transmission channel (with the ssl protocol for
example) with an external entity. As the code of the secure
application is encrypted with the public key of the Crypto-
Page processor on which the application will be executed,
and as the corresponding private key is embedded inside the
CryptoPage processor, and so only accessible by it, if the
secure communication is properly established, the secrets
must have been deciphered and so, the application must be
running on a correct CryptoPage architecture.
However, this feature is useful in the execution mode that
only protects the integrity of a secure application because the
solution described before is no longer applicable. Indeed, the
confidentiality of the code and data manipulated by a pro-
cess in this execution environment is no longer protected. So
the CryptoPage architecture has a special instruction that
allow a secure process to ask the processor to sign a result.
The result given by the secure process and an identifier of
the secure process are signed with the public key of the pro-
cessor, and the certificate produced by the manufacturer of
the processor is attached. Thus, the external entity can check
the signature, verify that it was generated by a Crypto-
Page processor and identify the process that produced the
result.
Signals
A special mechanism is implemented to allow the
processing of software signals (used in Unix operating sys-
tems). A signal requires the diversion of the normal execution
flow of a process but this situation can be seen as an attack
attempt by the CryptoPage architecture.
The secure processes can specify to the processor the
address of a function that has to be called whenever a signal
is triggered. The operating system, with a special instruc-
tion, can ask the processor to execute this signal handler for
a secure process. So, the operating system cannot modify the
execution flow as it wants. Another special instruction allows
the operating system to restore the original hardware context
(the one saved before the triggering of the signal) and so,
to restore the original execution flow, but while keeping the
modifications made in memory by the signal handler.
This mechanism also forces the signal starts and the signal
ends to be properly nested.
Secure storage
The CryptoPage architecture provides
each secure process with a small secure non-volatile stor-
age space protected against replay attacks. In this place, a
secure process can store encryption keys or cryptographic
hashes that can be used to protect a larger storage space.
This secure storage mechanism is also based on a Merkle
tree. The root of this storage tree is securely stored inside the
processor. Some of the operations of verification and update
of this tree are delegated to the operating system in order to
increase flexibility but without compromising the security of
the mechanism.
123
[ Pobierz całość w formacie PDF ]

zanotowane.pl

doc.pisz.pl

pdf.pisz.pl

mirabelkowy.keep.pl