Posts Tagged ‘XOM

Execute-Only Memory (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 partitionis 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 usea 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.

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 de/ciphering, 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 example).

The first proposed version of XOM is known to have security holes like noprotection 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 mustbe 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.

Tags : , , , , , , , , , , , , , ,

XOM, a secure architecture in Embedded Systems

XOM is the acronym of eXecute Only Memory. XOM wishes to completely secure an architecture. Moreover XOM is supposed to be sure and claimed that hardware solutions are more efficient than the software ones. So XOM mostly relies on hardware mechanisms to ensure security. New primitives are provided within the OS in orderto handle key and signature manipulation. The name of the OS extension is XOMOS. The main features of XOM are : memory ciphering and hashing, data and program partitioning, interruption and context switching protection.

Each partition of the memory is associated with a secret key to decrypt its content (the session key in Figure 3). The session key is obtained with the XOM key table which establishes the connection between the session key and the secret keyof a specific partition of the memory. The secret key is also encrypted with an asymmetric encryption. The key (private keyin Figure 3) required for the asymmetric decryption is stored in the secure zone of the architecture. The use of the hash solution is classic. The signature result of the hash algorithm is compared with the original one to validate the integrity of the hashed message. In addition the data stored in cache memory is associated with an identifier. When a task wants to use adata, the identifier of the task must be the same as the data one, in that case it means the task is allowed to read and modify the data. This feature protects the system from malicious program which tries to get illegal information. XOM proposes hardware security primitives to protect cipher keys and hash signatures which are essential to guarantee the architecture durability.

Fig. 3. XOM architecture

The last point of the XOM solution concerns the preemption within the OS which has similarities with the management ofthe interruptions. The context must be saved. It is essential to store and to protect the context in order to fend off an attack who aims to change some register values. XOM ciphers and hashes the switching context which is interesting for a solution with an OS. XOMOS can be seen as an extension of a non-secure OS which brings new security primitives (ciphering and hashing).

All the protections added by the solution have a cost. The first one concerns the implementation of XOM in an existing OS. A work is necessary on the kernel to add the instructions which help for the use of the security primitives. All this work is invisible for the user of the kernel. A real overhead appears inthe cache management. The number of cache miss raises from 10 to 40%. It depends on the kernel operation. This raise is due to the information added in the cache to secure the data. Data are associated with the identifier of the task. It means some parts of the cache are used to store the identifier. The protection of the context switching also brings an increase of the number of cycles to store the context and to protect it.

 

Tags : , , , , , , , , , , , , , , , , , , , ,