Isap - Light-weight cipherIsap is a light weight block cipher and was written by Christoph Dobraunig, Maria Eichlseder, Stefan Mangard, Florian Mendel, Bart Mennink, Robert Primas and Thomas Unterluggauer. It is focused on robustness against power analysis and fault attacks and where there is a node for small codesize. Overall it uses a sponge-based mode with SPN permutations. Isap has mechanisms to protec gain fault attacks. Isap uses an Encrypt-then-MAC design with two keys for IsapMac and IsapEnc. This page outlines the ASCON version. |
Outline
One of the key areas of protection is in device security, and NIST’s competition on light-weight cryptography aims to assess a range of methods against things like performance, ease of implementation, and robustness. One of the most important aspects is the robustness against side channels, and Isap is one of the methods in the final stage.
Overall Isap focuses on a re-keying approach for a lightweight cryptography method. It is a light weight block cipher and was written by Christoph Dobraunig, Maria Eichlseder, Stefan Mangard, Florian Mendel, Bart Mennink, Robert Primas and Thomas Unterluggauer [2]. Isap is focused on robustness against power analysis and fault attacks and where there is a node for small code size. Overall it uses a sponge-based mode with SPN permutations. Isap also has mechanisms to protect gain fault attacks and uses an Encrypt-then-MAC design with two keys for IsapMac and IsapEnc.
In most methods that protect against DPA, we have a secure side-channel initialization of the key and then use a pre-shared master key and a nonce, and where a new nonce is used for each session. This is useful against an attack on the sender’s encryption process, but it is not so easy to generate different session keys based on the long-term key and the received nonce. One way to do this is to generate a nonce value to all the parties involved, and then allow them to generate session keys from these, but this has significant overhead in communicating the nonce value. The Isap method overcomes this problem by protecting against DPA for both the encryption and decryption process. Along with this, Isap now integrates AEAD, and which allows the ciphertext to be authenticated by the receiver before it is actually decrypted.
With re-keying, we limit the number of processed inputs we can have for each key which is used. Typically, with DPA, we would need many samples of the process for our encryption key analysis, so limiting the number of times it is used, will significantly reduce the opportunity to discover any of the derived keys. With frequent re-keying, as would be seen in areas like RFID tags, we use a new key (\(K^*\)) for every new plaintext, and which is derived from a pre-shared master key (\(K\)), and a nonce (\(N\)). If we define g as the generator function we can represent as:
\(K^* = g:(K,N)\)
As long as our key generator for K* is secure, we should be protected against DPA attacks.
Overall we have three C files and a few header files. To compile we can use the gcc compiler:
gcc main.c isap.c crypto_aead.c -o isap.exe
An outline of the C code is [1]. A sample run is:
ISAP light-weight cipher with ASCON Plaintext: hello Key: 0123456789ABCDEF0123456789ABCDEF Nonce: 000000000000111111111111 Additional Information: Plaintext: hello Cipher: E77D3B5E44ED3F0227A06B, Len: 21 Plaintext: hello, Len: 5 Success!
References
[1] Isap GitHub [here].
[2] Dobraunig, C., Eichlseder, M., Mangard, S., Mendel, F., & Unterluggauer, T. (2017). ISAP–towards side-channel secure authenticated encryption. IACR Transactions on Symmetric Cryptology, 80-105. [paper]