December 2022 - mbed-tls - lists.trustedfirmware.org

by Subramanian Gopi Krishnan

Hi, I have an inhouse developed secure authentication program that uses certificate for authentication. I have used mbedtls library for the x.509 certificate verification purpose. In our custom PKI we have only three level of certificates, Root-CA -> Intermediate-CA -> Device-Cert. The embedded device has very limited memory, so instead of sending whole certificate chain, the devices communicates intermediate_CA and device cert (in der format base64 encoded) in separate packet. Root-CA will be available on node as trusted-ca. Intermediate is verified against Root; then device cert is verified against intermediate. The problem is, the poc developed on linux platform is working fine - but on embedded platform I encounter either 0x3b00(parsing failed) or 0x2700(with flag 8). Also the error code are inconsistent. I verified the integrity of packet with certificate using crc16. So no chance of certificate getting corrupted. Also verified the certificate's base64 format integrity using crc16. All certificates are sha256WithRSAEncryption; RSA Public-Key: (4096 bit) Attached config.h on target platform for reference - could you help me if anything wrong with configuration. While trying to trace, the flag was set from x509_crt.c from below code. /* No parent? We're done here */ if( parent == NULL ) { printf("NO_PARENT\r\n"); *flags |= MBEDTLS_X509_BADCERT_NOT_TRUSTED; return( 0 ); } Any clue would be helpful. Thanks, Gopi Krishnan

7 months, 2 weeks

2
1
0 0

[Mbed-tls-announce] Coding style change in Mbed TLS

by Gilles Peskine via Mbed-tls-announce

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

1 year, 11 months

2
2
0 0

Canceled event: MBed TLS Technical Forum - Asia @ Mon Jan 2, 2023 3am - 3:50am (MST) (mbed-tls@lists.trustedfirmware.org)

by don.harbin＠linaro.org

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

2 years

1
0
0 0

Regarding implementation of MBED CRYPTO libraries without entropy source on baremetal

by PRASHANT TRIPATHI

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*

2 years

2
3
0 0

[Mbed-tls-announce] Mbed TLS 3.3.0 and Mbed TLS 2.28.2

by Dave Rodgman via Mbed-tls-announce

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

2 years

1
0
0 0

Reminder: MBed TLS Technical Forum - US/Europe

by Don Harbin

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

2 years

1
0
0 0

About setting arbitrary RDN while generating a CSR with mbedtls

by Aditya Patwardhan

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

2 years

2
1
0 0

MbedTLS crashes with some websites in mbedtls_mpi_free()

by Peter

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

2 years

3
9
0 0

2024

2023

2022

2021

2020

mbed-tls December 2022