openssl offload crypto to hse

[eone]

Hi,NXP

i am using BSP36.0 on s32g274ardb2, when try use openssl offload crypto operation to hse, its not take effect;What should I do to make it effective?

Here are some outputs: 

[lakshaypiplani]

For authenticating kernel from uboot, I am using FIT image containing RSA private key and loading  image using bootm command.
currently I am storing  public key certificate for authentication of FIT image to be loaded in device tree,
can i store public key certificate for verification in hse NVM key catalog/ RAM key catalog instead of device tree for authentication of kernel from uboot using FIT image.??? 
@Daniel-Aguirre 

[Daniel-Aguirre]

Hi,

The available information on regards HSE under Linux for S32G platform is the one provided under the BSP User Manual. As for OpenSSL, the following information is seen under the User Manual:

For which, some pre-requisites are mentioned. Have you followed them? There is also an example available:

Have you taken a look into it?

Please, let us know.

[eone]

yes, i use pkcs11-tool and hse_demo success, aes and rsa work success through HSE.

can i use openssl user api to call hse? thats "S32G Vehicle Integration Platform (GoldVIP) User Manual" 18.1 phrase mentioned, offload crypto opera to HSE.

[Daniel-Aguirre]

Hi,

Thanks for your feedback.

HSE can offload cryptographic operations through the kernel Crypto API, as said under the BSP User Manual:

We do not see any other mention about OpenSSL aside from the information provided before. But again, HSE requires the usage of the kernel Crypto API if you want to offload the cryptographic operations.

Please, let us know.

[eone]

Hi NXP,

I am now tring to use hse crypto APIs by openssl on S32G.
I take "Linux BSP 36.0 User Manual for S32G2 platforms" section 10 as reference, and make linux kernel menuconfig as below(choose MU1):

 

When power on S32G_RDB2, the kernel log shows "hse 40211000.mu1b: MU interface not active",how can I fix it?

By the way，the HSE firmware is HSE_FW_S32G2_0_1_0_5. Does this firmware activate MU1 correctly？

[Daniel-Aguirre]

Hi,

Are you writing any commands after you enable MU1 under menuconfig?

We have the following commands provided by the internal team:

"NOTICE: Reset status: Power-On Reset
NOTICE: BL2: v2.5(release):bsp36.0_cd-2.5
NOTICE: BL2: Built : 10:52:45, Mar 16 2023
NOTICE: BL2: Booting BL31

U-Boot 2020.04 (Mar 16 2023 - 10:49:34 +0800)

...

[ 0.894802] hse 40211000.mu1b: MU interface not active

...

root@s32g274ardb2:~# ls
hse-encrypt hse-secboot hse-sysimg pkcs-key-provision pkcs-keyop
root@s32g274ardb2:~# ldconfig -l /usr/lib/libpkcs-hse.so
root@s32g274ardb2:~# ldconfig -l /usr/lib/libcrypto.so.1.1
root@s32g274ardb2:~# ldconfig -l /usr/lib/libhse.so.1.0
root@s32g274ardb2:~# ldconfig -l /usr/lib/libp11.so.3.4.3
root@s32g274ardb2:~# ./hse-secboot -h

format HSE key catalogs or set up HSE-based advanced secure boot

Usage:

./hse-secboot [-h] [-f|s] [-k keypath] [-d devpath]

-h: display this help string
-f: format key catalogs
requires -d
mutually exclusive with -s
-o: force overwrite of HSE key catalog
-s: set up advanced secure boot
requires -d and -k
mutually exclusive with -f
-k: specify full path to PEM format key file
-d: specify full path to SD device (e.g. /dev/sdb)

