Tool/software:
The SHA256 calculation time previously measured with SDK8.30 was about 0.2 ms, but when measured with SDK9.10, it took about 7 ms.
We also confirmed that other operations such as AES took about 7ms as well.
Is this a defensive measure to prevent identification of which operation is being performed by the operation time in anticipation of a side-channel attack?
Would it be possible to perform operations at the original speed by changing some settings?
Hello,
Looking through your code, I see that you are measuring the time of initializing the driver, setting the parameters, opening the handle and then the hash operation. In addition, you're closing the handle of the driver regardless of when you get the callback. This could cause issues in a larger application, you would want to close the handle after the operation has completed.
Note: First time initialization of any crypto driver will cause the HSM to boot incurring some timing cost. Any crypto driver initialized after at least one crypto initialization will be faster since the HSM will have booted.
I've modified the code to account for the intialization:
#include <stdint.h>
#include <stdio.h>
#include <string.h>
/* Driver Header files */
#include <ti/drivers/GPIO.h>
#include <ti/drivers/SHA2.h>
/* Driver configuration */
#include "ti_drivers_config.h"
#define mcU2_SEED_LENGTH 102
static uint8_t au1s_SEED[mcU2_SEED_LENGTH] = { 0x4D,0x08,0x88,0x88,0x88,0x88,0x88,0x88,0x88,0x88,
0x86,0x20,0x43,0xD6,0x05,0x52,0x69,0x99,0xF0,0x32,0xE0,0x8F,0x31,0x4F,0x22,0xEB,0xCE,0x05,
0x1D,0x1D,0xAE,0x53,0xDC,0x71,0xF1,0xC4,0xD6,0x14,0xB0,0x33,0x7B,0xB1,0x7F,0x20,
0x87,0x20,0xF9,0x8C,0xCA,0x31,0x65,0x1A,0xD2,0xE6,0x32,0x66,0x14,0x4B,0x24,0x50,0xFD,0x60,
0x81,0xD8,0xFE,0xA8,0xCE,0xB8,0x26,0xE1,0xFB,0x10,0xE8,0x03,0x4E,0x93,0x24,0x46,
0x4C,0x10,0xBF,0x1C,0x41,0x26,0x82,0x30,0xAF,0x76,0xBF,0xFE,0x3E,0x7C,0x5D,0x00,0xCF,0x4A,
0x93,0x04,0x41,0x5D,0x95,0x69
};
static uint8_t au1s_K[32];
volatile uint8_t flag = 0;
void callbackFxn(SHA2_Handle handle, int_fast16_t returnStatus)
{
/* LED OFF */
GPIO_write(CONFIG_GPIO_LED_0, CONFIG_GPIO_LED_OFF);
flag = 1;
}
/*
* ======== mainThread ========
*/
void *mainThread(void *arg0)
{
SHA2_Params params;
SHA2_Handle handle;
int_fast16_t result;
GPIO_init();
/* SHA-256演算 */
SHA2_init();
SHA2_Params_init(¶ms);
params.hashType = SHA2_HASH_TYPE_256;
params.returnBehavior = SHA2_RETURN_BEHAVIOR_CALLBACK;
params.callbackFxn = callbackFxn;
handle = SHA2_open(0, ¶ms);
GPIO_write(CONFIG_GPIO_LED_0, CONFIG_GPIO_LED_ON);
result = SHA2_hashData(handle, au1s_SEED, mcU2_SEED_LENGTH, au1s_K);
while(1)
{
if (flag == 1)
{
SHA2_close(handle);
}
}
}
Using this setup, I see the hash operation take 302.1us:
In this application callback vs blocking vs polling mode timing differences may be negligible, however, in a larger application with multiple tasks you may incur overhead. The reason behind this is because the HSM IRQ may be pushed to the bottom of the list of ISR's to be serviced, since there may be higher priority interrupts that need to be serviced first. For this reason, profiling the hash operation in callback mode is not recommended, since the callback interrupt may be serviced later, thus resulting in what seems like a longer hashing time.
Hope that helps!
Best,
Nima Behmanesh