Mbed forum

Need help of embedtls for Nuvoton NUC472 SoC Porting

mbed_tls
(Ritesh Prajapati) #1

Myself Ritesh Prajapati working as Team Leader into System Level Solutions and we have few queries regarding embedtls library.

We are working on Nuvoton NUC472 (ARM Cortex-M4) chip as Industrial Automation Gateway and we are trying to port embedtls library for secure connection. We have ported same library over ESP32 WiFi chip and it successfully worked without any issue and able to create secure connection within 2 seconds of interval.

But, When we tried to do same thing over Nuvoton NUC472 chip with same code then it takes almost 35 to 40 seconds to create secure connection which is too long for us as well as standard industrial gateway product.

We have also tried to port all global buffers and variable from external RAM into internal RAM but still issue remains same.

So, Do you have any idea or anyone of your client faced this type of issue into past?

Let me know if need any more details regarding embedtls library or porting related stuffs from my side to understand our problem in details

(Ritesh Prajapati) #2

Hi Support Team,

Please find below software details regarding Nuvoton NUC472 Arm Cortex-M4 which we are using for our project requirement.

  • Running CPU on 84 MHs and it supports upto 84 MHz only
  • It supports AES, DES and SHA Hardware Accelerator and we have checked with that and also without that.

Let me know if need any more details regarding same.

(Ron Eldor) #3

The bottleneck in the handshake operations is the key exchange, and certificate verification. In case you are using an ECC based ciphersuite, the ECC operations consume time, and this is dependent on the MCU clock on your chip, as these operations run on the MCU, unless you ported an alternative HW acceleration implementation.
Note we are working on a feature for a “resumable \ Restartable ECC operation”, which will split the ECC operations to several parts, allowing you to do other operations in between. This feature should be introduced in the near future.

I believe that https://tls.mbed.org/discussions/generic/optimized-bn_mul-for-arm-with-thumb2 and https://tls.mbed.org/discussions/generic/long-tls-handshake-connection-time may assist you in improving the performance.

Since your ECC operations are working on your CPU, it is very much dependent on your CPU clock. What’s the clock of your ESP32 board?

(Ritesh Prajapati) #4

We are running ESP32 on 160 MHz and checked it but it supports upto 240 MHz as well.

But I don’t know why there are too much different while comparing results between ESP32 and Nuvoton ARM Cortex-M4.

Does anyone has tried to use it over ARM Cortex-M4 based CPU?

(Ron Eldor) #5

As you stated, the ESP32 frequency is much higher, which explains reason for improvement.
There could also be different in assembly code for the bn_mul optimizations.

As mentioned in previous comment, https://tls.mbed.org/discussions/generic/optimized-bn_mul-for-arm-with-thumb2 have explanations for performance improvements, on a Coretx M4 CPU

Regards,
Mbed TLS Team member
Ron

(Ritesh Prajapati) #6

Hi,

I will check with few options provided in your last post and let you know results as soon as possible.

(Ritesh Prajapati) #7

Hi Support Team,

Please find following more details regarding mbedtls library and it’s component related details which we are right now using for our project requirement

  • mbedtls library version :- mbed TLS 2.3.0

We have checked each and every APIs into details and found one thing that mbedtls_pk_sign() function is taking almost 30-35 secs while establishing connection with our Nuvoton NUC472 ARM Cortex-M4

Also, We are using RSA Key of almost 1250 Bytes long for secure connection.

Let me know if need anything else regarding Security Keys and other stuffs from our side for more analysis.

(Ron Eldor) #8

Hi Ritesh,
Since you are using RSA based verification, the links I sent you are less relevant.
Is there a reason you are using such a big key ? Are you verifying \ signing the hash of the message? Is it possible for you to use an ECDHE key exchange?

(Ritesh Prajapati) #9

Hi,

Sorry for late Reply.

There is no any specific reason to use such a big length RSA key but can’t we use that much length key for secure connection? If not then would you please suggest recommended key for RSA key to use for secure connection?

What is the difference between RSA and ECDHE key as I don’t know difference between them? Can we use ECDHE key in place of RSA key?

Generally we are using RSA and AES key for Endpoint Authentication for our application requirement purpose.

Please find below useful information for same.

" In the default implementation, Kaa platform uses hybrid encryption system that is based on RSA with 2048-bit key pair and AES with 256(512)-bit key. During the start of a new session, every endpoint sends an encrypted and digitally signed session key. Session key is a randomly generated AES key that is also encrypted with public key of the Kaa node that handles this session or request. The digital signature of a session key is based on the private key of the endpoint. To authenticate an endpoint and validate its request, Kaa node validates the digital signature of the session key.

