-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NX_CRYPTO_SIZE_ERROR during DTLS handshake with PSK-AES128-CCM8 cipher when using FSP's hardware encryption #288
Comments
Hi Henrik, |
@michaelthomasj Thank you. It almost looks like the code for padding the last block is missing in the implementation of the CCM decrypt routine. I had a look at FSP's mbedtls implementation of AES-CCM8 and that one does support arbitrary lengths. Unfortunately its not possible to use mbedtls with NetXDuo, so we depend on a working implementation for NetXDuo. Also the issue would apply not only to DTLS but also to TLS or anything which has to decrypt data using AES128-CCM8. |
Hi Henrik, |
@michaelthomasj Thank you for looking into this issue.
We are not violating the spec because we are not using
If Renesas follows that line of thought, how can we get DTLS to work? It is not our application code which fails, it is Also I like to point out that So if All we want is to get DTLS to work on the Rareness platform. |
Microsofts spec is probably based on the standard AES modes like CBC which requires a 16-byte blocksize. Looking at RFC4309 section 3.2 , AES-CCM does seem to not require plaintext padding and allows a variable payload size. So technically the blocksize restriction would not apply here if I am correct. Microsoft's implementation seems to support AES-CCM's arbitrary payload sizes, in line with RFC4309. |
I extracted our code into a smaller test program. It can be used to connect to the following OpenSSL test server:
Here is the NetXDuo DTLS client program code which is unable to connect to above DTLS server using AES-CCM8 mode.
|
This is being internally tracked using FSPRA-2353. |
FSP's (version v4.5.0) encryption routines fail when calling
nx_secure_dtls_client_session_start()
withNX_CRYPTO_SIZE_ERROR
when using DTLS 1.2 with PSK-AES128-CCM8 cipher during the DTLS encryption handshake message phase.Refer to Wireshark screenshot:
and the error message in OpenSSL's log:
If the original NetX Secure encryption routines without hardware acceleration are used, nx_secure_dtls_client_session_start() with PSK-AES128-CCM8 has no problem to establish a connection.
The issue arises when Renesas' alternative SCE9 based implementation from the
rm_netx_secure_crypto
directory is compiled in (SECURE_ALT_SRCS).During the handshake the DTLS client and server exchange a handshake message with length of 40 bytes which after the nonce of 8 bytes and the icv of 8 bytes lengths each are deducted, results in an encrypted part of 24 bytes. The length of 24 bytes is causing the FSP code problems when decrypting.
I tracked the issue down to the file
nx_crypto_ccm_alt_process.c
. Functionsce_nx_crypto_ccm_decrypt_update()
fails In line 351 because the length passed to sce_nx_crypto_ccm_decrypt_update is 24 and the function does not seem to be able to handle a length which is not divisible by the block length of 16.Tested against the OpenSSL test server using the following command line:
As a result we are unable to use the SCE9 based hardware encryption with DTLS 1.2 and PSK as it is not able to decrypt the 40 byte handshake message.
The text was updated successfully, but these errors were encountered: