Posts Tagged ‘message authentication code

Authentication Primitives for Memory Authentication

Hash Functions: The first strategy (Figure 1.1-a) allowing to perform memory authentication consists in storing on-chip a hash value for each memory block stored off-chip(write operations). The integrity checking is done on read operations by re-computing a hash over the loaded block and by then comparing the resulting hash with the on-chip hash fingerprinting the off-chip memory location. The on-chip hash is stored on the tamper-resistant area, i.e., the processor chip and is thus inaccessible to adversaries.Therefore, spoofing, splicing and replay are detected if a mismatch occurs in the hash comparison. However, this solution has an unaffordable on-chip memory cost: by considering the common strategy of computing a fingerprint per cache line and assuming 128-bit hashes and 512-bit cache lines, the overhead is of 25% of the memory space to protect.

MAC Functions: In the second approach (Figure 1.1-b), the authentication engine embedded on-chip computes a MAC for every data block it writes in the physical memory.The key used in the MAC (Message Authentication Code) computation is securely stored on the trusted processor chip such that only the on-chip authentication engine itself is able to compute valid MACs. As a result, the MACs can be stored in untrusted memory because the attacker is unable to compute a valid MAC over a corrupted data block. In addition to the data contained by the block, the pre-image of the MAC function contains a nonce. This allows protection against splicing and replay attacks. The nonce precludes an attacker from passing a data block at address A, along with the associated MAC, as a valid (data block, MAC) pair for address B, where A 6= B. It also prevents the replay of a (data block, MAC) pair by distinguishing two pairs related to the same address, but written in memory at different points in time. On read operations, the processor loads the data to read and its corresponding MAC from physical memory. It checks the integrity of the loaded block by first re-computing a MAC over this block and a copy of the nonce used on write operation and by then comparing the result with the fetched MAC. However,to assure the resistance to replay and splicing, the nonce used for MAC re-computation must be genuine. A naive solution to assure this requirement is to store them on the trusted and tamper-evident area, the processor chip. The related on-chip memory overhead is 12.5% if we consider computing a MAC per 512-bit cache line and that we use 64-bit nonces.


H : Hash Function, D : Data, C : Ciphertext, N : Nonce

Figure 1.1: Authentication Primitives for Memory Integrity Checking

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