Hello everyone,
We are currently using the mbedTLS version 2.16.12 in our firmware and we are planning an update to a newer branch. I would like to know, how long the different 3.x branches will be supported.
Is there any fix roadmap, how long an mbedTLS branch must be supported and maintained after its first release? I could only find this information for the 2.28 branch (support until end of 2024).
Thank you for any help you can offer.
Best regards
Maher Azarkan
Hilscher Gesellschaft f?r Systemautomation mbH
Rheinstra?e 15 / D-65795 Hattersheim / Germany
Sitz der Gesellschaft / place of business: Hattersheim | Gesch?ftsf?hrer / managing director: Sebastian Hilscher, Hans-J?rgen Hilscher
Handelsregister / commercial register: Frankfurt B 26873 | Ust. Idnr. / VAT No.: DE113852715 Registergericht / register court: Amtsgericht Frankfurt/Main
Important Information:
This e-mail message including its attachments contains confidential and legally protected information solely intended for the addressee. If you are not the intended addressee of this message, please contact the addresser immediately and delete this message including its attachments. The unauthorized dissemination, copying and change of this e-mail are strictly forbidden. The addresser shall not be liable for the content of such changed e-mails.
Wichtiger Hinweis:
Diese E-Mail einschlie?lich ihrer Anh?nge enth?lt vertrauliche und rechtlich gesch?tzte Informationen, die nur f?r den Adressaten bestimmt sind. Sollten Sie nicht der bezeichnete Adressat sein, so teilen Sie dies bitte dem Absender umgehend mit und l?schen Sie diese Nachricht und ihre Anh?nge. Die unbefugte Weitergabe, das Anfertigen von Kopien und jede Ver?nderung der E-Mail ist untersagt. Der Absender haftet nicht f?r Inhalte von ver?nderten E-Mails.
Dear all,
I need to migrate from OpenSSL to MbedTLS.
I have to implement a SCEP client in my embedded environment composed by FreeRTOS as OS, mbedTLS as security layer and LwIP as network stack.
The best candidate for the SCEP client role is the sscep library. It works very well under Ubuntu, but now I need to use it in my embedded environment, so I have to adapt sscep for MbedTLS.
I would like to know if there is some porting/migration guide from OpenSSL to MbedTLS.
Any kind of suggestion or support will be appreciated.
Thanks in advance.
Regards,
Matteo
Hi All,
A gentle reminder that the Asia-Europe timezone-friendly MBed TLS Tech
forum is next Monday at 10:00am 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
security issue in mbedtls 3.30 in the release notes:
"An adversary with access to precise enough information about memory
accesses (typically, an untrusted operating system attacking a secure
enclave) could recover an RSA private key after observing the victim
performing a single private-key operation if the window size used for the
exponentiation was 3 or smaller. Found and reported by Zili KOU,
Wenjian HE, Sharad Sinha, and Wei ZHANG. See "Cache Side-channel Attacks
and Defenses of the Sliding Window Algorithm in TEEs" - Design, Automation
and Test in Europe 2023."
was this issue solved in this version?
Hello,
I have 3rd party custom ECC library, that can do ECDSA verification and uses secp256r1 compressed public key (33bytes) to do so - all works fine.
Now I want to migrate to mbedTLS, to also benefit of other crypto schemes, hence use of mbedtls ECDSA was a natural way to go.
Here I need (as I understand) PEM parser or optionally public key in uncompressed format (0x04 | X | Y).
Problem is that loading of the key seems to work (func returns 0), but verification fails with -20450, indicating (if I well understood) invalid signature.
Test data.
PRIVATE KEY:
-----BEGIN PRIVATE KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgKNqyWso/lMuTlTE6
ll47Jboqq/Iz7OYDrr7TuXN+s2ChRANCAARNgfaUcxLoWWG01ekJFiqB8ujMgnHz
P320ZgiZErH6zKjlB9EovIHrchj0240+EIpFios+2uM609FgRvu3+NrT
-----END PRIVATE KEY-----
PUBLIC KEY:
-----BEGIN PUBLIC KEY-----
MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgADTYH2lHMS6FlhtNXpCRYqgfLozIJx
8z99tGYImRKx+sw=
-----END PUBLIC KEY-----
PUBLIC KEY UNCOMPRESSED SEC1:
0x4,0x4d,0x81,0xf6,0x94,0x73,0x12,0xe8,0x59,0x61,0xb4,0xd5,0xe9,0x9,0x16,0x2a,0x81,0xf2,0xe8,0xcc,0x82,0x71,0xf3,0x3f,0x7d,0xb4,0x66,0x8,0x99,0x12,0xb1,0xfa,0xcc,0xa8,0xe5,0x7,0xd1,0x28,0xbc,0x81,0xeb,0x72,0x18,0xf4,0xdb,0x8d,0x3e,0x10,0x8a,0x45,0x8a,0x8b,0x3e,0xda,0xe3,0x3a,0xd3,0xd1,0x60,0x46,0xfb,0xb7,0xf8,0xda,0xd3
PUBLIC KEY COMPRESSED SEC1:
0x3,0x4d,0x81,0xf6,0x94,0x73,0x12,0xe8,0x59,0x61,0xb4,0xd5,0xe9,0x9,0x16,0x2a,0x81,0xf2,0xe8,0xcc,0x82,0x71,0xf3,0x3f,0x7d,0xb4,0x66,0x8,0x99,0x12,0xb1,0xfa,0xcc
INPUT STRING in TEXT format:
"This is my input data" (remove quotes)
INPUT STRING in HEX format:
0x54,0x68,0x69,0x73,0x20,0x69,0x73,0x20,0x6d,0x79,0x20,0x69,0x6e,0x70,0x75,0x74,0x20,0x64,0x61,0x74,0x61
SHA256 of INPUT STRING:
0xa7,0x3f,0x26,0xf4,0xa1,0xe4,0x61,0x61,0x0,0x1a,0x29,0xdf,0xd2,0xaf,0x7d,0xa,0x25,0x91,0xbb,0xcc,0x1f,0xbc,0xfb,0xdb,0x43,0xdb,0x57,0xf9,0x8d,0x94,0xeb,0x81
(x-checked here: https://emn178.github.io/online-tools/sha256.html)
SIGNATURE of HASH signed with PRIVATE KEY:
0x80,0xe6,0xf5,0x97,0x6a,0x66,0xa2,0xe2,0x9a,0xd7,0x7f,0x9a,0x9b,0x3e,0x2b,0xde,0x1f,0x7c,0x3,0xb3,0x1,0xb8,0x6f,0xd8,0xf6,0xf,0x27,0x38,0x63,0x3,0x54,0x74,0x76,0x6d,0x1b,0x97,0xf0,0xbc,0xc5,0xd2,0x4b,0xae,0xf0,0x34,0xab,0x86,0xbd,0x55,0x0,0x8a,0x4c,0x9f,0x4e,0xa5,0x53,0x89,0xe8,0x0,0xb9,0x83,0x24,0x87,0x98,0x1
My custom library code looks like - this one works as expected:
if (ecdsa_verify(public_key_compressed_33_bytes_array, hash_of_input_string, signature_signed_with_private_key)) {
printf("Custom ECDSA lib verification is OK\r\n");
}
My mbedTLS code looks like:
```
/* mbedTLS */
printf("mbedTLS way start\r\n");
mbedtls_ecdsa_init(&ctx);
mbedtls_ecp_group_load(&ctx.private_grp, MBEDTLS_ECP_DP_SECP256R1);
res = mbedtls_ecp_point_read_binary(&ctx.private_grp, &ctx.private_Q, ecc_public_key_uncompressed_bin,
sizeof(ecc_public_key_uncompressed_bin));
if (res != 0) {
printf("ECP point read binary failed: %d\r\n", res);
}
res = mbedtls_ecdsa_read_signature(&ctx, data_raw_hash_digest, sizeof(data_raw_hash_digest), signature,
sizeof(signature));
if (res == 0) {
printf("mbedTLS Verification is OK...\r\n");
} else {
printf("mbedTLS Verification failed...: %d\r\n", res);
}
printf("mbedTLS way end\r\n");
```
and it always fails with error code -20450. while loading keys function goes through well.
Am I wrongly loading the keys?
Hi, I recently had to do some PKCS#7 signature validation and was
disappointed to find that it didn't just work. After digging through
RFCs to figure out the myriad of things I'd done wrong I was also left
with a lack of 3 features in mbedtls:
1. The full certificate chain was not being loaded and explicitly not
supported. I believe this is in error since the certificate was never
actually used anywhere, meaning it basically errored out for no reason.
Since this certificate chain also contains the key used to validate the
signature in my case that presented a pretty fundamental problem.
2. signedAttributes were not supported at all.
3. All the fields in mbedtls_pkcs7 and its associated structures are
marked as MBEDTLS_PRIVATE. I need to inspect both the certificates and
the signedAttributes and would rather not have to parse the entire DER
myself.
I have attached patches implementing the first two. I believe I've done
so without altering the behavior of the calls although I'm a bit unsure
as to why mbedtls_x509_crt_verify doesn't take a const mbedtls_x509_crt.
The third issue is a matter of policy and I don't know what your opinion
on it is. For the moment I can at least get away with poking at the
internal fields.
I have tested it on several signatures, one of which I have included
here and I apologize in advance for the absolute spew but I thought it
better than attaching even more files.
The data:
3059301306072A8648CE3D020106082A8648CE3D030107034200041B58AEE5B7C868AE0EED554133774B7C16802062EC2EB5A1A053318A9ED7DB943CE1F877671DADCFEB4D3171ACC2714ECBC0C0BCADE0569DF7CD0031623AF1BBDE72D8FFF60EC6D04B0D6C93658FC40F4AF2E22E1F68BF1A500FE00A94B804B7CA1DD7AF825C000FCF77A0ABB6918D2DF55C7A3CBC90BE14C59D8EE62A02B988DF7F32117770012AE362C03FB3AA3918AB9D10BE78442EFA7FCBA3CB02D6E196CE4137C6C3F280D963A5CD050EAC8871B3EB2C4500916FB3E39840D8EB198D58F49A434B2736385075BF9397405360B8694D0AD1E5DA8291F9EA47743F803F4A409EA72C2DF94F43DB60A0EAB8A8BD409C4D684200778B23D2A8126827995C3A80CAACA4AB7077266CED79BF91725330C9FCE3B8F1F5316C08C17B9994CF0ECB26D87A5C1F8FEB1FA737F78794895F6C5153B575EF8E95A8D433FD9486AA6C2B46ED6633D2BE0938202B99BEC21895018FB6FC59BAD662815A2C65200B8B1BAA4B69A8C89204B1EA70094026E9F710E599E14941476C8CD2E2879CF58E850DC732A506885F646BB9BE96B7A65355A6A9B907956E6DF65336504300CF062BA9DE50
It's SHA2-256 hash is:
C76DE7AF191C16E01405CE8FE89136EB60AC035B3DDE34ACF65220AC7C3CA619
If you decode the signature DER you'll see a matching id-messageDigest
in the signedAttributes towards the very bottom.
The signature in DER format:
3082089B06092A864886F70D010702A082088C30820888020101310D300B0609608648016503040201300B06092A864886F70D010701A08206D9308203E330820388A00302010202084C304149519D5436300A06082A8648CE3D040302307A312E302C06035504030C254170706C65204170706C69636174696F6E20496E746567726174696F6E204341202D20473331263024060355040B0C1D4170706C652043657274696669636174696F6E20417574686F7269747931133011060355040A0C0A4170706C6520496E632E310B3009060355040613025553301E170D3139303531383031333235375A170D3234303531363031333235375A305F3125302306035504030C1C6563632D736D702D62726F6B65722D7369676E5F5543342D50524F4431143012060355040B0C0B694F532053797374656D7331133011060355040A0C0A4170706C6520496E632E310B30090603550406130255533059301306072A8648CE3D020106082A8648CE3D03010703420004C21577EDEBD6C7B2218F68DD7090A1218DC7B0BD6F2C283D846095D94AF4A5411B83420ED811F3407E83331F1C54C3F7EB3220D6BAD5D4EFF49289893E7C0F13A38202113082020D300C0603551D130101FF04023000301F0603551D2304183016801423F249C44F93E4EF27E6C4F6286C3FA2BBFD2E4B304506082B0601
050507010104393037303506082B060105050730018629687474703A2F2F6F6373702E6170706C652E636F6D2F6F63737030342D6170706C65616963613330323082011D0603551D2004820114308201103082010C06092A864886F7636405013081FE3081C306082B060105050702023081B60C81B352656C69616E6365206F6E207468697320636572746966696361746520627920616E7920706172747920617373756D657320616363657074616E6365206F6620746865207468656E206170706C696361626C65207374616E64617264207465726D7320616E6420636F6E646974696F6E73206F66207573652C20636572746966696361746520706F6C69637920616E642063657274696669636174696F6E2070726163746963652073746174656D656E74732E303606082B06010505070201162A687474703A2F2F7777772E6170706C652E636F6D2F6365727469666963617465617574686F726974792F30340603551D1F042D302B3029A027A0258623687474703A2F2F63726C2E6170706C652E636F6D2F6170706C6561696361332E63726C301D0603551D0E041604149457DB6FD57481868989762F7E578507E79B5824300E0603551D0F0101FF040403020780300F06092A864886F76364061D04020500300A06082A8648CE3D0403020349003046022100BE09571FE71E1E7
35B55E5AFACB4C72FEB445F30185222C7251002B61EBD6F55022100D18B350A5DD6DD6EB1746035B11EB2CE87CFA3E6AF6CBD8380890DC82CDDAA63308202EE30820275A0030201020208496D2FBF3A98DA97300A06082A8648CE3D0403023067311B301906035504030C124170706C6520526F6F74204341202D20473331263024060355040B0C1D4170706C652043657274696669636174696F6E20417574686F7269747931133011060355040A0C0A4170706C6520496E632E310B3009060355040613025553301E170D3134303530363233343633305A170D3239303530363233343633305A307A312E302C06035504030C254170706C65204170706C69636174696F6E20496E746567726174696F6E204341202D20473331263024060355040B0C1D4170706C652043657274696669636174696F6E20417574686F7269747931133011060355040A0C0A4170706C6520496E632E310B30090603550406130255533059301306072A8648CE3D020106082A8648CE3D03010703420004F017118419D76485D51A5E25810776E880A2EFDE7BAE4DE08DFC4B93E13356D5665B35AE22D097760D224E7BBA08FD7617CE88CB76BB6670BEC8E82984FF5445A381F73081F4304606082B06010505070101043A3038303606082B06010505073001862A687474703A2F2F6F6373702E6170706C
652E636F6D2F6F63737030342D6170706C65726F6F7463616733301D0603551D0E0416041423F249C44F93E4EF27E6C4F6286C3FA2BBFD2E4B300F0603551D130101FF040530030101FF301F0603551D23041830168014BBB0DEA15833889AA48A99DEBEBDEBAFDACB24AB30370603551D1F0430302E302CA02AA0288626687474703A2F2F63726C2E6170706C652E636F6D2F6170706C65726F6F74636167332E63726C300E0603551D0F0101FF0404030201063010060A2A864886F7636406020E04020500300A06082A8648CE3D040302036700306402303ACF7283511699B186FB35C356CA62BFF417EDD90F754DA28EBEF19C815E42B789F898F79B599F98D5410D8F9DE9C2FE0230322DD54421B0A305776C5DF3383B9067FD177C2C216D964FC6726982126F54F87A7D1B99CB9B0989216106990F09921D3182018830820184020101308186307A312E302C06035504030C254170706C65204170706C69636174696F6E20496E746567726174696F6E204341202D20473331263024060355040B0C1D4170706C652043657274696669636174696F6E20417574686F7269747931133011060355040A0C0A4170706C6520496E632E310B300906035504061302555302084C304149519D5436300B0609608648016503040201A08193301806092A864886F70D010903310B06092A864
886F70D010701301C06092A864886F70D010905310F170D3233303230393231333032345A302806092A864886F70D010934311B3019300B0609608648016503040201A10A06082A8648CE3D040302302F06092A864886F70D01090431220420C76DE7AF191C16E01405CE8FE89136EB60AC035B3DDE34ACF65220AC7C3CA619300A06082A8648CE3D04030204473045022100EE9B221CD9B5EEB1C6AF4160128D099C9414440A96C855A789846599E3BDE442022005AE51DC947E0B2AA6593E8FDB9F888782C71E5BB1CB6BF3C32B79C448C6A75D
Joakim
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