root@s32g274ardb2:~# ./hse-secboot -f -d /dev/mmcblk0
[INFO] Formatting HSE key catalog
hse: device initialized, status 0x0920
[INFO] Retrieving IVT from device /dev/mmcblk0
[INFO] Enabling MUs
[INFO] Formatting NVM and RAM key catalogs
[INFO] Retrieving SYSIMG size
[INFO] Publishing SYSIMG
[INFO] Writing SYSIMG to /dev/mmcblk0
root@s32g274ardb2:~# NOTICE: Reset status: Power-On Reset
NOTICE: BL2: v2.5(release):bsp36.0_cd-2.5
NOTICE: BL2: Built : 10:52:45, Mar 16 2023
NOTICE: BL2: Booting BL31

...

[ 0.894824] hse 40211000.mu1b: premium firmware, version 1.0.1
[ 0.901025] hse 40211000.mu1b: registered algs sha1,hmac(sha1)
[ 0.907198] hse 40211000.mu1b: registered algs sha224,hmac(sha224)
[ 0.913718] hse 40211000.mu1b: registered algs sha256,hmac(sha256)
[ 0.920235] hse 40211000.mu1b: registered algs sha384,hmac(sha384)
[ 0.922555] mmc0: SDHCI controller on 402f0000.mmc [402f0000.mmc] using ADMA
[ 0.930734] hse 40211000.mu1b: registered algs sha512,hmac(sha512)
[ 0.940252] hse 40211000.mu1b: registered alg ctr(aes)
[ 0.945651] hse 40211000.mu1b: registered alg cbc(aes)
[ 0.951007] hse 40211000.mu1b: registered alg ecb(aes)
[ 0.956409] hse 40211000.mu1b: registered alg cfb(aes)
[ 0.961761] hse 40211000.mu1b: registered alg ofb(aes)
[ 0.967133] hse 40211000.mu1b: registered alg gcm(aes)
[ 0.972530] hse 40211000.mu1b: registered hwrng-hse
[ 0.977527] hse 40211000.mu1b: device ready, status 0x4B20

"

Please, let us know.

[eone]

hi, NXP, thank you for your reply.
Follow the instructions you provided, MU1 is actived and algorithm successfully registered

When I tested using OpenSSL with af_alg engine, I found that only aes_cbc could call HSE!!! aes_ctr and sha256 may not taken effect

What should I do to call all algorithm operations registered with HSE through OpenSSL?
thanks, Looking forward to your reply.

[Daniel-Aguirre]

Hi,

We have received the following update:

"That's because the (default) af-alg engine only supports the algorithm AES-CBC, please check source code of AF-ALG engine in OpenSSL.
For example, for OpenSSL 3.0.7 version, in the source file engines\e_afalg.c, you can find the supported NIDs:

static int afalg_cipher_nids[] = {
NID_aes_128_cbc,
NID_aes_192_cbc,
NID_aes_256_cbc,
};

In order to support other algorithms, you need to enable that in the engine. Unfortunately, we don't have sample code for this."

Please, let us know.

[eone]

Hi,NXP

following your prompts, I tried adding several algorithms:

Testing found no effect, the interrupt about hse in /proc/interrupt did not change;

Is it related to the following implementation? the afalg_ciphers function only aes algorithms

 How should I modify can use other algorithms link AES offload to hse?

Looking forward to your reply, Thanks!!!

[Daniel-Aguirre]

Hi,

Thanks for your feedback. Since the following was told before:

"In order to support other algorithms, you need to enable that in the engine. Unfortunately, we don't have sample code for this."

We may not be able to provide the specific modifications required, under this channel.

Still, we will verify if we can provide the required modifications. In the meantime, we can recommend either looking into our available Partners (link: Partner Directory | NXP Semiconductors) or contacting your local NXP FAE, since you are looking for SW customization, which is not commonly supported under the NXP online service/community. We do apologize.

Please, let us know.

[eone]

Thank you for your reply,  Looking forward to your feedback

[Daniel-Aguirre]

Hi,

We have received the following update:

"Your modifications doesn't help much. You need to implement mechanisms in the engine code for new algorithms, to offload OpenSSL cryptographic operations to corresponding kernel crypto API. 

You can refer to sample code in OpenSSL source code (engines/), or some open source projects on github. For example: https://github.com/cotequeiroz/afalg_engine."