Although other authentication strategies are possible, they are out of scope of this section."

Please find below link for reference purpose

https://kaaproject.github.io/kaa/docs/v0.10.0/Programming-guide/Key-platform-features/Devices-provisioning-and-registration/

https://docs.kaaproject.org/plugins/servlet/mobile#content/view/16417884

Hope this will be helpful information for you to understand it.

Still let me know if need any information regarding this.

(Ron Eldor) #10

HI Ritesh,
Thank you for your information. I will answer your questions one by one.

There is no any specific reason to use such a big length RSA key but can’t we use that much length key for secure connection?

The bigger the RSA, the more secure the operation is. However, the bigger the key is, the longer it takes to do the mathematic operations it requires. In your previous comment, you mentioned you are using a 1250 Byte key. This is more than 8192 bit key size, which is highly secure, however long in processing time. In your citing, you mention a 2048 bit key size, so it puzzles me you are

If not then would you please suggest recommended key for RSA key to use for secure connection?

It is better you consult with your security experts regarding the key size you should be using, according to your threat model. However, in my view it is enough you use a 4096 bit key size for your RSA operations.

What is the difference between RSA and ECDHE key as I don’t know difference between them? Can we use ECDHE key in place of RSA key?

ECDHE is Elipric Curve ephemeral Diffie Hellmann Key exchange. ECC keys are shorter in length of RSA keys of same security strength, You can see in the table here that having the same security strength of a RSA 7680 bit key size is a 384 bit key size for ECC.
However, from your description in last comment, you are not using a key exchange algorithm, but a hybrid solution, which uses RSA to encrypt a symmetric key, and then use the key in the operation. ECC is not used for encryption, but only for key exchange and signature verification operations, so you cannot use ECC for your solution.
At first, I was under the assumption you are asking about TLS negotiation. Is there a reason why you aren’t securing the connection with TLS, but your own solution, as mentioned in your citing:

Although other authentication strategies are possible, they are out of scope of this section.

?

If you must use this hybrid solution, then I would recommend using a shorter key size. If 2048 bit key size is enough for your endpoint authentication, according to your link, then why are you using a 1250 byte key?

Regards,
Mbed TLS Team member
Ron

(Rahul Patel) #11

Hi Ron,
I am Rahul, working with Ritesh. Thanks for the detailed explanation.
First, we miss-understood the size of RSA key which is being used. Its actually 2048 bit key. As per some debugging mbedtls_pk_sign() is taking the over all time which is @30-35 seconds.
So I believe making signature takes this long time, hash length is 0 with this mbedtls_pk_sign(). Its generating 256bytes long signature with hash of message is of size 32 bytes long.

(Ritesh Prajapati) #12

Hi Ron,

Would you please check suspected area into " mbedtls_pk_sign()" like where it will take much time to generate 256 Bytes signing key for specific target?

Let us know if need any more details regarding overall Encryption and Security steps for that

(Ritesh Prajapati) #13

Hi Ron,

Do you have any update regarding " mbedtls_pk_sign()" which is taking too much time in our case? Let me know if need anything ellse or want to debug more for this issue from our side

(Ritesh Prajapati) #14

Hi Support team,

Do you have any update regarding " mbedtls_pk_sign()" which is taking too much time in our case?

(Ritesh Prajapati) #15

Hi Support team,

Do you have any update regarding " mbedtls_pk_sign()" which is taking too much time in our case? Let us know if you find anything or any suggestion regarding that

(Ron Eldor) #16

Hi Ritesh,
mbedtls_pk_sign() is anj operation that takes time. It depends on your CPU.
Have you looked in https://tls.mbed.org/kb/how-to/reduce-mbedtls-memory-and-storage-footprint about tradeoff between performance and memory?
Have you managed to see if your code runs the assembly operations in bn_mul ?
Could this PR assist you?

If you are using a hybrid solution, as described earlier, then why are you calling mbedtls_pk_sign()? A hybrid solution means you are encrypting the key using RSA, and then using the key for your symmetric operations.
If you are signing data, it is better you use ECC algorithms, as suggested earlier.
Regards,
Mbed TLS Team member
Ron

(Ritesh Prajapati) #17

Hi Ron,

Sorry for late reply.

We will check and let you know further update regarding this ASAP.