Posts Tagged hash value
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.