# On the Hardware-Software Integration in Cryptographic Accelerators for Industrial IoT
## 3 System Description
### Sw Architecture of the Proposed System
* exit: when the operation is over or interrupted, it can be used for reading the output (according to the crypto operation), deallocating the data structures and resetting the device. The update function is the one that differs the most according to the algorithm type. For instance, for symmetric encryption data flow in both directions: input data are processed and then sent back to the caller. Whereas, in message digest, no output is produced at this stage. In Listing 1 are listed the callbacks for symmetric encryption. ```
1 int(*setkey)(structcrypto_skiper*tfm,constu8*key,unsignedintkeylen);
2 int(*init)(structcrypto_skiper*tfm);
3 int(*encrypt)(structskepher_request*req);
4 int(*decrypt)(structskepher_request*req);
5 void(*exit)(structcrypto_skcipher*tfm);
```  
Listing 1: Crypto API Callbacks for Symmetric Encryption. To set up an encryption or decryption request, the AES Engine requires three information pieces:  
* Key Size;
* Block cipher mode of operation: ECB, CBC, etc. ;
* Encryption or Decryption. The key size is provided to the hardware when the setkey callback is fired. The other two information pieces are given inside the init and inside the encrypt/decrypt, respectively. This has some consequences on the driver implementation because the operation can be performed only when all these three pieces are known to the hardware. The functions are listed in the call order. The first one that is invoked by the kernel is the setkey. As a parameter of this function, the driver receives the symmetric key that will be used for encrypting or decrypting. As explained in [6], in the AES Engine, the key management system's purpose is to set and then seal all the symmetric keys at boot time in the accelerator, so that any software attack which tries to steal a key is prevented. Unfortunately, this concept cannot be applied when using the Linux Crypto APIs: each key, as far as the driver knows, is disposable and will (probably) not be reused. Then the init function is called. Due to the way this accelerator shall be programmed, the driver cannot perform any configuration on the hardware because it does not know (yet) whether this cryptographic operation will be encryption or decryption. The _encrypt_ (or _decrypt_) function: this function is the main one. It uses two _scatterlists_ for input and output data which require processing or have already been processed. As mentioned above, the device configuration must be performed inside this function because beforehand, the driver did not know what operation to perform. Once this step is complete, the driver can then proceed with all the write and subsequent read operations from the device. As better explained in Section 4 with experiments and results, the MCU Interface used for the I/O operation for this work, which is composed of 32-bit registers for Input and Output, although fully working, is not fast enough and cannot sustain a data rate that would allow the device to reach 100% utilization. In other words, the device spends most of its time waiting for data. The _exit_ function is called in two scenarios: when the operation is over or because the requester has suddenly canceled the ongoing cryptographic operation. The driver does not differentiate these two cases and for this reason, it resets the key slot and the entire engine, so that it is ready for a new request.