Hi All,
A gentle reminder that the Asia-Europe timezone-friendly MBed TLS Tech
forum is next *Monday, Feb 27th at 10:00am UK time*. Invite details can be
found on the online calendar here
<https://www.trustedfirmware.org/meetings/>.
As usual, if anyone has any topics, please let Dave Rodgman, cc'd, know. :)
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hi,
I'm using AES 128 GCM with TLS 1.2 and trying to understand the AES key expansion code for decrypting received SSL records.
I'm not an expert on AES but as I understand it, we use the IV (4 byte salt + 8 byte explicit nonce in the received message), pad to 16 bytes, increment and use this as input to the AES key expansion for the first block of ciphertext. This produces a round key per AES round (10 rounds for AES 128). We then increment our IV as input to the key expansion and generate the rounding keys for the next block.
I noticed aesni_setkey_enc_128 in aesni.c contains the Intel AES-NI instruction AESKEYGENASSIST which helps with key expansion.
However, what's confusing me is when I add a breakpoint in GDB, this function is only called once, via mbedtls_ctr_drbg_seed in ctr_drbg.c. I thought we need to do the key expansion on every block, to generate the round keys?
I kept looking at the code and I noticed mbedtls_aesni_crypt_ecb, which contains the Intel AES-NI instructions for performing decryption.
This loads the round key via ctx->buf + ctx->rk_offset but I do not see any code updating this round key per block.
Could someone please explain where the round keys are generated for each round, per block?
Thanks,
Hi All,
I have a couple of tasks which use LWIP and which get suspended for a
few seconds during TLS RSA/EC crypto. One (a primitive http server)
uses Netconn and the other (a serial to TCP data copy process) uses
sockets.
I also have a number of tasks which don't do any networking and which
run as they should, throughout. Experimentation of what priority these
need is difficult but it looks like it needs to be at/above the tasks
which invoke TLS. If their priority is 0 then TLS hangs them up as
well.
After much experimentation with RTOS priorities, this is what I found,
and I wonder if it is right:
TCP/IP applications (whether using the LWIP Netconn API or the LWIP
socket API) should run at a priority equal to or lower than that of
LWIP itself which [in this project] is osPriorityHigh (40). TCP/IP
applications can be run with a priority all the way down to
tskIDLE_PRIORITY (0).
The exception is if TLS is in use. TLS does not yield to the RTOS; you
get a solid CPU time lump of ~3 secs (STM 32F417, hardware AES only).
TLS starts in the priority of the task which invokes it, but
subsequent TLS-driven TCP/IP operations run at the priority of LWIP.
So when TLS is doing the session setup crypto, tasks of a priority
lower than LWIP get suspended. If this gap is an issue, the priority
of the relevant tasks should be equal to LWIP's. Furthermore, due to
the structure of LWIP, the priority of a task using it should not be
higher than LWIP (24) since it might cause blocking on socket (or
netconn) writes.
Does this make sense?
It looks like LWIP blocks all netconn and socket ops when TLS is using
it. Is that possible?
I am running with
#define LWIP_TCPIP_CORE_LOCKING 0
#define LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT 1
#define SYS_LIGHTWEIGHT_PROT 1
as this was found to have much better granularity for task switching.
With LWIP_TCPIP_CORE_LOCKING=1 you end up with a crude mutex across
the entire API call, which is fine in a single RTOS task.
Thank you in advance for any pointers.
Peter
Hi Team,
I have a requirement to generate self signed certificate programmatically.
I have raw EDCSA key pairs generated via OP-TEE APIs.
I m trying to generate self signed certificate. I tried the example as shown in programs/x509/cert_write.c. This doesn't work for me as I have raw key pairs where as this expects the key pairs to be in either pem/der format.
I tried the following code but it throws error "0xffffdd00" when I call mbedtls_x509write_crt_der
Code to set the raw key pairs:
mbedtls_ecdh_context issuer_ctx;
mbedtls_ecdh_init(&issuer_ctx);
ret = mbedtls_ecdh_setup(&issuer_ctx, MBEDTLS_ECP_DP_SECP384R1);
if (ret != 0) {
goto exit;
}
res = TA_ECSetPublicKey(&issuer_ctx, public_keyX, public_key_Y, 48);
if (res != TEE_SUCCESS)
{
goto exit;
}
res = TA_ECSetPrivateKey(&issuer_ctx, private_key, 48);
if (res != TEE_SUCCESS)
{
goto exit;
}
Am I doing something wrong ? Please help
It would be very helpful if some working example of generating certificate programmatically is shared for my reference
Thanks,
Prithvi
Hello,
In our project we use mbedTLS together with freeRTOS. mbedTLS requires an mbedtls_ssl_context (let's say `ssl_context`) for the send (`mbedtls_ssl_write(...)`) and receive (`mbedtls_ssl_read(...)`) functions. In our project we have a freeRTOS task `A` to send data with mbedTLS and a freeRTOS task `B`to receive data with mbedTLS over the same session/interface. Both tasks use the same `ssl_context` instance. Potentially sending and receiving can happen at the same time.
Is it safe to use the same `ssl_context` instance from both taks? Or should only one task access the `ssl_context`?
At the moment we are using `mbedtls_ssl_read(...)` in blocking mode and hence the `ssl_context` cannot be protected against multiple access with a mutex because then the sending task cannot obtain the mutex as long as the receiving task is the blocked receiving state (holding the mutext).
Thank you for your help.
Best regards,
Pascal
Hello,
We intend to remove DES (including Triple-DES) in the next major version
of Mbed TLS, i.e. Mbed TLS 4.0. We do not yet have a release date, but
at the moment it seems likely that there will be a new major version in
2024. As usual, the Mbed TLS 3.x series will keep the current support
for DES, and we intend to maintain the last 3.x minor release as a
long-term support branch for 3 years.
Rationale: Most security standards deprecate DES if they do not forbid
it already. Tooling is widely available to switch to AES or other
cipher. In particular, NIST will forbid Triple-DES except to decrypt
legacy data after 31 December 2023 (following SP 800-131A
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf>).
We would like to remove the last 64-bit block cipher from Mbed TLS to
simplify some parts of the code and reduce the maintenance burden.
If you wish for Mbed TLS to keep supporting DES longer, please let us
know what your business case is, either by replying to this email or on
the GitHub issue: https://github.com/Mbed-TLS/mbedtls/issues/7024
Best regards,
--
Gilles Peskine
Mbed TLS developer
Dear MbedTLS dev,
I am writing an opaque driver (equivalent of PSA_CRYPTO_TEST_DRIVER_LOCATION/PSA_KEY_PERSISTENCE_READ_ONLY in the test suite) with the PSA API compiled with MBEDTLS_PSA_CRYPTO_BUILTIN_KEYS.
But I am not sure if I have to use "psa_import_key" before "psa_driver_wrapper_sign_message" or if I have to "read/generate" the builtin key on the fly, at each psa_driver_wrapper_* operation ?
Would it be possible to add this example in the test suite ? Or explain how builtin key + opaque driver is supposed to be used with, for example, "psa_driver_wrapper_sign_message" ?
I put more details below.
Thank you in advance,
Best regards,
Rehan
#############################################################################
I would like to write an example doing :
I) psa_sign_message (ECDSA SECP256R1 SHA-256)
II) psa_export_public_key
III) psa_verify_message (with the public key from II)
I am following the examples provided by the test suite, especially :
1) sign_message transparent driver: calculate in driver ECDSA SECP256R1 SHA-256
using the API :
- psa_import_key
- psa_sign_message
with the attributes :
- key_type = PSA_KEY_TYPE_ECC_KEY_PAIR(PSA_ECC_FAMILY_SECP_R1)
2) PSA opaque driver builtin pubkey export: secp256r1
using the API :
- psa_export_public_key
with the attributes :
- key_id = MBEDTLS_PSA_KEY_ID_BUILTIN_MIN + 1
- key_type = PSA_KEY_TYPE_ECC_KEY_PAIR(PSA_ECC_FAMILY_SECP_R1)
and the driver code :
- platform_builtin_keys.c : mbedtls_psa_platform_get_builtin_key() (PSA_KEY_PERSISTENCE_READ_ONLY, PSA_CRYPTO_TEST_DRIVER_LOCATION)
- test_driver_key_management.c : mbedtls_test_opaque_export_public_key()
3) verify_message transparent driver: calculate in driver ECDSA SECP256R1 SHA-256
using the API :
- psa_import_key
- psa_verify_message
with the attributes :
- key_type = PSA_KEY_TYPE_ECC_KEY_PAIR(PSA_ECC_FAMILY_SECP_R1)
It seems to me that II)=2) and 3) should be pretty similar to III) because I assume that neither transparent vs opaque, nor PSA_KEY_TYPE_ECC_KEY_PAIR vs PSA_KEY_TYPE_ECC_PUBLIC_KEY_BASE, is gonna change much here.
But the signature I) is less clear... Has the built-in key feature been thought such that the read-only key is read each time we call a different PSA API function ?
Long story short, an "opaque driver + builtin keys" equivalent of the "sign_message transparent driver: calculate in driver ECDSA SECP256R1 SHA-256" example in the test-suite would be really helpful :)
Hello,
Is it possible to use PSA crypto APIs for SHA256 and RSA signature verification for RH850F1KMS1 microcontroller from renesas which has G3KH cpu core.
Let me know your thoughts.
Thank you in advance.
Regards,
Ujjwal
Hello,
I am writing this mail in order to get support.
I am using RH850-F1KMS1 microcontroller from Renesas, and I need to integrate mbed to perform SHA256 and RSA-1024 digital signature verification.
The controller is bare metal and does not have any OS like freeRTOS.
Just want to understand how to integrate mbed code in our project.
Thank you in advance for the help.
Regards,
Ujjwal