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
Hi All,
A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum
is next Monday at 4:30 PM UK time. Invite details can be found on the
online calendar here <https://www.trustedfirmware.org/meetings/>.
If you have any topics, please let Dave Rodgman know. :)
Dave,
Please keep in mind that next Monday is a Federal Holiday in the US, so
this may impact attendance.
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hello,
You are concerned if: you contribute to Mbed TLS, or you maintain local patches to Mbed TLS.
You are not concerned if: you just use Mbed TLS.
We are going to change the C coding style in Mbed TLS. The new style is mostly what you'd find in The C Programming Language, 2nd edition, by Brian Kernighan and Dennis Ritchie (K&R2). The main changes compared to the current style are:
* Spaces outside parentheses, not inside. No space in f(x).
* Opening braces on the same line as if(), for(), etc., but on a separate line for functions.
Indentation remains 4 spaces. The recommended maximum line length remains 80 columns. There are a few deviations from K&R2, documentation will be available shortly.
The new code style will be enforced by the CI testing. This means that style that's rejected by the tool will not be merged, full stop. This also means that sometimes we'll have code that looks a bit less good to humans because the tool insists on it. We're doing this to avoid wasting reviewers' and contributors' time with style violations in code review.
The tool we're using is uncrustify<https://github.com/uncrustify/uncrustify>. You can see how your code will look like by installing uncrustify 0.75.1 and running scripts/code_style.py from mbedtls-3.3.0 or mbedtls-2.28.2. There are previews of the rewritten branches at https://github.com/Mbed-TLS/mbedtls/tree/features/new-code-style/development and https://github.com/Mbed-TLS/mbedtls/tree/features/new-code-style/mbedtls-2.… (updated every few days until the real branches are rewritten). If you're now starting work on a new feature or bugfix, it will probably be easier to start from those branches, and do an easy rebase once they become official.
If you've been working on a branch, we will provide a script to rebase the branch and rewrite it to the new style commit by commit. You'll need to have uncrustify 0.75.1.
Concretely, when we change the code style:
* If you've started to work on a branch but review has not started yet, we'll ask you to adapt your branch to the new code style.
* If your work is under review, you'll need to adapt your branch to the new code style before it can be merged. Rebasing a branch is disruptive for reviews, so please synchronize with the reviewers to decide on a good time.
We plan to do the switch during the first week of January 2023.
Best regards,
--
Gilles Peskine
Mbed TLS developer
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
--
Mbed-tls-announce mailing list -- mbed-tls-announce(a)lists.trustedfirmware.org
To unsubscribe send an email to mbed-tls-announce-leave(a)lists.trustedfirmware.org
Hi All,
I raised the issue below in the MBED-TLS github, as per suggestion from the moderator asking it in the mailing-list. Below are the details.
https://github.com/Mbed-TLS/mbedtls/issues/6864
I am running Mbed TLS as a core security library(2.24.0), on an embedded platform.
I am using the FreeRADIUS server for AAA authentication.
I am able to get the PMK values correctly at the supplicant side, however while decrypting the MPPE key at the gateway side I see that the values are incorrect specially in the API(radius_client_sec_prot_ms_mppe_recv_key_pmk_decrypt)
Below are my setup details:
FreeRADIUS server setup on Ubuntu(3.2.1)
openssl :1.1.1f
Ubuntu version : 20.04.04LTS
System information
Client side setup
Platform : Micro controller based platform
OS : FreeRTOS
Compiler gcc-arm-none-eabi-8-2019-q3-update
Sample example
MPPE KEY in clear at RADIUS Server
Fri Dec 30 23:50:13 2022 : Debug: (209) MS-MPPE-Recv-Key = 0x2f6c3e7e748eb49a598c208af3ef520454f5aa6873bc72f7f32be1053914a566
Fri Dec 30 23:50:13 2022 : Debug: (209) MS-MPPE-Send-Key = 0xa04539819a272e94782af1818b05878bb0e420d08a51accd6c3cb75baaecbd75
PMK Key values at Supplicant(which is same as MPPE-RECV-KEY)
PMK Key values at Supplicant(which is same as MPPE-RECV-KEY)
2022-12-30 23:50:07.313 #1 0000000000000000 <log> 0:28:21.215 [debug] [ tlsp] {Wi-SUN Ev}: >>>> PRINT THE KEY PMK >>>>
2022-12-30 23:50:07.313 #1 0000000000000000 <log> 0:28:21.224 [debug] [ tlsp] {Wi-SUN Ev}: EAP-TLS key material 2f:6c:3e:7e:74:8e:b4:9a:59:8c:20:8a:f3:ef:52:04:54:f5:aa:68:73:bc:72:f7:f3:2b:e1:05:39:14:a5:66
which is same as the value that we see at the RADIUS Server.
Decrypted key Value at Authenticator(using the API radius_client_sec_prot_ms_mppe_recv_key_pmk_decrypt)
2022-12-30 23:51:34.763 #1 0000000000000000 <log> 3:09:17.919 [debug] [ hmac] {Wi-SUN Ev}: hmac_md key a9:69:02:e9:3a:1d:cd:05:31:b3:77:cd:d6:d7:c2:c7:2d:52:4b:0a:5b:b1:aa:81:20:67:dd:b8:1c:04:ef:63
Mbed TLS version (number or commit id): 2.24.0
Operating system and version:
Configuration (if not default, please attach mbedtls_config.h):
Compiler and options (if you used a pre-built binary, please indicate how you obtained it):
Additional environment information:
Expected behavior
The key should be decrypted with the correct value.
Actual behavior
The key is not getting the correct value.
Steps to reproduce
Additional information
Kindly let me know what is missing here ?
Thanks in advance.
With regards,
Ajay.
Brentwood, UK.
With mbedTLS set up as a streaming server (e.g. https), can it deal
with two attempts to connect that arrive in quick succession, so two
handshakes are occurring simultaneously?
David
I have a working Client code in which I use MbedTLS functions to send HTTPS GET request to my server. For sending data to the server, I use mbedtls_ssl_write(). But this call is blocking.
My goal is to make this function call (mbedtls_ssl_write()) non-blocking. What is the correct way to do it ?
I read the documentation and concluded that:
1. I have to set the bio callbacks using the mbedtls_ssl_set_bio() function where I have to pass the callback functions as parameters in this function call.
2. I have to set the SSL context as non-blocking using the mbedtls_net_set_nonblock() function call
3. I have used the default bio callbacks, named mbedtls_net_send and mbedtls_net_recv, which are defined in net_sockets.c
My question is:
After setting the default bio callbacks (mbedtls_net_send and mbedtls_net_recv) and setting the SSL context as non-blocking (mbedtls_net_set_nonblock) which function should I use for non-blocking write/read. Will it be mbedtls_ssl_write() and mbedtls_ssl_read() ? And will the call back functions (which are set using mbedtls_ssl_set_bio) be called when read/write completes?
Please help me with advice on how to implement non-blocking write/read using MbedTLS functions.
Thanks and Regards,
Sritam Paltasingh.
Hi,
PSA driver interface specification talks about "add_entropy" entry point.
Snippet pasted below.
https://github.com/Mbed-TLS/mbedtls/blob/development/docs/proposed/psa-driv…
*A driver can declare an entropy source by providing a "get_entropy" entry
point. This entry point has the following prototype for a driver with the
prefix "acme":*
*psa_status_t acme_get_entropy(uint32_t flags,
size_t *estimate_bits,
uint8_t *output,
size_t output_size);*
However, in the current implementation of MbedTLS 3.x I don't see
this implemented . With the psa_crypto-init() what I observe is that if the
platform enables MBEDTLS_ENTROPY_HARDWARE_ALT then using "
mbedtls_hardware_poll(),
the entropy source can be provided.
Can you please confirm if this observation is correct and also let us know
if the <driver>_get_entropy() is planned to be implemented in near future ?
Regards,
Ruchika
This event has been canceled.
MBed TLS Technical Forum - Asia
Monday Jan 2, 2023 ⋅ 3am – 3:50am
Mountain Standard Time - Phoenix
Trusted Firmware is inviting you to a scheduled Zoom meeting.
Topic: MBed TLS Technical Forum - Asia
Time: Nov 8, 2021 10:00 AM London
Every 4 weeks on Mon, 20 occurrence(s)
Nov 8, 2021 10:00 AM
Dec 6, 2021 10:00 AM
Jan 3, 2022 10:00 AM
Jan 31, 2022 10:00 AM
Feb 28, 2022 10:00 AM
Mar 28, 2022 10:00 AM
Apr 25, 2022 10:00 AM
May 23, 2022 10:00 AM
Jun 20, 2022 10:00 AM
Jul 18, 2022 10:00 AM
Aug 15, 2022 10:00 AM
Sep 12, 2022 10:00 AM
Oct 10, 2022 10:00 AM
Nov 7, 2022 10:00 AM
Dec 5, 2022 10:00 AM
Jan 2, 2023 10:00 AM
Jan 30, 2023 10:00 AM
Feb 27, 2023 10:00 AM
Mar 27, 2023 10:00 AM
Apr 24, 2023 10:00 AM
Please download and import the following iCalendar (.ics) files to your
calendar system.
Weekly:
https://linaro-org.zoom.us/meeting/tJ0kc-GsqDktHNGa8CWl6wJ7je6CKD-5zgh8/ics…
Join Zoom Meeting
https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT…
Meeting ID: 999 4846 2765
Passcode: 196117
One tap mobile
+12532158782,,99948462765# US (Tacoma)
+13462487799,,99948462765# US (Houston)
Dial by your location
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
+1 669 900 9128 US (San Jose)
+1 301 715 8592 US (Washington DC)
+1 312 626 6799 US (Chicago)
+1 646 558 8656 US (New York)
888 788 0099 US Toll-free
877 853 5247 US Toll-free
Meeting ID: 999 4846 2765
Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt
Guests
Don Harbin - creator
nnac123(a)gmail.com
santosdanillo(a)gmail.com
schoenle.thomas(a)googlemail.com
kris.kwiatkowski(a)pqshield.com
psa-crypto(a)lists.trustedfirmware.org
mbed-tls(a)lists.trustedfirmware.org
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Dear sir/madam
I have following queries regarding implementation of MBED CRYPTO Libraries :
1) How crypto libraries files could be used on baremetal with no entropy
source(cross compilation )?
2) How asymmetric cryptographic operations like RSA , RNG , EC ,DSA etc ,
could be implemented on baremetal without entropy , seed provisions ?
3) If i want to use some custom PRNG and entropy , then how the respective
contexts structures could be filled ?
Thanks & Regards,
*Prashant Tripathi*
Hi Mbed TLS users,
We are pleased to announce the release of Mbed TLS versions 3.3.0 and 2.28.2.
These releases of Mbed TLS address several security issues, provide bug fixes, and bring other minor changes. Full details are available in the release notes (https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-3.3.0 and https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.28.2 ).
We recommend all users to consider whether they are impacted, and to upgrade appropriately.
The releases are available from
https://github.com/Mbed-TLS/mbedtls/releases
Dave Rodgman
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
--
Mbed-tls-announce mailing list -- mbed-tls-announce(a)lists.trustedfirmware.org
To unsubscribe send an email to mbed-tls-announce-leave(a)lists.trustedfirmware.org
Hi All,
A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum
is next Monday at 4:30 PM UK time. Invite details can be found on the
online calendar here <https://www.trustedfirmware.org/meetings/>.
If you have any topics, please let Dave Rodgman know. :)
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
I am using mbedtls_x509write_csr_set_subject_name API from mbedtls to set the subject name.
I wanted to set the arbitrary old value in my certificate for e.g.
ffeBgt9jDHhBwPDANgtT7R/1.3.6.1.4.1.37244.2.1=FFF2/1.3.6.1.4.1.37244.2.2=8001
In this case ffeBgt9jDHhBwPDANgtT7R is the CN
And 1.3.6.1.4.1.37244.2.1 is an arbitrary OID which has a value of FFF2 similar to the second arbitrary OID.
I am able to do this through openssl commands, but while doing it through mbedtls, when I pass it as a string then mbedtls considers the whole string as CN which Is not my intention.
Please fine the asn1 parsing of the CSR as below
CSR generated through mbedtls:
18:d=5 hl=2 l= 3 prim: OBJECT :commonName
23:d=5 hl=2 l= 76 prim: UTF8STRING :ffeBgt9jDHhBwPDANgtT7R/1.3.7.1.4.1.37466.2.1=FFF2+1.3.7.1.4.1.37466.2.2=8001
101:d=3 hl=2 l= 11 cons: SET
103:d=4 hl=2 l= 9 cons: SEQUENCE
Target CSR ( done thorough openssl):
14:d=4 hl=2 l= 29 cons: SEQUENCE
16:d=5 hl=2 l= 3 prim: OBJECT :commonName
21:d=5 hl=2 l= 22 prim: UTF8STRING :ffeBgt9jDHhBwPDANgtT7R
45:d=3 hl=2 l= 20 cons: SET
47:d=4 hl=2 l= 18 cons: SEQUENCE
49:d=5 hl=2 l= 10 prim: OBJECT :1.3.7.1.4.1.37466.2.1
61:d=5 hl=2 l= 4 prim: UTF8STRING :FFF2
67:d=3 hl=2 l= 20 cons: SET
69:d=4 hl=2 l= 18 cons: SEQUENCE
71:d=5 hl=2 l= 10 prim: OBJECT :1.3.7.1.4.1.37466.2.2
83:d=5 hl=2 l= 4 prim: UTF8STRING :8001
89:d=2 hl=2 l= 89 cons: SEQUENCE
91:d=3 hl=2 l= 19 cons: SEQUENCE
93:d=4 hl=2 l= 7 prim: OBJECT :id-ecPublicKey
102:d=4 hl=2 l= 8 prim: OBJECT :prime256v1
Am I missing something here? Do I need to provide the CN in a different way to get the intended result?
I found an open issue https://github.com/Mbed-TLS/mbedtls/issues/4886, could it be related to this?
Any help would be appreciated.
Thanks and Regards,
Aditya
Hi All,
Some websites crash MbedTLS, in
void mbedtls_ecp_point_free( mbedtls_ecp_point *pt )
{
if( pt == NULL )
return;
mbedtls_mpi_free( &( pt->X ) );
mbedtls_mpi_free( &( pt->Y ) );
mbedtls_mpi_free( &( pt->Z ) );
}
It crashes in the last function call of the three above.
Thread #1 [main] 1 [core: 0] (Suspended : Signal :
SIGTRAP:Trace/breakpoint trap)
HardFault_Handler() at stm32f4xx_it.c:103 0x8053c22
<signal handler called>() at 0xffffffed
0x3810180
mbedtls_ecp_point_free() at ecp.c:594 0x8029c7a
0x81030100
It crashes properly i.e. invalid opcodes etc.
There is a fair bit on google with others having gone down the same
road, never resolved.
One site which does it is socata.org but quite a few others do it.
Probably 10% of "major name" websites cause it to crash.
It may have been undiscovered for a long time, or ever, because most
MbedTLS clients are connecting to specific private servers only.
People aren't using it to connect to microsoft.com (which doesn't
actually crash but the handshake returns 0x2700 which can be
investigated).
There is a Windows build of MbedTLS (v2.16.2) which seems to work in
the crashing cases. Stepping through this in Cube IDE (32F417) it
looks like the crash is due to a buffer being filled with random
numbers. The guy working on this is contactable only on Monday
afternoons so I am a bit screwed :) He said he found something about
that buffer, or maybe a corrupted function pointer.
But as I said this issue has come up before according to numerous
online searches and maybe someone can recognise it.
Hardware AES is enabled but this occurs with software AES also. No
other 32F417 hardware crypto features are used, other than its random
number generator.
TLS is v2.16.2.
Thank you in advance for any pointers.
Peter
Hi All,
A gentle reminder that the Asia-Europe timezone-friendly MBed TLS Tech
forum is next *Monday, Dec 5 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 All,
Mbed TLS is planning to move to a new code style by the end of this year. The proposed new style is currently being discussed in the GitHub pull request:
https://github.com/Mbed-TLS/mbedtls/pull/6591
If you have any feedback on this new style, or you think we should tweak it, feel free to comment on the pull request. We will take your thoughts into account when we decide on the final style.
Discussions will continue until the evening of THIS FRIDAY (UK time).
Many thanks,
David Horstmann for the Mbed TLS Team
Hi All,
A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum
is next Monday at 4:30 PM UK time. Invite details can be found on the
online calendar here <https://www.trustedfirmware.org/meetings/>.
If you have any topics, please let Dave Rodgman know. :)
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org