Please, let us know.

[eone]

hi,NXP

I tested the openssl software and AF_ALG engine (offload HSE), and found that the performance was worse after using the AF_ALG engine (offload HSE), Can you tell me why?

Here are the test data:

I used openssl's own performance testing command, the AF_ALG engine was not used on the left, and used on the right. I checked and found that there was indeed an increase in HSE interrupts when use AF_ALG.

 This is test of hash, left use openssl EVP api and right use kernel socket

 

 

[Daniel-Aguirre]

Hi,

Thanks for the information. Could be that there is bottleneck when sending the information to offload with HSE. Could be that the offload still requires some optimization.

Still, we will confirm if this behavior is expected or not. Can you help us with the measurements of the 16, 64, 256 and 1024 bytes? Unless we are not understanding the tables you have shared, we find that the first has different lengths than the second one.

Please, let us know.

[eone]

hi，NXP

the first data table is the performance test that comes with OpenSSL: the amount of data that can be encrypted per second, which clearly shows that pure software has a higher than offloading throughput compared to HSE.

The second table shows my time consumption testing of the interface. I did not test according to the bytes provided by OpenSSL, but calculated a byte change myself, which is consistent with the throughput results. The time consumption of pure software interfaces is much lower than that of HSE  hardware offload.

If that's the case, using HSE offload sacrificing performance. According to the link you provided, the performance of hardware processing large bytes should be better than that of software?

and then, Can I use HSE to accelerate openssl software algorithm operations?

thanks!!!

[Daniel-Aguirre]

Hi,

Thanks for your feedback. 

We know understand the 2 tables you have shared. Thanks for the description. The link we have shared was just an example of an open-source project, but it is not NXP developed, for what we can see.

Offloading to HSE should improve the performance, but this is by using the NXP Crypto API. As said before:

"As for OpenSSL, the following information is seen under the User Manual:

"

And this is the only information available at this moment regarding OpenSSL. We cannot confirm nor deny that HSE can offload OpenSSL software operations (aside from those under PKCS11), since there are no further guidelines on doing it.

Still, we will verify if the numbers are expected or not.

Please, let us know.

[Daniel-Aguirre]

Hi,

We have received the following update:

"When the AF_ALG engine is used, the software overhead is increased due to HSE driver and data exchange between linux kernel and user space. So, not surprise you got worse performance when using AF_ALG engine, specially for small data chunks.

I'm not sure about your use case. The top advantage of using HSE is the security, but not the performance. This is not to say, the performance of HSE is low."

For looking into the HSE benchmark, we can recommend sending the inquiry to your local NXP FAE/DFAE, for them to process the request. We do apologize.

Please, let us know.

[eone]

hi,NXP

thanks for you feedback;

I conducted the following experiments based on the BSP36 guidance manual.

use the HSE reference link provided in the BSP36 manual: https://github.com/nxp-auto-linux/pkcs11-hse AES crypto was performed on data with different bytes, The code for AES_128_CBC testing is as follows:

At the same time, the same encryption and decryption code for the openssl interface was written, as follows:

Both scenarios were tested 10000 times and the average value was taken. The results showed that OpenSSL performed better at any length. The following are the statistical results of the test:

The performance of the pkcs_hse.so provided by NXP test results is also poor compared to the openssl software algorithm. Can you help confirm whether the test data results are normal?

and may I ask what the reason is?

[Daniel-Aguirre]

Hi,

We may be misunderstanding your implementation, but looking into the provided HSE Benchmarks, we see that, even if HSE might not surpass OpenSSL, it should be closer than the results you are showing.

Again, could be we are misunderstanding the implementation.

Since HSE-FW information is confidential as well as the benchmarks themselves, help us contacting your local NXP FAE, for them channel this last request for either a reviewal of the implementation or access the test setup of the benchmarks, if possible.

We do apologize.

Please, let us know.

[Daniel-Aguirre]

Hi,

Thanks for your feedback. Let us verify if it possible and how.

Please, let us know.