Posts Tagged ‘hashing

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 : , , , , , , , , , , , , , ,

Scope and Applicability of Randomized Hashing

Randomized hashing is designed for situations where one party, the message preparer, generates all or part of a message to be signed by a second party, the message signer. If the message preparer is able to find cryptographic hash function collisions (i.e., two messages producing the same hash value), then she might prepare meaningful versions of the message that would produce the same hash value and digital signature, but with different results (e.g., transferring $1,000,000 to an account, rather than $10). Cryptographic hash functions have been designed with collision resistance as a major goal, but the current concentration on attacking cryptographic hash functions may result in a given cryptographic hash function providing less collision resistance than expected. Randomized hashing offers the signer additional protection by reducing the likelihood that a preparer can generate two or more messages that ultimately yield the same hash value during the digital signature generation process – even if it is practical to find collisions for the hash function. However, the use of randomized hashing may reduce the amount of security provided by a digital signature when all portions of the message are prepared by the signer.

In randomized hashing, a quantity, called a “random value,” or rv, that the preparer cannot predict, is used by the signer to modify the message. This modification occurs after the preparer commits to the message (i.e., passes the message to the signer), but before the signer computes the hash value. The technique specified in this Recommendation does not require knowledge of the specific cryptographic hash function; the same randomization process is used regardless of the cryptographic hash functions used in the digital signature applications. Protocol and application designers should select cryptographic hash functions believed to be collision resistant, and then consider the use of the randomized hashing in the design of their protocol or application whenever one party prepares a full or partial message for signature by another party.

The randomization method specified in this Recommendation is an approved method for randomizing messages prior to hashing. The method will enhance the security provided by the approved cryptographic hash functions in certain digital signature applications.

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 : , , , , , , , , , , , , , , , , , , , ,

Wireless biometric verification

We designed our security protocols to operate on an embedded implementation. For example, the verification protocol in Figure 3 combines elements of challenge–response symmetric-key authentication and biometric verification. The protocol assumes that a shared key K exists between the device and the server. The device stores the template, while the server stores a hash of the template H(K, TEMPLATE). The device initiates a verification transaction by transmitting its ID to the server. After corroborating the device’s identity, the server sends two random numbers, RAND and RANDT, to the device (in the figure, | denotes concatenation). The device receives these values and begins the biometric-verification protocol. After obtaining the user’s fingerprint locally, the device extracts the candidate minutiae and compares them with the stored template. If the match is positive, the device loads the key K and generates the hash of the template H(K, TEMPLATE). If the match is negative, the device loads a dummy key, setting K = 0, and a dummy template, setting H(K, TEMPLATE) = 0.

Next, the device encrypts RAND to create a session key SK = E(K, RAND). It uses the session key to encrypt RANDT concatenated with H(K, TEMPLATE), producing an authentication token TOKEN = E(SK, RANDT | H(K,TEMPLATE)), which it forwards to the server. The server decrypts the token and the transmitted template hash H(K, TEMPLATE), and compares the template hash with the stored hash to check the device’s authenticity. The server then sends a final transaction result to the device and lets it access the system if all tests check.

Figure 3. Device-based verification protocol. The device interacts with the user and the server to perform a biometric authentication transaction where all biometrics are performed on the device. (Bold text signifies secure functions.)

A single-level security flaw at the protocol level could allow a server masquerade attack. Because the device never authenticates the RAND | RANDT values, a false server could easily send these values undetected. We can fix this at the protocol level by requiring the server to send an additional hash, say H(SK, RAND |RANDT | ID), to the device, where SK is a session hash/message authentication code (MAC) key. The device can then authenticate the server at each transaction. Other solutions at this level include using a MAC to protect token integrity, sequence numbers to prevent replay attacks, or a different key for token hashing. Figure 3 shows a software bypass attack, an example ofa translevel security flaw. In this attack, the adversary inserts malicious software into the device to bypass the biometric functions. Directly after receiving the random numbers, the hacked program loads the key K, falsely telling the device that a match has been made. This attack effectively breaks the biometric tie between the user and device, letting anyone use the hacked device without a correct fingerprint. The server assumes that the device is operating properly, so it allows unauthorized access to system resources. We can’t fix the software bypass attack at the protocol level because it modifies any protocol it encounters. Instead, we must take measures at the architecture and microarchitecture levels.

This protocol performs all biometrics on-device for maximum security. We can design a suite of protocols that variously partitions the biometric functions between the device and server, based on the limitations of embedded performance, latency, energy, and memory. Protection mechanisms similar to those used for the secret key should safeguard the template; in fact, greater protection mechanisms might be necessary because keys are replaceable, whereas biometrics are not. Future directions for template storage involve storing a transformation (hash) of the template and performing a match directly in the transformed space. Further considerations of biometric security are available elsewhere. Alternatives to embedded biometrics for authentication include smart cards, RFID tags, and secure authenticators such as RSA SecurID.

 

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