Archive for April, 2012

Execute Only Memory or XOM

The XOM approach, which provides memory protection, is based on a complex key management.
The main XOM features are: data ciphering, data hashing, data partitioning, interruption
and context switching protection. Figure 1.0 and 1.1 give an overview of the XOM
architecture and mechanisms. All the security primitives are included in the trusted
zone. The only security information which are not in the trusted zone are the session
keys. That is why XOM owns a complex key management to guarantee a secure architecture.

Figure 1.0: XOM architecture for write request

Figure 1.1: XOM architecture for read request

In order to guarantee the data confidentiality and integrity, each memory partition
is associated with a session key which is needed to decrypt its content. Encrypted
session keys are stored in main memory and can be decrypted using an asymmetric
cipher algorithm (RSA in XOM case). Decrypted session keys are stored in the XOM
key table (in the secure zone). The private key required for the asymmetric decryption
is stored in the secure zone of the architecture (RSA key in Figures 1.0 & 1.1). The
algorithm used for the symmetric deciphering is an AES 256 (256 bits key and 256 bits
data input). For write requests, a hash value of the data and its address are concatenated
with the data before ciphering with AES. The use of the address in the hash value is
there to prevent the relocation attacks. When the core produces a cache miss for a read
request, the 256 bits read from the memory need to be decrypted (Figure 1.1). Data
integrity is ensured by a hash value relying on a MD5 computation. The hash of the
deciphered data and its address are compared with deciphered hash value. If the new
computed hash value matches with the deciphered one the data is considered secure
and can be used by the processor.

In addition, the data stored in cache memory are associated with an identifier or tag
in order to guarantee the data partitioning at a cache level. When a task needs to use
a data, the task identifier must be the same as the data, in that case it means the task
is allowed to access the data. The tag value are provided by the XOM key table which
also manages this part.

The last XOM security feature concerns OS preemption which has similarities with
interruptions management (in both cases register values are pushed into the stack). During
a context switching, if the architecture is running a secure application, the register
values need to be stored securely (values are ciphered, hashed then stored in the external
memory located in the untrusted zone). It is essential to store and protect the
context in order to fend off an attack who aims to change some register values. XOMOS,
which is the software extension of a non-secure OS, brings the software support
for the new security primitives added in hardware.

All the protections added by this solution have a cost. The first one concerns the
XOM implementation in an existing OS. A work is necessary on the OS kernel to add
the instructions which help for the hardware security primitives use. All this work is
transparent for the kernel user. According to the figures from, a real overhead
appears in the cache management (cache miss raises from 10 to 40% depending on the
application). This raise is mainly due to the information added into the cache to secure
the data. Indeed, by adding some data tagging, some space in the cache memory is lost
compared with a non protected solution. Moreover, all the security features are bringing
some latency in the system to obtain the data in clear (data deciphering, hashing,
tag checking). Even if these security primitives are done in hardware, the general architecture
performances are slowed down. The decryption needs to be done before the
integrity checking. These two operations are not done in parallel, so some more latency
is added. Some latency is also added to the software execution because of some
software security primitive (secure context switching add some specific instruction for

The first proposed version of XOM is known to have security holes like no
protection against replay attacks. In the authors extended the proposition and
replaced the AES-based ciphering scheme with a system based on OTP to guarantee
protection against replay attacks and also to increase the performances of the system.
Concerning the global security level of the XOM architecture, the attack possibilities
are fully dependent on the integrity checking capabilities. To succeed, the attacker must
be able to pass through the integrity checking in order to execute his own program or
use his own data. He may exploit some collisions in the hash algorithm used. For
example, with MD5 the signature is 128 bits long. If he wishes to attack the system,
he needs to find two inputs which will produce the same result with MD5. So he has
one chance out of 2128 to get the same result. The security level of the XOM mainly
depends on the hash algorithm used, because SHA-1 could be used for integrity checking.
In this case the signature would be 160 bits long and the probability of success
would be one out of 2160.

, , , , , , , , , , , , , , , , , , , , , , ,

Leave a comment

A Comparison between Subtree Encryption and Server side Access Control


Subtree encryption (element wise) is a good and straight-forward solution for XML Encryption
and it will fit into most situations. The encrypted entity can be transferred to
the client without a need for an additional encryption on the transport layer (like SSL).
The XML entities can be stored encrypted on the (potentially insecure and vulnerable)
web server. The decisions about access rights to different portions of the document can
be made by the document creator and be immediately applied to the XML document.
Encryption has to be applied to each document individually, but in analogy to extensible
stylesheet transformations (XLST), it should be possible to apply an “encryption
policy stylesheet” to a XML document which allows an automatic encryption process
based on a defined policy.


In contrast to this model, server-side access control has much more flexibilty in the resulting
document, because the confidentiality transformation is not constrained to
complete subtrees. The pruning of sensitive or classified information prevents the requesting
client from accessing this information, but during the transfer to the client,
there is a need for an additional encryption on transport layer (like SSL). The access
control processor needs to be secure and trustworthy, because this centralised element
has access to the complete information base. A disadvantage is the need to make
AC decisions online.

The access rights for a specific document have to be added to the ACL (access control
list) database. An advantage of this model is the ability of applying a specific ACL to a
large class of documents (based on DTD/Schema).

Table 1: Comparison between the existing models (disadvantages are marked grey)

It could be nice to get the best from subtree encryption and server-side AC:

  1. allow unencrypted (visible) content within an encrypted subtree
  2. does not need a trustworthy online access control processor (only encryption, no online
  3. no need for additional encryption

, , , , , , , , , , , , ,

Leave a comment

Memory errors in C : Terminology

Using terminology from SafeC, memory errors in C programs can be classifieds into two
different types:

(1) Spatial memory errors and

(2) Temporal memory errors.

Spatial memory errors in C programs include array bounds violations (i.e., buffer
overrun) errors, uninitialized pointer dereferences (causing an access to an invalid
address), invalid type conversion errors, format string errors, etc. Temporal memory
errors include uses of pointers to freed heap memory and uses of pointers to an
activation record after the function invocation completes.

Here we focus on detecting uses of pointers to freed heap memory. In previous work,
we have described techniques for detecting spatial errors with very low overhead,
which also exploits Automatic Pool Allocation to reduce run-time overhead. Those
techniques (and other approaches that detect spatial errors) are complementary to
our approach here because our approach here does not use any metadata on individual
pointers or objects and does not restrict adding such metadata. For dangling pointer
accesses to stack objects, some combination of compile time escape analysis, run-time
checks, or converting possibly escaping stack allocations to heap allocations can be
used. By dangling pointer errors we mean use of pointers to freed heap memory, where
use of a pointer is a read, write or free operation on that pointer.

, , , , , , , , , , ,

Leave a comment

%d bloggers like this: