- mbed-tls - lists.trustedfirmware.org

by Xavier Del Campo Romero

I want to connect an ESP32 to a DTLS server using mbedtls' dtls_server demo. The code I used for the client is very similar to the dtls_client example, but is unable to finish the handshake process for some reason. According to Wireshark, the client is not responding to the "Server hello done" frame, causing a timeout that makes the server to send the certificate again and again until it gives up the connection. The dtls_client demo works correctly on the computer, but not on the ESP32. Has anyone tested DTLS on the ESP32? I have attached the following files for further reference: - dtls_esp32.pcapng: Wireshark file with the DTLS packets between client and server. - mbedtls.tar.bz2: compressed (> 7k lines) plain text log as reported by the board. On line 7131, where the last message from the server is received, it looks like the client never receives the whole message, so it never reaches the "Server hello done" state. Could anyone please confirm this? - dtls.c: client source code. Slightly modified from the dtls_client example. Thank you very much for your help. Xavi

6 years, 2 months

1
0
0 0

Re: [mbed-tls] Feedback sought on a new PSA Crypto driver interface

by Quach, Brian

Hi, I was reviewing the proposal and had a few questions on usage of the new params. 1) When using plaintext keys, is the "attributes" param unused and should/could it be set to NULL? 2) If using key store (i.e. opaque), is the key ID the only attribute field which needs to be set? My assumption is attributes would be populated from the key store using the key ID? 3) If using key store, are the "key_buffer" and "key_buffer_size" params typically unused (i.e. can be set to null and zero respectively)? I do the proposal says the buffer content is up to the driver. Are there any usage cases in mind? 4) For drivers that support both opaque and transparent operation, which param would be used to determine the mode? (I had assumed key ID = 0 would be transparent, and non-zero is opaque) I'm unclear how persistent_state for opaque driver's is used. Could you elaborate on how it's used by the driver and core and why it isn't needed for transparent drivers? Key management with opaque drivers Transparent drivers may provide the following key management functions: Should this be "Opaque"? Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

6 years, 2 months

1
0
0 0

Re: [mbed-tls] mbedtls_x509write_crt_set_subject_name, mbedtls_x509_dn_gets fail to handle UTF8 multibyte properly

by Martin Man

> On 11 Jun 2020, at 12:09, Gilles Peskine via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> wrote: > > On 11/06/2020 11:24, Martin Man via mbed-tls wrote: >> >> I think this is a bug and the dn_gets should simply leave the UTF-8 >> multibyte untouched when parsing it out from a field tagged with ASN.1 >> tag 12 (utf-8). > > We are not going to do Unicode normalization in Mbed TLS: that would be > far too complex for a library that runs on systems with ~1e5 bytes > available for code. So Unicode strings would only be processed correctly > if the application passes normalized strings and CAs only generate > certificates with normalized strings. But that would be an improvement > on converting non-ASCII characters to '?'. Definitely agree that normalization is not needed. I think this problem could be split into two parts: 1) When a const char* is passed into mbedtls_x509write_crt_set_subject_name, the mbedtls will currently encode it into ASN tag 12 UTF8. Not sure what validation is done. But it could perhaps do at least a basic validation of what the C string passed in is to avoid generating a cert with crippled DN. Alternatively you can simply trust the developer to pass in correct UTF8 and document this. This is a API design decision of what input is allowed to be passed into the method and what validation is done on this. 2) When the mbedtls_x509_dn_gets extracts a C string from the ASN.1 tagged as 12, it could validate that it is indeed valid UTF-8, or just leave it as is and push it out. Again, this is about what we expect the library to do. I’m not an expert on whether this can in any way be used to trick MBEDLTS to do bad things when sending in a malformed certificate, say a one where DN is encoded as UTF-8 but contains illegal UTF-8 in the payload. thanks for listening, Martin

6 years, 2 months

1
0
0 0

Re: [mbed-tls] mbedtls_x509write_crt_set_subject_name, mbedtls_x509_dn_gets fail to handle UTF8 multibyte properly

by Gilles Peskine

On 11/06/2020 11:24, Martin Man via mbed-tls wrote: > The code in mbedtls_x509_dn_gets fails to properly handle the UTF-8 > multibyte sequence 0xe2 0x80 0x99 and turns it into 0xe2 0x80 0x3f. > > There is a fix floating around development branch mentioned > here https://github.com/ARMmbed/mbedtls/pull/3326/files which > essentially replaces all control chars with question marks. > > I think this is a bug and the dn_gets should simply leave the UTF-8 > multibyte untouched when parsing it out from a field tagged with ASN.1 > tag 12 (utf-8). That code is from an earlier era (mid 2000s, I think) when most systems used an 8-bit encoding, but non-8-bit-clean systems were still common. A '\x80' in text might be transformed to '\x00' with disastrous consequences. But over a decade later, I don't think non-8-bit-clean systems are a concern anymore. Leaving all non-ASCII characters alone sounds reasonable to me. We are not going to do Unicode normalization in Mbed TLS: that would be far too complex for a library that runs on systems with ~1e5 bytes available for code. So Unicode strings would only be processed correctly if the application passes normalized strings and CAs only generate certificates with normalized strings. But that would be an improvement on converting non-ASCII characters to '?'. -- Gilles Peskine Mbed TLS developer

6 years, 2 months

1
0
0 0

mbedtls_x509write_crt_set_subject_name, mbedtls_x509_dn_gets fail to handle UTF8 multibyte properly

by Martin Man

Hi guys, I’m new to the list and bringing the discussion over here from https://github.com/ARMmbed/mbedtls/issues/3413 <https://github.com/ARMmbed/mbedtls/issues/3413>. I’m creating a certificate using mbedtls and setting it’s issuer and and subject using the mbedtls_x509write_crt_set_subject_name, and mbedtls_x509write_crt_set_issuer_name. The name passed in is in UTF8 and contains a sequence 0xe2 0x80 0x99 (apostrophe) in the CN string. If I debugged this correctly, the underlying sequence of bytes is correctly encoded in ASN.1 and tagged as 12 (UTF-8). When I later parse the cert and try to extract its subject back using mbedtls_x509_dn_gets from crt.subject and crt.issuer the UTF-8 gets corrupted. The code in mbedtls_x509_dn_gets fails to properly handle the UTF-8 multibyte sequence 0xe2 0x80 0x99 and turns it into 0xe2 0x80 0x3f. There is a fix floating around development branch mentioned here https://github.com/ARMmbed/mbedtls/pull/3326/files <https://github.com/ARMmbed/mbedtls/pull/3326/files> which essentially replaces all control chars with question marks. I think this is a bug and the dn_gets should simply leave the UTF-8 multibyte untouched when parsing it out from a field tagged with ASN.1 tag 12 (utf-8). What’s your opinion? Martin

6 years, 2 months

1
0
0 0

ERROR: mbedtls_ssl_handshake returned -0x50 (with AWS IOT SDK )

by Srinivasa Rao Ragolu

Hi All, I recently started working on mbedtls for AWS IoT SDK based applications. Issue: I am planning to run AWS IoT SDK sample applications on my memory constrained (6MB RAM) embedded hardware Usage: AWS IOT SDK(3.0.1 release version) and mbedtls (2.16.5) Note: This filesystem is Read-Only file system. I have tried on Ubuntu 18.04 setup first to make things clear. It was not working with "AmazonRootCA1.pem" and working perfectly fine with cross-signed "G2-RootCA1.pem". Ref: https://docs.aws.amazon.com/iot/latest/developerguide/iot-embedded-c-sdk.ht… So I have cross-compiled for my target board using ARM toolchain and copied the binary and certificates. I have downloaded device certificate, private key and RootCA from AWS IOT Core to my device. Nothing on my device except copying the above 3 files. On my Embedded platform, whenever run my application, mbedtls is throwing the error "mbedtls_ssl_handshake returned -0x50" So I have enabled the debug in mbedtls library and ran below command to dig into the problem. $ ./ssl_client2 server_name=a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com<http://a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com/> serv er_port=443 ca_file=/certs/G2-RootCA1.pem crt_file=/certs/4960bd2f6b-certificate .pem.crt key_file=/certs/4960bd2f6b-private.pem.key Output: $ ./ssl_client2 server_name=a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com<http://a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com/> serv er_port=443 ca_file=/certs/G2-RootCA1.pem crt_file=/certs/4960bd2f6b-certificate .pem.crt key_file=/certs/4960bd2f6b-private.pem.key . Seeding the random number generator... ok . Loading the CA root certificate ... ok (0 skipped) . Loading the client cert. and key... ok . Connecting to tcp/a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com/443.<http://a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com/443.>.. ok . Setting up the SSL/TLS structure...ssl_tls.c:0081: |3| set_timer to 0 ms ok . Performing the SSL/TLS handshake...ssl_tls.c:8084: |2| => handshake ssl_cli.c:3510: |2| client state: 0 ssl_tls.c:2755: |2| => flush output ssl_tls.c:2767: |2| <= flush output ssl_cli.c:3510: |2| client state: 1 ssl_tls.c:2755: |2| => flush output ssl_tls.c:2767: |2| <= flush output ssl_cli.c:0774: |2| => write client hello ssl_cli.c:0811: |3| client hello, max version: [3:3] ssl_cli.c:0703: |3| client hello, current time: 1540981791 ssl_cli.c:0821: |3| dumping 'client hello, random bytes' (32 bytes) ssl_cli.c:0821: |3| 0000: 5b d9 84 1f 2f 33 35 54 ea 0b 5d e1 dc 42 0c 99 [.../35T..]..B.. ssl_cli.c:0821: |3| 0010: d4 a1 25 72 6f 0f cf 8e 56 0d ab f5 10 e4 47 46 ..%ro...V.....GF ssl_cli.c:0874: |3| client hello, session id len.: 0 ssl_cli.c:0875: |3| dumping 'client hello, session id' (0 bytes) ssl_cli.c:0921: |3| client hello, add ciphersuite: cca8 ssl_cli.c:0921: |3| client hello, add ciphersuite: cca9 ssl_cli.c:0921: |3| client hello, add ciphersuite: ccaa ssl_cli.c:0921: |3| client hello, add ciphersuite: c02c ssl_cli.c:0921: |3| client hello, add ciphersuite: c030 ssl_cli.c:0921: |3| client hello, add ciphersuite: 009f ssl_cli.c:0921: |3| client hello, add ciphersuite: c0ad ssl_cli.c:0921: |3| client hello, add ciphersuite: c09f ssl_cli.c:0921: |3| client hello, add ciphersuite: c024 ssl_cli.c:0921: |3| client hello, add ciphersuite: c028 ssl_cli.c:0921: |3| client hello, add ciphersuite: 006b ssl_cli.c:0921: |3| client hello, add ciphersuite: c00a ssl_cli.c:0921: |3| client hello, add ciphersuite: c014 ssl_cli.c:0921: |3| client hello, add ciphersuite: 0039 ssl_cli.c:0921: |3| client hello, add ciphersuite: c0af ssl_cli.c:0921: |3| client hello, add ciphersuite: c0a3 ssl_cli.c:0921: |3| client hello, add ciphersuite: c087 ssl_cli.c:0921: |3| client hello, add ciphersuite: c08b ssl_cli.c:0921: |3| client hello, add ciphersuite: c07d ssl_cli.c:0921: |3| client hello, add ciphersuite: c073 ssl_cli.c:0921: |3| client hello, add ciphersuite: c077 ssl_cli.c:0921: |3| client hello, add ciphersuite: 00c4 ssl_cli.c:0921: |3| client hello, add ciphersuite: 0088 ssl_cli.c:0921: |3| client hello, add ciphersuite: c02b ssl_cli.c:0921: |3| client hello, add ciphersuite: c02f ssl_cli.c:0921: |3| client hello, add ciphersuite: 009e ssl_cli.c:0921: |3| client hello, add ciphersuite: c0ac ssl_cli.c:0921: |3| client hello, add ciphersuite: c09e ssl_cli.c:0921: |3| client hello, add ciphersuite: c023 ssl_cli.c:0921: |3| client hello, add ciphersuite: c027 ssl_cli.c:0921: |3| client hello, add ciphersuite: 0067 ssl_cli.c:0921: |3| client hello, add ciphersuite: c009 ssl_cli.c:0921: |3| client hello, add ciphersuite: c013 ssl_cli.c:0921: |3| client hello, add ciphersuite: 0033 ssl_cli.c:0921: |3| client hello, add ciphersuite: c0ae ssl_cli.c:0921: |3| client hello, add ciphersuite: c0a2 ssl_cli.c:0921: |3| client hello, add ciphersuite: c086 ssl_cli.c:0921: |3| client hello, add ciphersuite: c08a ssl_cli.c:0921: |3| client hello, add ciphersuite: c07c ssl_cli.c:0921: |3| client hello, add ciphersuite: c072 ssl_cli.c:0921: |3| client hello, add ciphersuite: c076 ssl_cli.c:0921: |3| client hello, add ciphersuite: 00be ssl_cli.c:0921: |3| client hello, add ciphersuite: 0045 ssl_cli.c:0921: |3| client hello, add ciphersuite: ccac ssl_cli.c:0921: |3| client hello, add ciphersuite: ccad ssl_cli.c:0921: |3| client hello, add ciphersuite: 00ab ssl_cli.c:0921: |3| client hello, add ciphersuite: c0a7 ssl_cli.c:0921: |3| client hello, add ciphersuite: c038 ssl_cli.c:0921: |3| client hello, add ciphersuite: 00b3 ssl_cli.c:0921: |3| client hello, add ciphersuite: c036 ssl_cli.c:0921: |3| client hello, add ciphersuite: 0091 ssl_cli.c:0921: |3| client hello, add ciphersuite: c091 ssl_cli.c:0921: |3| client hello, add ciphersuite: c09b ssl_cli.c:0921: |3| client hello, add ciphersuite: c097 ssl_cli.c:0921: |3| client hello, add ciphersuite: c0ab ssl_cli.c:0921: |3| client hello, add ciphersuite: 00aa ssl_cli.c:0921: |3| client hello, add ciphersuite: c0a6 ssl_cli.c:0921: |3| client hello, add ciphersuite: c037 ssl_cli.c:0921: |3| client hello, add ciphersuite: 00b2 ssl_cli.c:0921: |3| client hello, add ciphersuite: c035 ssl_cli.c:0921: |3| client hello, add ciphersuite: 0090 ssl_cli.c:0921: |3| client hello, add ciphersuite: c090 ssl_cli.c:0921: |3| client hello, add ciphersuite: c096 ssl_cli.c:0921: |3| client hello, add ciphersuite: c09a ssl_cli.c:0921: |3| client hello, add ciphersuite: c0aa ssl_cli.c:0921: |3| client hello, add ciphersuite: 009d ssl_cli.c:0921: |3| client hello, add ciphersuite: c09d ssl_cli.c:0921: |3| client hello, add ciphersuite: 003d ssl_cli.c:0921: |3| client hello, add ciphersuite: 0035 ssl_cli.c:0921: |3| client hello, add ciphersuite: c032 ssl_cli.c:0921: |3| client hello, add ciphersuite: c02a ssl_cli.c:0921: |3| client hello, add ciphersuite: c00f ssl_cli.c:0921: |3| client hello, add ciphersuite: c02e ssl_cli.c:0921: |3| client hello, add ciphersuite: c026 ssl_cli.c:0921: |3| client hello, add ciphersuite: c005 ssl_cli.c:0921: |3| client hello, add ciphersuite: c0a1 ssl_cli.c:0921: |3| client hello, add ciphersuite: c07b ssl_cli.c:0921: |3| client hello, add ciphersuite: 00c0 ssl_cli.c:0921: |3| client hello, add ciphersuite: 0084 ssl_cli.c:0921: |3| client hello, add ciphersuite: c08d ssl_cli.c:0921: |3| client hello, add ciphersuite: c079 ssl_cli.c:0921: |3| client hello, add ciphersuite: c089 ssl_cli.c:0921: |3| client hello, add ciphersuite: c075 ssl_cli.c:0921: |3| client hello, add ciphersuite: 009c ssl_cli.c:0921: |3| client hello, add ciphersuite: c09c ssl_cli.c:0921: |3| client hello, add ciphersuite: 003c ssl_cli.c:0921: |3| client hello, add ciphersuite: 002f ssl_cli.c:0921: |3| client hello, add ciphersuite: c031 ssl_cli.c:0921: |3| client hello, add ciphersuite: c029 ssl_cli.c:0921: |3| client hello, add ciphersuite: c00e ssl_cli.c:0921: |3| client hello, add ciphersuite: c02d ssl_cli.c:0921: |3| client hello, add ciphersuite: c025 ssl_cli.c:0921: |3| client hello, add ciphersuite: c004 ssl_cli.c:0921: |3| client hello, add ciphersuite: c0a0 ssl_cli.c:0921: |3| client hello, add ciphersuite: c07a ssl_cli.c:0921: |3| client hello, add ciphersuite: 00ba ssl_cli.c:0921: |3| client hello, add ciphersuite: 0041 ssl_cli.c:0921: |3| client hello, add ciphersuite: c08c ssl_cli.c:0921: |3| client hello, add ciphersuite: c078 ssl_cli.c:0921: |3| client hello, add ciphersuite: c088 ssl_cli.c:0921: |3| client hello, add ciphersuite: c074 ssl_cli.c:0921: |3| client hello, add ciphersuite: ccae ssl_cli.c:0921: |3| client hello, add ciphersuite: 00ad ssl_cli.c:0921: |3| client hello, add ciphersuite: 00b7 ssl_cli.c:0921: |3| client hello, add ciphersuite: 0095 ssl_cli.c:0921: |3| client hello, add ciphersuite: c093 ssl_cli.c:0921: |3| client hello, add ciphersuite: c099 ssl_cli.c:0921: |3| client hello, add ciphersuite: 00ac ssl_cli.c:0921: |3| client hello, add ciphersuite: 00b6 ssl_cli.c:0921: |3| client hello, add ciphersuite: 0094 ssl_cli.c:0921: |3| client hello, add ciphersuite: c092 ssl_cli.c:0921: |3| client hello, add ciphersuite: c098 ssl_cli.c:0921: |3| client hello, add ciphersuite: ccab ssl_cli.c:0921: |3| client hello, add ciphersuite: 00a9 ssl_cli.c:0921: |3| client hello, add ciphersuite: c0a5 ssl_cli.c:0921: |3| client hello, add ciphersuite: 00af ssl_cli.c:0921: |3| client hello, add ciphersuite: 008d ssl_cli.c:0921: |3| client hello, add ciphersuite: c08f ssl_cli.c:0921: |3| client hello, add ciphersuite: c095 ssl_cli.c:0921: |3| client hello, add ciphersuite: c0a9 ssl_cli.c:0921: |3| client hello, add ciphersuite: 00a8 ssl_cli.c:0921: |3| client hello, add ciphersuite: c0a4 ssl_cli.c:0921: |3| client hello, add ciphersuite: 00ae ssl_cli.c:0921: |3| client hello, add ciphersuite: 008c ssl_cli.c:0921: |3| client hello, add ciphersuite: c08e ssl_cli.c:0921: |3| client hello, add ciphersuite: c094 ssl_cli.c:0921: |3| client hello, add ciphersuite: c0a8 ssl_cli.c:0934: |3| client hello, got 127 ciphersuites (excluding SCSVs) ssl_cli.c:0943: |3| adding EMPTY_RENEGOTIATION_INFO_SCSV ssl_cli.c:0992: |3| client hello, compress len.: 1 ssl_cli.c:0993: |3| client hello, compress alg.: 0 ssl_cli.c:0068: |3| client hello, adding server name extension: a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com<http://a2g7twmqo7hg82-ats.iot.ap-south-1.amazonaws.com/> ssl_cli.c:0186: |3| client hello, adding signature_algorithms extension ssl_cli.c:0271: |3| client hello, adding supported_elliptic_curves extension ssl_cli.c:0336: |3| client hello, adding supported_point_formats extension ssl_cli.c:0517: |3| client hello, adding encrypt_then_mac extension ssl_cli.c:0551: |3| client hello, adding extended_master_secret extension ssl_cli.c:0585: |3| client hello, adding session ticket extension ssl_cli.c:1070: |3| client hello, total extension length: 128 ssl_tls.c:3184: |2| => write handshake message ssl_tls.c:3343: |2| => write record ssl_tls.c:3420: |3| output record: msgtype = 22, version = [3:1], msglen = 429 ssl_tls.c:3425: |4| dumping 'output record sent to network' (434 bytes) ssl_tls.c:3425: |4| 0000: 16 03 01 01 ad 01 00 01 a9 03 03 5b d9 84 1f 2f ...........[.../ ssl_tls.c:3425: |4| 0010: 33 35 54 ea 0b 5d e1 dc 42 0c 99 d4 a1 25 72 6f 35T..]..B....%ro ssl_tls.c:3425: |4| 0020: 0f cf 8e 56 0d ab f5 10 e4 47 46 00 01 00 cc a8 ...V.....GF..... ssl_tls.c:3425: |4| 0030: cc a9 cc aa c0 2c c0 30 00 9f c0 ad c0 9f c0 24 .....,.0.......$ ssl_tls.c:3425: |4| 0040: c0 28 00 6b c0 0a c0 14 00 39 c0 af c0 a3 c0 87 .(.k.....9...... ssl_tls.c:3425: |4| 0050: c0 8b c0 7d c0 73 c0 77 00 c4 00 88 c0 2b c0 2f ...}.s.w.....+./ ssl_tls.c:3425: |4| 0060: 00 9e c0 ac c0 9e c0 23 c0 27 00 67 c0 09 c0 13 .......#.'.g.... ssl_tls.c:3425: |4| 0070: 00 33 c0 ae c0 a2 c0 86 c0 8a c0 7c c0 72 c0 76 .3.........|.r.v ssl_tls.c:3425: |4| 0080: 00 be 00 45 cc ac cc ad 00 ab c0 a7 c0 38 00 b3 ...E.........8.. ssl_tls.c:3425: |4| 0090: c0 36 00 91 c0 91 c0 9b c0 97 c0 ab 00 aa c0 a6 .6.............. ssl_tls.c:3425: |4| 00a0: c0 37 00 b2 c0 35 00 90 c0 90 c0 96 c0 9a c0 aa .7...5.......... ssl_tls.c:3425: |4| 00b0: 00 9d c0 9d 00 3d 00 35 c0 32 c0 2a c0 0f c0 2e .....=.5.2.*.... ssl_tls.c:3425: |4| 00c0: c0 26 c0 05 c0 a1 c0 7b 00 c0 00 84 c0 8d c0 79 .&.....{.......y ssl_tls.c:3425: |4| 00d0: c0 89 c0 75 00 9c c0 9c 00 3c 00 2f c0 31 c0 29 ...u.....<./.1.) ssl_tls.c:3425: |4| 00e0: c0 0e c0 2d c0 25 c0 04 c0 a0 c0 7a 00 ba 00 41 ...-.%.....z...A ssl_tls.c:3425: |4| 00f0: c0 8c c0 78 c0 88 c0 74 cc ae 00 ad 00 b7 00 95 ...x...t........ ssl_tls.c:3425: |4| 0100: c0 93 c0 99 00 ac 00 b6 00 94 c0 92 c0 98 cc ab ................ ssl_tls.c:3425: |4| 0110: 00 a9 c0 a5 00 af 00 8d c0 8f c0 95 c0 a9 00 a8 ................ ssl_tls.c:3425: |4| 0120: c0 a4 00 ae 00 8c c0 8e c0 94 c0 a8 00 ff 01 00 ................ ssl_tls.c:3425: |4| 0130: 00 80 00 00 00 34 00 32 00 00 2f 61 32 67 37 74 .....4.2../a2g7t ssl_tls.c:3425: |4| 0140: 77 6d 71 6f 37 68 67 38 32 2d 61 74 73 2e 69 6f wmqo7hg82-ats.io<http://wmqo7hg82-ats.io/> ssl_tls.c:3425: |4| 0150: 74 2e 61 70 2d 73 6f 75 74 68 2d 31 2e 61 6d 61 t.ap-south-1.ama ssl_tls.c:3425: |4| 0160: 7a 6f 6e 61 77 73 2e 63 6f 6d 00 0d 00 16 00 14 zonaws.com...... ssl_tls.c:3425: |4| 0170: 06 03 06 01 05 03 05 01 04 03 04 01 03 03 03 01 ................ ssl_tls.c:3425: |4| 0180: 02 03 02 01 00 0a 00 18 00 16 00 19 00 1c 00 18 ................ ssl_tls.c:3425: |4| 0190: 00 1b 00 17 00 16 00 1a 00 15 00 14 00 13 00 12 ................ ssl_tls.c:3425: |4| 01a0: 00 0b 00 02 01 00 00 16 00 00 00 17 00 00 00 23 ...............# ssl_tls.c:3425: |4| 01b0: 00 00 .. ssl_tls.c:2755: |2| => flush output ssl_tls.c:2773: |2| message length: 434, out_left: 434 ssl_tls.c:2779: |2| ssl->f_send() returned 434 (-0xfffffe4e) ssl_tls.c:2807: |2| <= flush output ssl_tls.c:3476: |2| <= write record ssl_tls.c:3320: |2| <= write handshake message ssl_cli.c:1106: |2| <= write client hello ssl_cli.c:3510: |2| client state: 2 ssl_tls.c:2755: |2| => flush output ssl_tls.c:2767: |2| <= flush output ssl_cli.c:1499: |2| => parse server hello ssl_tls.c:4311: |2| => read record ssl_tls.c:2536: |2| => fetch input ssl_tls.c:2696: |2| in_left: 0, nb_want: 5 ssl_tls.c:2720: |2| in_left: 0, nb_want: 5 ssl_tls.c:2722: |2| ssl->f_recv(_timeout)() returned -80 (-0x0050) ssl_tls.c:4973: |1| mbedtls_ssl_fetch_input() returned -80 (-0x0050) ssl_tls.c:4344: |1| ssl_get_next_record() returned -80 (-0x0050) ssl_cli.c:1506: |1| mbedtls_ssl_read_record() returned -80 (-0x0050) ssl_tls.c:8094: |2| <= handshake failed ! mbedtls_ssl_handshake returned -0x50 Last error was: -0x50 - NET - Connection was reset by peer ssl_tls.c:8934: |2| => free ssl_tls.c:8999: |2| <= free I request you to help me in resolving this issue. Regards, Srinivas. [cid:ef4e58a5-df1a-47f0-90b9-c467a93244c2]

6 years, 2 months

1
0
0 0

Re: [mbed-tls] support mbedTLS no entropy source

by Dan Handley

Hi Palomo All the documentation we have to share is already available, either in the upstream codebase, the wiki (https://developer.trustedfirmware.org/w/mbed-tls/) or the legacy website (https://tls.mbed.org/). Some of the info on the latter is out of date. The core development team at Arm do not offer training. Arm has a Partner Enablement Group that does this kind of thing but I don't think they offer Mbed TLS specific training currently. I've asked them if they would consider this in future but I guess that's not going to help you in the short term. Good luck with your learning and we'll try to answer any specific questions you have. Regards Dan. From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of Jesus Gualberto Palomo Garcia via mbed-tls Sent: 08 June 2020 04:46 To: Gilles Peskine <Gilles.Peskine(a)arm.com> Cc: mbed-tls(a)lists.trustedfirmware.org Subject: Re: [mbed-tls] support mbedTLS no entropy source Hi Gilles. Thanks for follow my questions and attend it, regarding trainings, I want to understand how the encryption works, how the algorithms works inside the library, I can read the code and google the concepts but I want to accelerate the knowledge transfer, maybe for implement some optimization, I don't if that is possible, at the moment my PoC using uClinux works perfectly and the TLS 1.2 ir running over 80Mhz, so that is pretty awesome, but I want to learn more about encryption, maybe if you can share me some literature regarding this point? Thank you very much and regards from Mexico! On Tue, Jun 2, 2020 at 6:21 PM Gilles Peskine <gilles.peskine(a)arm.com<mailto:gilles.peskine@arm.com>> wrote: Hi Palomo, I don't think there's any other way at the moment. The patch in my email is one possible solution, but I'm not sure if it's right, because not all platforms with a Linux kernel have /dev/urandom. I think the best solution would be to make the existence of /dev/urandom a platform configuration option. But platform options are a little messy already, between the MBEDTLS_HAVE_xxx options, the MBEDTLS_PLATFORM_STD_xxx options, the MBEDTLS_PLATFORM_xxx_MACRO options, the MBEDTLS_PLATFORM_xxx_ALT options. And this new option wouldn't behave like any of the existing ones since it should have three settings: guess (the default, identical to the current behavior of observing preprocessor symbols like __unix__), off and on. We should figure out what to do about platform options in 3.0 before making this even more complex. me.todo.add("collect my thoughts on simplifying platform customization and post them to the list") Regarding trainings, my team doesn't normally do that, but there are other teams in Arm that do. What topic are you interested in? -- Gilles Peskine Mbed TLS developer On 31/05/2020 20:06, Jesus Gualberto Palomo Garcia wrote: > Hello Gilles thanks for your support, yes finally I could compile the > library in the architecture that I used, I forced the compilation to > entry in the "if _unix_" conditional compilation, but I assume that > exist another way to do this. Do you have a example for enable that > conditional compilation flags? > > regarding to my dev/urandom, yes my platform has this feature, the > library runs very well, but I just have the point related to "force" > the compilation because the library doesn't recognize the unix > architecture. > > Thanks and we keep in touch! > > Regards from Mexico! > > BTW If I want to professional training, Do you offered this service? > > On Mon, May 25, 2020 at 11:07 AM Gilles Peskine via mbed-tls > <mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> > <mailto:mbed-tls@lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>>> wrote: > > Hi Palomo, > > You seem to be compiling for a system with a Linux kernel, but > with only > a partial Unix userland. The “Unix” code in the entropy_poll module > might work on your system, but it is only enabled if __unix__ or > __unix > (or a few others) is defined. > > Can you please try the attached patch? Does your runtime environment > have /dev/urandom ? > > Regarding the knowledge base article, you need to remove the "." > character at the end of the URL: > https://tls.mbed.org/kb/how-to/add-a-random-generator-- > > Gilles Peskine > Mbed TLS developer > > On 19/05/2020 21:43, Jesus Gualberto Palomo Garcia via mbed-tls wrote: > > Hello Hanno, Thanks for your thanks for you quickly replay. > > > > I have an error compilation, I'm using nios2-linux-uclibc for my > cross > > compilation and uclinux architecture, > > the linux kernel is 2.60 but I have this error when I try to compile > > the library, I want to use the library as a simple client using > TLS1.2 > > > > $ make static > > CC aes.c > > CC aesni.c > > CC arc4.c > > CC aria.c > > CC asn1parse.c > > CC asn1write.c > > CC base64.c > > CC bignum.c > > CC blowfish.c > > CC camellia.c > > CC ccm.c > > CC chacha20.c > > CC chachapoly.c > > CC cipher.c > > CC cipher_wrap.c > > CC cmac.c > > CC ctr_drbg.c > > CC des.c > > CC dhm.c > > CC ecdh.c > > CC ecdsa.c > > CC ecjpake.c > > CC ecp.c > > CC ecp_curves.c > > CC entropy.c > > CC entropy_poll.c > > entropy_poll.c:56:2: #error "Platform entropy sources only work on > > Unix and Windows, see MBEDTLS_NO_PLATFORM_ENTROPY in config.h" > > Makefile:285: recipe for target 'entropy_poll.o' failed > > make: *** [entropy_poll.o] Error 1 > > > > BTW the article is not > > found https://tls.mbed.org/kb/how-to/add-a-random-generator. > > <https://tls.mbed.org/kb/how-to/add-a-random-generator.> > > > > Many thanks!! > > > > > > On Tue, May 19, 2020 at 9:01 AM Hanno Becker > <Hanno.Becker(a)arm.com<mailto:Hanno.Becker@arm.com> <mailto:Hanno.Becker@arm.com<mailto:Hanno.Becker@arm.com>> > > <mailto:Hanno.Becker@arm.com<mailto:Hanno.Becker@arm.com> <mailto:Hanno.Becker@arm.com<mailto:Hanno.Becker@arm.com>>>> wrote: > > > > Hi Palomo, > > > > Please take a look at the recent > > > thread https://lists.trustedfirmware.org/pipermail/mbed-tls/2020-April/000069.html > > which should give you a better understanding of how Mbed TLS > > manages and uses entropy from the underlying system. > > > > Regards, > > Hanno > > > ------------------------------------------------------------------------ > > *From:* mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org<mailto:mbed-tls-bounces@lists.trustedfirmware.org> > <mailto:mbed-tls-bounces@lists.trustedfirmware.org<mailto:mbed-tls-bounces@lists.trustedfirmware.org>> > > <mailto:mbed-tls-bounces@lists.trustedfirmware.org<mailto:mbed-tls-bounces@lists.trustedfirmware.org> > <mailto:mbed-tls-bounces@lists.trustedfirmware.org<mailto:mbed-tls-bounces@lists.trustedfirmware.org>>>> on behalf of > > Jesus Gualberto Palomo Garcia via mbed-tls > > <mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> > <mailto:mbed-tls@lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>> > > <mailto:mbed-tls@lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> > <mailto:mbed-tls@lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>>>> > > *Sent:* Tuesday, May 19, 2020 2:56 PM > > *To:* mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> > <mailto:mbed-tls@lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>> > > <mailto:mbed-tls@lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> > <mailto:mbed-tls@lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>>> > > <mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> > <mailto:mbed-tls@lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>> > > <mailto:mbed-tls@lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> > <mailto:mbed-tls@lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>>>> > > *Subject:* [mbed-tls] support mbedTLS no entropy source > > > > Hi all! > > > > I'm Palomo and I've been working with your library a few weeks > > ago, I'm using Linux kernel 2.60 but my embedded system has a > > limit entropy source, i now that this is a critical point, > but How > > can I use your library if I want to use a other entropy source? > > > > Thanks and waiting for you! > > > > -- > > *¡Saludos! Best wishes!* > > * > > * > > * > > /*Jesus** Palomo*/ > > > > México, D.F. > > > > * > > > > > > > > -- > > *¡Saludos! Best wishes!* > > * > > * > > * > > /*Jesus** Palomo*/ > > > > México, D.F. > > > > * > > > > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> > <mailto:mbed-tls@lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>> > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > > > > -- > *¡Saludos! Best wishes!* > * > * > * > /*Jesus** Palomo*/ > > México, D.F. > > * -- ¡Saludos! Best wishes! Jesus Palomo México, D.F.

6 years, 2 months

1
0
0 0

Re: [mbed-tls] support mbedTLS no entropy source

by Jesus Gualberto Palomo Garcia

Hello Gilles thanks for your support, yes finally I could compile the library in the architecture that I used, I forced the compilation to entry in the "if _unix_" conditional compilation, but I assume that exist another way to do this. Do you have a example for enable that conditional compilation flags? regarding to my dev/urandom, yes my platform has this feature, the library runs very well, but I just have the point related to "force" the compilation because the library doesn't recognize the unix architecture. Thanks and we keep in touch! Regards from Mexico! BTW If I want to professional training, Do you offered this service? On Mon, May 25, 2020 at 11:07 AM Gilles Peskine via mbed-tls < mbed-tls(a)lists.trustedfirmware.org> wrote: > Hi Palomo, > > You seem to be compiling for a system with a Linux kernel, but with only > a partial Unix userland. The “Unix” code in the entropy_poll module > might work on your system, but it is only enabled if __unix__ or __unix > (or a few others) is defined. > > Can you please try the attached patch? Does your runtime environment > have /dev/urandom ? > > Regarding the knowledge base article, you need to remove the "." > character at the end of the URL: > https://tls.mbed.org/kb/how-to/add-a-random-generator-- > > Gilles Peskine > Mbed TLS developer > > On 19/05/2020 21:43, Jesus Gualberto Palomo Garcia via mbed-tls wrote: > > Hello Hanno, Thanks for your thanks for you quickly replay. > > > > I have an error compilation, I'm using nios2-linux-uclibc for my cross > > compilation and uclinux architecture, > > the linux kernel is 2.60 but I have this error when I try to compile > > the library, I want to use the library as a simple client using TLS1.2 > > > > $ make static > > CC aes.c > > CC aesni.c > > CC arc4.c > > CC aria.c > > CC asn1parse.c > > CC asn1write.c > > CC base64.c > > CC bignum.c > > CC blowfish.c > > CC camellia.c > > CC ccm.c > > CC chacha20.c > > CC chachapoly.c > > CC cipher.c > > CC cipher_wrap.c > > CC cmac.c > > CC ctr_drbg.c > > CC des.c > > CC dhm.c > > CC ecdh.c > > CC ecdsa.c > > CC ecjpake.c > > CC ecp.c > > CC ecp_curves.c > > CC entropy.c > > CC entropy_poll.c > > entropy_poll.c:56:2: #error "Platform entropy sources only work on > > Unix and Windows, see MBEDTLS_NO_PLATFORM_ENTROPY in config.h" > > Makefile:285: recipe for target 'entropy_poll.o' failed > > make: *** [entropy_poll.o] Error 1 > > > > BTW the article is not > > found https://tls.mbed.org/kb/how-to/add-a-random-generator. > > <https://tls.mbed.org/kb/how-to/add-a-random-generator.> > > > > Many thanks!! > > > > > > On Tue, May 19, 2020 at 9:01 AM Hanno Becker <Hanno.Becker(a)arm.com > > <mailto:Hanno.Becker@arm.com>> wrote: > > > > Hi Palomo, > > > > Please take a look at the recent > > thread > https://lists.trustedfirmware.org/pipermail/mbed-tls/2020-April/000069.html > > > which should give you a better understanding of how Mbed TLS > > manages and uses entropy from the underlying system. > > > > Regards, > > Hanno > > > ------------------------------------------------------------------------ > > *From:* mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org > > <mailto:mbed-tls-bounces@lists.trustedfirmware.org>> on behalf of > > Jesus Gualberto Palomo Garcia via mbed-tls > > <mbed-tls(a)lists.trustedfirmware.org > > <mailto:mbed-tls@lists.trustedfirmware.org>> > > *Sent:* Tuesday, May 19, 2020 2:56 PM > > *To:* mbed-tls(a)lists.trustedfirmware.org > > <mailto:mbed-tls@lists.trustedfirmware.org> > > <mbed-tls(a)lists.trustedfirmware.org > > <mailto:mbed-tls@lists.trustedfirmware.org>> > > *Subject:* [mbed-tls] support mbedTLS no entropy source > > > > Hi all! > > > > I'm Palomo and I've been working with your library a few weeks > > ago, I'm using Linux kernel 2.60 but my embedded system has a > > limit entropy source, i now that this is a critical point, but How > > can I use your library if I want to use a other entropy source? > > > > Thanks and waiting for you! > > > > -- > > *¡Saludos! Best wishes!* > > * > > * > > * > > /*Jesus** Palomo*/ > > > > México, D.F. > > > > * > > > > > > > > -- > > *¡Saludos! Best wishes!* > > * > > * > > * > > /*Jesus** Palomo*/ > > > > México, D.F. > > > > * > > > > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > -- *¡Saludos! Best wishes!* *Jesus PalomoMéxico, D.F.*

6 years, 2 months

2
2
0 0

Feedback sought on a new PSA Crypto driver interface

by Gilles Peskine

Hello, Arm is seeking early feedback on a proposed interface for cryptographic drivers that can be plugged into an implementation of the PSA Cryptography API. A copy of the current specification is attached. You can find the current draft of the specification of this interface at https://github.com/gilles-peskine-arm/mbedtls/blob/psa-unified-driver-proto… Please note that this is work in progress. The document is not complete yet. At this stage, it is intended to offer a general overview of the design, not as an implementable specification. Our intention is to continue refining this design, however we may change it based on the feedback that we will receive and there is even a small chance that we will abandon it. The primary intent of this specification is to allow manufacturers of cryptographic hardware to distribute drivers that can be added to a pure-software, portable implementation of the PSA Cryptography API such as Mbed TLS. The interface was designed to support three types of hardware: * Cryptographic accelerators that operate on a key which is provided in cleartext at the beginning of the operation. This type of driver can also be used to plug in software engines. * Protected environments that operate on a wrapped key which is stored outside the protected environment. * Protected environments that have internal key storage and operate on keys designated by an identifier. Concretely, a driver manufacturer would distribute: * A JSON file specifying the driver's capabilities. * C headers declaring the types and functions provided by the driver. * The implementation of the functions provided by the driver, either in the form of C source code or in the form of compiled code. Then when an application uses a key: * If the key is in the memory or local storage of the PSA crypto subsystem and a driver is available for the requested cryptographic mechanism, the core (e.g. Mbed TLS) dispatches the cryptographic operation to the driver. * If the key is in local storage and no driver is available, the core performs the cryptographic operation itself. * If the key is in some other location (as specified by its lifetime), the core invokes the protected environment driver corresponding to that location. This proposal supersedes the previous drafts “PSA cryptographic accelerator interface” (psa_crypto_accel.h) and “PSA secure element driver interface” (crypto_se_driver.h). We intend to implement this specification in Mbed TLS in such a way that a platform distributor can combine drivers and distribute C source code, object files or a mixture of the two in their system development kit. In the long term, the accelerator interface defined here will replace the current MBEDTLS_xxx_ALT mechanism. Comments are welcome through the following venues: * Public email to the psa-crypto or mbed-tls mailing list at TrustedFirmware. * Public comments on GitHub on the pull request https://github.com/ARMmbed/mbedtls/pull/3313 . * Private email to <mbed-crypto(a)arm.com>. These emails will only be shared inside Arm. We may use your feedback to influence the design of PSA Crypto, but your identity and the specifics will be kept confidential. We do not have a specific deadline for feedback, however we intend to start implementing this interface in Mbed TLS in June 2020, so feedback received later will have a reduced chance of influencing the design if it would entail major changes. Best regards, -- Gilles Peskine Mbed TLS developer and PSA Cryptography architect

6 years, 2 months

1
0
0 0

Re: [mbed-tls] support mbedTLS no entropy source

by Gilles Peskine

Hi Palomo, You seem to be compiling for a system with a Linux kernel, but with only a partial Unix userland. The “Unix” code in the entropy_poll module might work on your system, but it is only enabled if __unix__ or __unix (or a few others) is defined. Can you please try the attached patch? Does your runtime environment have /dev/urandom ? Regarding the knowledge base article, you need to remove the "." character at the end of the URL: https://tls.mbed.org/kb/how-to/add-a-random-generator-- Gilles Peskine Mbed TLS developer On 19/05/2020 21:43, Jesus Gualberto Palomo Garcia via mbed-tls wrote: > Hello Hanno, Thanks for your thanks for you quickly replay. > > I have an error compilation, I'm using nios2-linux-uclibc for my cross > compilation and uclinux architecture, > the linux kernel is 2.60 but I have this error when I try to compile > the library, I want to use the library as a simple client using TLS1.2 > > $ make static > CC aes.c > CC aesni.c > CC arc4.c > CC aria.c > CC asn1parse.c > CC asn1write.c > CC base64.c > CC bignum.c > CC blowfish.c > CC camellia.c > CC ccm.c > CC chacha20.c > CC chachapoly.c > CC cipher.c > CC cipher_wrap.c > CC cmac.c > CC ctr_drbg.c > CC des.c > CC dhm.c > CC ecdh.c > CC ecdsa.c > CC ecjpake.c > CC ecp.c > CC ecp_curves.c > CC entropy.c > CC entropy_poll.c > entropy_poll.c:56:2: #error "Platform entropy sources only work on > Unix and Windows, see MBEDTLS_NO_PLATFORM_ENTROPY in config.h" > Makefile:285: recipe for target 'entropy_poll.o' failed > make: *** [entropy_poll.o] Error 1 > > BTW the article is not > found https://tls.mbed.org/kb/how-to/add-a-random-generator. > <https://tls.mbed.org/kb/how-to/add-a-random-generator.> > > Many thanks!! > > > On Tue, May 19, 2020 at 9:01 AM Hanno Becker <Hanno.Becker(a)arm.com > <mailto:Hanno.Becker@arm.com>> wrote: > > Hi Palomo, > > Please take a look at the recent > thread https://lists.trustedfirmware.org/pipermail/mbed-tls/2020-April/000069.html > which should give you a better understanding of how Mbed TLS > manages and uses entropy from the underlying system. > > Regards, > Hanno > ------------------------------------------------------------------------ > *From:* mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org > <mailto:mbed-tls-bounces@lists.trustedfirmware.org>> on behalf of > Jesus Gualberto Palomo Garcia via mbed-tls > <mbed-tls(a)lists.trustedfirmware.org > <mailto:mbed-tls@lists.trustedfirmware.org>> > *Sent:* Tuesday, May 19, 2020 2:56 PM > *To:* mbed-tls(a)lists.trustedfirmware.org > <mailto:mbed-tls@lists.trustedfirmware.org> > <mbed-tls(a)lists.trustedfirmware.org > <mailto:mbed-tls@lists.trustedfirmware.org>> > *Subject:* [mbed-tls] support mbedTLS no entropy source > > Hi all! > > I'm Palomo and I've been working with your library a few weeks > ago, I'm using Linux kernel 2.60 but my embedded system has a > limit entropy source, i now that this is a critical point, but How > can I use your library if I want to use a other entropy source? > > Thanks and waiting for you! > > -- > *¡Saludos! Best wishes!* > * > * > * > /*Jesus** Palomo*/ > > México, D.F. > > * > > > > -- > *¡Saludos! Best wishes!* > * > * > * > /*Jesus** Palomo*/ > > México, D.F. > > * >

6 years, 2 months

1
0
0 0

Re: [mbed-tls] support mbedTLS no entropy source

by Hanno Becker

Hi Palomo, Please take a look at the recent thread https://lists.trustedfirmware.org/pipermail/mbed-tls/2020-April/000069.html which should give you a better understanding of how Mbed TLS manages and uses entropy from the underlying system. Regards, Hanno ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Jesus Gualberto Palomo Garcia via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: Tuesday, May 19, 2020 2:56 PM To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] support mbedTLS no entropy source Hi all! I'm Palomo and I've been working with your library a few weeks ago, I'm using Linux kernel 2.60 but my embedded system has a limit entropy source, i now that this is a critical point, but How can I use your library if I want to use a other entropy source? Thanks and waiting for you! -- ¡Saludos! Best wishes! Jesus Palomo México, D.F.

6 years, 2 months

2
1
0 0

support mbedTLS no entropy source

by Jesus Gualberto Palomo Garcia

Hi all! I'm Palomo and I've been working with your library a few weeks ago, I'm using Linux kernel 2.60 but my embedded system has a limit entropy source, i now that this is a critical point, but How can I use your library if I want to use a other entropy source? Thanks and waiting for you! -- *¡Saludos! Best wishes!* *Jesus PalomoMéxico, D.F.*

6 years, 2 months

1
0
0 0

Re: [mbed-tls] Psk tls with trustzone

by Gilles Peskine

Hello, If you enable the use PSA for cryptography in TLS (MBEDTLS_USE_PSA_CRYPTO) and configure the PSK with mbedtls_ssl_conf_psk_opaque(), the key derivation is done through the PSA API. You can then keep your key in the secure world. You'll need to have a PSA crypto implementation where the PSA crypto core is in the secure world and the frontend is in the application that performs the TLS handshake. PSA crypto is designed for this, but you or your TEE vendor will need to port the Mbed TLS code to your platform. -- Gilles Peskine Mbed TLS developer On 13/05/2020 11:10, mayuri janawad via mbed-tls wrote: > Hello, > > I am currently trying to establish pre shared key based tls handshake > using mbedtls. However, I want to store the pre shared key in the > trustzone and derive the session key inside the trustzone. Is it > possible using mbedtls? Can I provide alternate implementation for psk > based tls in mbedtls library? > > It would be really helpful if this could be answered as soon as > possible. Thank you in advance for your assistance. > > Regards, > Mayuri Janawad >

6 years, 3 months

1
0
0 0

Psk tls with trustzone

by mayuri janawad

Hello, I am currently trying to establish pre shared key based tls handshake using mbedtls. However, I want to store the pre shared key in the trustzone and derive the session key inside the trustzone. Is it possible using mbedtls? Can I provide alternate implementation for psk based tls in mbedtls library? It would be really helpful if this could be answered as soon as possible. Thank you in advance for your assistance. Regards, Mayuri Janawad

6 years, 3 months

1
0
0 0

Re: [mbed-tls] ECDH Computation on STM32 platform

by Manuel Pegourie-Gonnard

Hi Abhilash, > I am trying to do the ECDH shared secret computation using the mbedTLS > library. I am referring to multiple examples such as ecdh_curve25519.c > and ecdh_main.c. > Ok. You should probably know a few things about those examples: 1. They both perform what's known as "ephemeral ECDH" (or sometimes ECDHE). 2. They're both using the low-level part of our ECDH API. For ecdh_curve25519, that is because that curve is not supported by the higher-level API yet - for the other example, I don't know what the reason is. 3. Curve25519 is quite different from other curves regarding how public keys are represented. > In my case, in my application firmware, I already have a device _priv > key and I receive a server_public key; both generated using a curve > ECP_DP_SECP256R1 in the bootloader itself. So in the application > firmware, I would like to do generate a shared secret from here on and > preserve it for future use. > Ok, so you want to do what's known as "static ECDH". So the example ecdh_curve25519 is not a great example, due to points 1 and 3 above. Also, since the curve you're using supports it, you may want to use the higher-level part of our ECDH API (the functions that accept a context as an argument). > The following is the steps that I do: > > 1. Create a new client context, entropy context, ctr_drbg context variables. > 2. use mbedtls_"respective"_init() to initalize all the three variables > 3. Seed a random number using mbedtls_ctr_drbg_seed() function. > 4. load the P256 elliptic curve in client context using mbedtls_ecp_group_load() All this looks absolutely correct. > 5. Then use mbedtls_mpi_lset() to set Qp.Z =1 > 6. Then read the server pub key using mbedtls_mpi_read_binary(&ctx_cli.Qp.X, server_pub, 65); >From the 65 I assume that the server public key as encoded as an uncompressed point. Then you can read it with: mbedtls_ecp_point_read_binary(&ctx_cli.grp, &ctx_cli.Qp, server_pub, 65); (For Curve25519 mbedtls_ecp_point_read_binary() isn't implemented yet which is why the example does a direct call to an MPI function and accesses individual point coordinates, but Curve25519 and P-256 don't use the same coordinate systems.) > 7. Now the question is: Should I initialize the ctx_cli with my already generated device_priv key using > mbedtls_mpi_read_binary(&ctx_cli.d, device_priv_key, 50) ? That looks almost correct, except 50 does not look like a valid size for a private key for the curve you're using. > 8. Then I use mbedtls_ecdh_compute_shared(&ctx_cli.grp, &ctx_cli.z, &ctx_cli.Qp, &ctx_cli.d, mbedtls_ctr_drbg_random, &ctr_drbg); to compute the shared secret in z. > That's correct, but you could also call mbedtls_ecdh_calc_secret( &ctx_cli, &olen, buf, blen, mbedtls_ctr_drbg_random, &ctr_drbg ); which also serializes the secret to a buffer. > Questions: > 1. Do I need to generate a keypair for client context using > mbedtls_ecdh_gen_public(&ctx_cli.grp, &ctx_cli.d, &ctx_cli.Q, > mbedtls_ctr_drbg_random, &ctrDrbg)? And then set pvtkey as device priv > key and pub key as service pub key? > I'm not sure I understand the context of the question, so I'll distinguish two cases: - When provisioning the device, you need to generate a key pair for it, which can indeed be done as show. - Once the device is working, it doesn't need to generate new key pairs, just load the one that was provisioned as described below. > 2. I see that ctx_cli.Q has two components, Q.x and Q.y. How do I > extract these two values from a public key? Do I need to separately > initialize them? > I don't recommend you manipulate those directly, but use the `mbedtls_ecp_point_{read,write}_binary()` functions instead. > Please let me know if the flow is correct. In all the examples, they > generate a key pair and just update the public key part (Qp.X) of the > key. They do not touch the private key part (d) of the key. Please > confirm if I can upload my private key directly in my case. > Your flow looks correct, and the difference from the examples is that they're demonstrating ephemeral ECDH while it looks like you want to do static ECDH. > Also if my platform is a little endian, is there a recommended step > before using mbedtls_mpi_read_binary_le functions? Then endianness of your plaftorm should not matter, and you shouldn't need to use that function. Regards, Manuel.

6 years, 3 months

1
0
0 0

Re: [mbed-tls] Edwards curve support (#3245): fixing mbedtls_ecp_get_type

by Manuel Pegourie-Gonnard

Hi Aurélien, > I have submitted PR#3245 in order to add Edwards curves support to Mbed > TLS, with the eventual goal to add support for the EdDSA algorithm. > There are still a few things to fix that require discussion. > Thank you very much for your contribution, and for opening this discussion! > Let's start the discussion with the first one. Adding a new curve type > requires to add a new entry to the mbedtls_ecp_curve_type enum. The > curve type used by a group is returned by the mbedtls_ecp_get_type > function. It currently uses the coordinates type of the base point to > determine the curve type. Montgomery curves are lacking the y > coordinate, and the Short Weierstrass curves use the three x, y and z > coordinates. > > The Edwards arithmetic implementation in this PR uses the projective > coordinates. As such it also uses the x, y and z coordinates and this > gives no way to differentiate a Short Weierstrass from an Edwards curve. > Indeed, the current implementation of `ecp_curve_type()` is a bit of a hack and needs changing now that you're adding Edwards curves. > I have currently implemented that by checking if the curves are the > Ed25519 or Ed448 ones using the group id [1]. I am not sure it's very > clean and it won't scale if more curves are added later. Another > alternative would be to add another entry to mbedtls_ecp_group to hold > the curve type. > > What do you think is the best option? Any other idea? Honestly I think both options are fine. In the medium term (in 3.0 or 3.x) I'd like to entirely rework the `ecp_group` structure, which currently potentially wastes memory by having multiple instances for the same curve around (for example, when verifying a chain of N certificates all signed with the same curve, we'll have N instances of the `ecp_group` structure for that curve in RAM, which is quite wasteful). So I think in the meantime we don't need to sweat it too much. I have a slight preference for the option you currently implemented (checking the group ID), for two reasons: 1. Lack of scaling is not an issue, as it's unlikely a large number of Edwards curves are going to be added soon (in particular, not before the rework of ecp_group), since these last few years the tendency seems to be to focus on a small number of trusted curves [1]. 2. Adding a new member to `mbedtls_ecp_group` would be an ABI break, and while we don't have a strict policy of ABI stability, it tends to cause pain to packagers if we change the ABI too often, so it's probably better to avoid it if we can. Thanks, Manuel. [1] For example, compare https://tools.ietf.org/html/rfc4492#section-5.1.1 to https://tools.ietf.org/html/rfc8422#section-5.1.1

6 years, 3 months

1
0
0 0

Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code base

by Manuel Pegourie-Gonnard

Hi Simon, > I appreciate I'm coming very late to this discussion, but I want to make a > point and suggestion. > Well, I don't think we had reached a clear consensus yet, so it's not too late to explore more options! > These are very similar points to those Manuel was making to remove the feature > in the first place - however - short of investing the time in rewriting the > asymmetric functions, what we could do as a quick fix is to replace the > existing memory code with a block allocation scheme - which should be much > faster, speed up the asymmetric functions (in theory), avoid fragmentation, be > more deterministic, and a better fit for embedded applications. That could > then become the basis of the library for other projects too. > I think compared to our existing allocator, that would indeed be an improvement, and as you say possibly a "quick fix" for some of the performance issues of our asymmetric crypto (esp. ECC)... for people who use our allocator. I'm still under the impression they're a minority of users, even in the embedded world. I think it comes back to a point we touched on earlier in the thread: what other allocators are available, and how do they compare to the design you have in mind? If existing allocators in popular embedded libc implementations already handle small allocations efficiently, then people are probably better off using them. > I wouldn't mind contributing such a feature, as I had to write something very > similar last week anyway. > > If I do it - will you accept it? Thanks for the offer! Unfortunately I think it's hard to give you a clear yes or no answer at this point. Speaking only for myself (others in the team may disagree and are welcome to say so in reply), I'm a bit concerned that for a "quick fix" it would represent a significant review effort: there are obvious security implications, it would be a complete re-design of a whole module, and I'm not sure how many of the potential reviewers are very familiar with allocators (I know I'm not). Considering we already have a number of significant contributions that we just can't review as soon as we'd like, I'd be concerned adding another one. Adding to that concern is the fact that at this point it's still not clear to me if in the long-term we want to keep maintaining this, or use some existing allocator, or move it to a separate project possibly maintained by another team. Would your offer still stand in a couple of months, when the future of the module is perhaps a bit clearer, and when we've hopefully cleared a few of the long-standing large PR awaiting review? Thanks, Manuel.

6 years, 3 months

2
1
0 0

Re: [mbed-tls] Fwd: MBEDTLS never exits ecp_double_jac function call

by Gilles Peskine

Hi Sirjee, Does this fail systematically or randomly? Can you reproduce this with a very small program that only opens a TLS connection and nothing else, like programs/ssl/ssl_client1? At a guess, but this is only a guess, maybe this is the part of your program which uses the largest amount of stack, and there's a stack overflow that causes some variable to be overwritten. Please try increasing the stack size. -- Gilles Peskine Mbed TLS developer P.S. The config.h attachment didn't come through, but a graphical signature did. Please check your email settings when posting to the list. On 04/05/2020 10:50, Sirjee Rooplall via mbed-tls wrote: > > > Hi Support, > > I am using MBEDTLS and most of it works, except I have hit a snag > where I am trying to communicate to an https server, and it fails in > the ssl->handshake-step (ssl_write_client_key_exchange). > > My stack trace shows that it gets to the function ecp_double_jac and > never exits. It is looping at > MBEDTLS_MPI_CHK( mbedtls_mpi_add_mpi( &T, &P->X, &S ) ); > MOD_ADD( T );. > Stack trace: > test.elf! mbedtls_mpi_sub_abs (mbedtls_mpi * X, const mbedtls_mpi * A, > const mbedtls_mpi * B) Line: 1287 > test.elf! ecp_double_jac (const mbedtls_ecp_group * grp, > mbedtls_ecp_point * R, const mbedtls_ecp_point * P) Line: 1310 > test.elf! ecp_precompute_comb (const mbedtls_ecp_group * grp, > mbedtls_ecp_point * T, const mbedtls_ecp_point * P, unsigned char w, > size_t d, mbedtls_ecp_restart_ctx * rs_ctx) Line: 1702 > test.elf! ecp_mul_comb (mbedtls_ecp_group * grp, mbedtls_ecp_point * > R, const mbedtls_mpi * m, const mbedtls_ecp_point * P, int (*)(void *, > unsigned char *, size_t) f_rng, void * p_rng, mbedtls_ecp_restart_ctx > * rs_ctx) Line: 2095 > test.elf! mbedtls_ecp_mul_restartable (mbedtls_ecp_group * grp, > mbedtls_ecp_point * R, const mbedtls_mpi * m, const mbedtls_ecp_point > * P, int (*)(void *, unsigned char *, size_t) f_rng, void * p_rng, > mbedtls_ecp_restart_ctx * rs_ctx) Line: 2396 > test.elf! ecdh_gen_public_restartable (mbedtls_ecp_group * grp, > mbedtls_mpi * d, mbedtls_ecp_point * Q, int (*)(void *, unsigned char > *, size_t) f_rng, void * p_rng, mbedtls_ecp_restart_ctx * rs_ctx) > Line: 84 > test.elf! mbedtls_ecdh_gen_public (mbedtls_ecp_group * grp, > mbedtls_mpi * d, mbedtls_ecp_point * Q, int (*)(void *, unsigned char > *, size_t) f_rng, void * p_rng) Line: 102 > test.elf! ecdh_make_public_internal (mbedtls_ecdh_context_mbed * > ctx, size_t * olen, int point_format, unsigned char * buf, size_t > blen, int (*)(void *, unsigned char *, size_t) f_rng, void * p_rng, > int restart_enabled) Line: 514 > test.elf! mbedtls_ecdh_make_public (mbedtls_ecdh_context * ctx, > size_t * olen, unsigned char * buf, size_t blen, int (*)(void *, > unsigned char *, size_t) f_rng, void * p_rng) Line: 542 > test.elf! ssl_write_client_key_exchange (mbedtls_ssl_context * ssl) > Line: 3362 > test.elf! mbedtls_ssl_handshake_client_step (mbedtls_ssl_context * > ssl) Line: 4015 > test.elf! mbedtls_ssl_handshake_step (mbedtls_ssl_context * ssl) > Line: 9564 > test.elf! mbedtls_ssl_handshake (mbedtls_ssl_context * ssl) Line: 9588 > test.elf! https_do_tls_handshake (struct httpsConfigStr * client) > Line: 419 > test.elf! HttpsStateMachine Line: 366 > test.elf! HttpsTask (void * param) Line: 110 > test.elf! ?? Line: 110 > > MBEDTLS VERSION: mbed TLS 2.18.0 > PLATFORM: embedded microchip SAME70 micro controller. > > I have attached my config.h file. > > What am I doing wrong? > >

6 years, 3 months

1
0
0 0

Fwd: MBEDTLS never exits ecp_double_jac function call

by Sirjee Rooplall

Hi Support, I am using MBEDTLS and most of it works, except I have hit a snag where I am trying to communicate to an https server, and it fails in the ssl->handshake-step (ssl_write_client_key_exchange). My stack trace shows that it gets to the function ecp_double_jac and never exits. It is looping at MBEDTLS_MPI_CHK( mbedtls_mpi_add_mpi( &T, &P->X, &S ) ); MOD_ADD( T );. Stack trace: test.elf! mbedtls_mpi_sub_abs (mbedtls_mpi * X, const mbedtls_mpi * A, const mbedtls_mpi * B) Line: 1287 test.elf! ecp_double_jac (const mbedtls_ecp_group * grp, mbedtls_ecp_point * R, const mbedtls_ecp_point * P) Line: 1310 test.elf! ecp_precompute_comb (const mbedtls_ecp_group * grp, mbedtls_ecp_point * T, const mbedtls_ecp_point * P, unsigned char w, size_t d, mbedtls_ecp_restart_ctx * rs_ctx) Line: 1702 test.elf! ecp_mul_comb (mbedtls_ecp_group * grp, mbedtls_ecp_point * R, const mbedtls_mpi * m, const mbedtls_ecp_point * P, int (*)(void *, unsigned char *, size_t) f_rng, void * p_rng, mbedtls_ecp_restart_ctx * rs_ctx) Line: 2095 test.elf! mbedtls_ecp_mul_restartable (mbedtls_ecp_group * grp, mbedtls_ecp_point * R, const mbedtls_mpi * m, const mbedtls_ecp_point * P, int (*)(void *, unsigned char *, size_t) f_rng, void * p_rng, mbedtls_ecp_restart_ctx * rs_ctx) Line: 2396 test.elf! ecdh_gen_public_restartable (mbedtls_ecp_group * grp, mbedtls_mpi * d, mbedtls_ecp_point * Q, int (*)(void *, unsigned char *, size_t) f_rng, void * p_rng, mbedtls_ecp_restart_ctx * rs_ctx) Line: 84 test.elf! mbedtls_ecdh_gen_public (mbedtls_ecp_group * grp, mbedtls_mpi * d, mbedtls_ecp_point * Q, int (*)(void *, unsigned char *, size_t) f_rng, void * p_rng) Line: 102 test.elf! ecdh_make_public_internal (mbedtls_ecdh_context_mbed * ctx, size_t * olen, int point_format, unsigned char * buf, size_t blen, int (*)(void *, unsigned char *, size_t) f_rng, void * p_rng, int restart_enabled) Line: 514 test.elf! mbedtls_ecdh_make_public (mbedtls_ecdh_context * ctx, size_t * olen, unsigned char * buf, size_t blen, int (*)(void *, unsigned char *, size_t) f_rng, void * p_rng) Line: 542 test.elf! ssl_write_client_key_exchange (mbedtls_ssl_context * ssl) Line: 3362 test.elf! mbedtls_ssl_handshake_client_step (mbedtls_ssl_context * ssl) Line: 4015 test.elf! mbedtls_ssl_handshake_step (mbedtls_ssl_context * ssl) Line: 9564 test.elf! mbedtls_ssl_handshake (mbedtls_ssl_context * ssl) Line: 9588 test.elf! https_do_tls_handshake (struct httpsConfigStr * client) Line: 419 test.elf! HttpsStateMachine Line: 366 test.elf! HttpsTask (void * param) Line: 110 test.elf! ?? Line: 110 MBEDTLS VERSION: mbed TLS 2.18.0 PLATFORM: embedded microchip SAME70 micro controller. I have attached my config.h file. What am I doing wrong?

6 years, 3 months

1
0
0 0

Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code base

by Simon Butcher

Hi All, I appreciate I'm coming very late to this discussion, but I want to make a point and suggestion. The performance of the asymmetric functions is less than ideal, and whilst I think we can all agree that the ECC code should be rewritten at some point to be more competitive, one of the issues with the performance is that the MPI code uses malloc() a lot. There are competing crypto libraries out there that are faster and use a smaller RAM footprint and don't use dynamic memory allocation at all. Our memory allocation code is also kind of slow, and has a primitive and simplistic design of a linked list. These are very similar points to those Manuel was making to remove the feature in the first place - however - short of investing the time in rewriting the asymmetric functions, what we could do as a quick fix is to replace the existing memory code with a block allocation scheme - which should be much faster, speed up the asymmetric functions (in theory), avoid fragmentation, be more deterministic, and a better fit for embedded applications. That could then become the basis of the library for other projects too. I wouldn't mind contributing such a feature, as I had to write something very similar last week anyway. If I do it - will you accept it? Kind regards Simon On 09/04/2020, 12:07, "mbed-tls on behalf of Dan Handley via mbed-tls" <mbed-tls-bounces(a)lists.trustedfirmware.org on behalf of mbed-tls(a)lists.trustedfirmware.org> wrote: Hi There has already been some discussion about a shared C standard library implementation, at least for TF-A and TF-M. So far there's been general agreement that this is a good idea but no actual commitment from anyone to make this happen, since each project is reasonably happy with what they've got. Regarding MBEDTLS_MEMORY_BUFFER_ALLOC_C, TF-A at least enables this so removing this from the codebase would be an issue there. Memory allocators are probably not the core expertise of other Trusted Firmware projects either but it needs to be if they're going to use them! I propose that we move this allocator into a new shared TrustedFirmware.org standard C library project and work with the other projects to ensure it has the correct initial maintainers. This will probably have to be driven by the maintainers of whichever project is most motivated to make this happen. It sounds like that could be Mbed TLS and this will need to be done before any separation of the PSA Crypto implementation. In the short term, as we move C stdlib functionality out of the other projects and into this new project, we will need to support multiple implementations of some functions. Eventually we should move towards a common implementation, and I agree we should look at what security-oriented implementations are already available. I also agree it would make sense for Mbed TLS to not use the toolchain-provided stdlib implementation by default, but only once it uses a default implementation it trusts. Regards Dan. > -----Original Message----- > From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of > Ronald Cron via mbed-tls > Sent: 09 April 2020 08:47 > To: mbed-tls(a)lists.trustedfirmware.org > Subject: Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code > base > > Hi, I think this is related to the more general need for an implementation of > the C standard library for trusted firmware projects. As far as I know TF-A > and TF-M don't use the standard library provided by compilation toolchains. > The rationale is to have complete control over the trusted firmware code. > Currently they both have their own partial implementation of the parts of the > C standard library they need. > > This memory_buffer_alloc.c module in question here is another partial > implementation of the C standard library. Currently TF-A and TF-M don't > use/provide dynamic memory allocations but PSA-FF explicitly mentions that an > SPM implementation may support dynamic memory allocation. Thus it is possible > that TF-M at some point consider providing dynamic memory allocation support. > > All of this to say that a possible way forward may be to remove > memory_buffer_alloc.c from the code base when there is a C standard library > implementation common to trustedfirmware.org projects (is there already a > security oriented open source implementation out there ?). > > In Mbed TLS, it would also make sense to me to, by default, not use C > standard libraries provided by compilation toolchains > (MBEDTLS_PLATFORM_NO_STD_FUNCTIONS defined by default). > > Thanks, Ronald. > > > -----Original Message----- > From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of > Manuel Pegourie-Gonnard via mbed-tls > Sent: 08 April 2020 12:42 > To: mbed-tls(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code > base > > Hi all, > > In this new installment of "let's discuss ideas for Mbed TLS 3.0" [1]: > should we remove memory_buffer_alloc.c from the code base? > > [1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ > > Currently the crypto library includes a module called memory_buffer_alloc.c, > disabled in the default build (config.h option MBEDTLS_MEMORY_BUFFER_ALLOC_C), > which provides implementations of calloc() and free() based on a user- > provided buffer (which could be static or on the stack), suitable for use in > the rest of the crypto, X.509 and TLS libraries as replacements to the > standard functions. > > In addition to providing replacement calloc() and free(), the module also > offers some facilities for measurement and debugging. > > We're considering dropping this module and removing it from the code base > entirely for the following reasons: > > - Memory allocators are not our core area of expertise. > > - This allocator is pretty basic and has a large allocation overhead. For > example for ECC computations, the overhead can be as large as the actual > memory used. > > - Using this allocator also tends to slow things down, so we don't run many > tests with it enabled. > > - In the future when we split between PSA Crypto on one side and Mbed TLS and > X.509 on the other, it's unclear on which side this allocator should fall. > Which can be taken as a sign that it doesn't really belong here. > > On the other hand, we're hesitating for the following reasons: > > - We know from bug reports and questions that some people are using it. > > - Unlike other modules we'd like to drop, there isn't a strong security > incentive to dropping this allocator, it's merely a matter of how we spend > our maintenance resources. > > What do you think? Should we keep maintaining this allocator as part of Mbed > TLS? Should we drop it and focus on our core instead? If you're using this > allocator, why did you pick it over other alternatives? > > Regards, > Manuel. > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > 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 mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls 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 mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

6 years, 3 months

1
0
0 0

Re: [mbed-tls] Development environment: minimum tool versions

by Gilles Peskine

On 25/04/2020 23:44, Steffan Karger via mbed-tls wrote: > Hi, > > I maintain OpenVPN-NL (https://openvpn.fox-it.com), which uses mbedtls > as it's crypto library. > > On 24-04-2020 00:25, Gilles Peskine via mbed-tls wrote: >> 1. Is there any interest in the community for making sure that the build >> keeps (or starts) working on RHEL 6? > Yes, we support RHEL6 until it's retirement (30 November 2020). (…) > It would be nice if it's at least possible to build mbedtls on/for these > platforms until they go out of regular support. Preferably with their > default packages compilers. > All right, thanks for the feedback! I'm not going to promise that we'll add RHEL 6 to our CI. (Of course, in TrustedFirmware, it can happen if someone's motivated enough to contribute it and to keep maintaining it.) But let's at least not knowingly break support for CMake 2.8 yet (or GNU make 3.81 or older GCC and Clang but those are less likely to break). I expect that it will remain possible to build the library *for* ancient systems for a very long time, since all it really needs is a basic C runtime. But the tooling to build the library, or at least to do anything more than building the library (tuning the configuration, building and running tests, etc.) is slowly modernizing (the configuration script and the test building script have required Python 3 for a while now). -- Gilles Peskine Mbed TLS developer

6 years, 3 months

1
0
0 0

ECDH Computation on STM32 platform

by Abhilash Iyer

Hello, I am trying to do the ECDH shared secret computation using the mbedTLS library. I am referring to multiple examples such as ecdh_curve25519.c<https://github.com/ARMmbed/mbedtls/blob/development/programs/pkey/ecdh_curv…> and ecdh_main.c<https://github.com/SiliconLabs/peripheral_examples/blob/master/series2/se/s…>. In my case, in my application firmware, I already have a device _priv key and I receive a server_public key; both generated using a curve ECP_DP_SECP256R1 in the bootloader itself. So in the application firmware, I would like to do generate a shared secret from here on and preserve it for future use. The following is the steps that I do: 1. Create a new client context, entropy context, ctr_drbg context variables. 2. use mbedtls_"respective"_init() to initalize all the three variables 3. Seed a random number using mbedtls_ctr_drbg_seed() function. 4. load the P256 elliptic curve in client context using mbedtls_ecp_group_load() 5. Then use mbedtls_mpi_lset() to set Qp.Z =1 6. Then read the server pub key using mbedtls_mpi_read_binary(&ctx_cli.Qp.X, server_pub, 65); 7. Now the question is: Should I initialize the ctx_cli with my already generated device_priv key using mbedtls_mpi_read_binary(&ctx_cli.d, device_priv_key, 50) ? 8. Then I use mbedtls_ecdh_compute_shared(&ctx_cli.grp, &ctx_cli.z, &ctx_cli.Qp, &ctx_cli.d, mbedtls_ctr_drbg_random, &ctr_drbg); to compute the shared secret in z. Questions: 1. Do I need to generate a keypair for client context using mbedtls_ecdh_gen_public(&ctx_cli.grp, &ctx_cli.d, &ctx_cli.Q, mbedtls_ctr_drbg_random, &ctrDrbg)? And then set pvtkey as device priv key and pub key as service pub key? 2. I see that ctx_cli.Q has two components, Q.x and Q.y. How do I extract these two values from a public key? Do I need to separately initialize them? Please let me know if the flow is correct. In all the examples, they generate a key pair and just update the public key part (Qp.X) of the key. They do not touch the private key part (d) of the key. Please confirm if I can upload my private key directly in my case. Also if my platform is a little endian, is there a recommended step before using mbedtls_mpi_read_binary_le functions? Thanks so much for your help in advance! Thanks, Abhilash From: Abhilash Iyer Sent: Monday, April 27, 2020 11:25 AM To: mbed-tls(a)lists.trustedfirmware.org Subject: Hello, I am trying to do the ECDH shared secret computation using the mbedTLS library. I am referring to multiple examples such as ecdh_curve25519.c<https://github.com/ARMmbed/mbedtls/blob/development/programs/pkey/ecdh_curv…> and ecdh_main.c<https://github.com/SiliconLabs/peripheral_examples/blob/master/series2/se/s…>. In my case, in my application firmware, I already have a device _priv key and I receive a server_public key; both generated using a curve ECP_DP_SECP256R1 in the bootloader itself. So in the application firmware, I would like to do generate a shared secret from here on and preserve it for future use. The following is the steps that I do: 1. Create a new client context, entropy context, ctr_drbg context variables. 2. use mbedtls_"respective"_init() to initalize all the three variables 3. Seed a random number using mbedtls_ctr_drbg_seed() function. 4. load the P256 elliptic curve in client context using mbedtls_ecp_group_load() 5. Then use mbedtls_mpi_lset() to set Qp.Z =1 6. Then read the server pub key using mbedtls_mpi_read_binary(&ctx_cli.Qp.X, server_pub, 65); 7. Now the question is: Should I initialize the ctx_cli with my already generated device_priv key using mbedtls_mpi_read_binary(&ctx_cli.d, device_priv_key, 50) ? 8. Then I use mbedtls_ecdh_compute_shared(&ctx_cli.grp, &ctx_cli.z, &ctx_cli.Qp, &ctx_cli.d, mbedtls_ctr_drbg_random, &ctr_drbg); to compute the shared secret in z. Questions: 1. Do I need to generate a keypair for client context using mbedtls_ecdh_gen_public(&ctx_cli.grp, &ctx_cli.d, &ctx_cli.Q, mbedtls_ctr_drbg_random, &ctrDrbg)? And then set pvtkey as device priv key and pub key as service pub key? 2. I see that ctx_cli.Q has two components, Q.x and Q.y. How do I extract these two values from a public key? Do I need to separately initialize them? Please let me know if the flow is correct. In all the examples, they generate a key pair and just update the public key part (Qp.X) of the key. They do not touch the private key part (d) of the key. Please confirm if I can upload my private key directly in my case. Also if my platform is a little endian, is there a recommended step before using mbedtls_mpi_read_binary_le functions? Thanks so much for your help in advance! Thanks, Abhilash Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

6 years, 3 months

1
0
0 0

Re: [mbed-tls] Random Number Generator module in mbed TLS

by ROSHINI DEVI

Perfect! Thanks everyone for your assistance. On Tue, Apr 28, 2020 at 1:48 PM Janos Follath via mbed-tls < mbed-tls(a)lists.trustedfirmware.org> wrote: > Hi, > > > > Hanno described perfectly how it works and I just would like to add a > single remark. You mentioned that some of your platforms don’t have a > hardware entropy source. In cases like that, depending on your threat model > you might need to use the MBEDTLS_ENTROPY_NV_SEED feature to achieve > security. > > > > (This uses a stored secret value as a seed and on embedded systems without > a hardware entropy source it is more secure against a remote adversary than > trying to collect the entropy from the environment. On systems like that > NV_SEED can have an edge against physical attackers – compared to > attempting to collect entropy from the environment – if the seed is stored > in secure storage/internal flash.) > > > > Regards, > > Janos > > > > *From: *mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf > of Hanno Becker via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> > *Reply to: *Hanno Becker <Hanno.Becker(a)arm.com> > *Date: *Tuesday, 28 April 2020 at 07:55 > *To: *"mbed-tls(a)lists.trustedfirmware.org" < > mbed-tls(a)lists.trustedfirmware.org>, ROSHINI DEVI <roshinilachi(a)gmail.com> > *Subject: *Re: [mbed-tls] Random Number Generator module in mbed TLS > > > > Hi, > > > > Mbed TLS establishes variable-length access to random data in a three step > fashion: > > > > 1) At the bottommost layer, there is a variable number of *entropy > sources *external to the library. > > Such sources are supposed to provide some true randomness, though the > exact amount of > > entropy they contain isn't yet specified (at least to my knowledge). > > > > 2) Mbed TLS' entropy module mixes those entropy sources into a single > source of randomness. > > In contrast to the entropy sources themselves, the idea here is that, > ideally, the data obtained > > from the entropy module has full entropy. This is achieved by (a) > accumulating random data > > from available entropy sources and depending on the amount of entropy each > of them offers, > > and (b) 'mixing' them by a application of hash functions. > > > > 3) Based on true randomness, Mbed TLS' provides two implementations of > pseudo random > > number generators: CTR-DRBG and HMAC-DRBG. Those build on top of an > entropy context > > and expand the underlying randomness as standardized in NIST SP 800-90. > > > > Applications should use the PRNGs from step 3) as their actual source of > randomness, > > and not directly hook into the underlying TRNGs. > > > > Take a look at the example programs such as `ssl_client2` or `ssl_server2` > to see how this > > works practically. Also see > https://tls.mbed.org/kb/how-to/add-a-random-generator. > > > > Now specifically to your question: You should register your STM32 hardware > entropy > > as an entropy source via `mbedtls_entropy_add_source()` but not (need) to > change > > anything else in your code. In particular, steps 2) and 3) above are > entirely independent > > of the exact source of true randomness. > > > > Hope this helps, > > > > Hanno > > > ------------------------------ > > *From:* mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf > of ROSHINI DEVI via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> > *Sent:* Tuesday, April 28, 2020 6:06 AM > *To:* mbed-tls(a)lists.trustedfirmware.org < > mbed-tls(a)lists.trustedfirmware.org> > *Subject:* Re: [mbed-tls] Random Number Generator module in mbed TLS > > > > Hello, > > > > Can anyone confirm this? Its urgent. > > > > Thanks > > > > On Fri, Apr 17, 2020 at 4:50 PM ROSHINI DEVI <roshinilachi(a)gmail.com> > wrote: > > Hello, > > > > Is there any random number library available in mbedTLS? > > Right now, I am using hardware entropy in STM32 boards. > > If hardware platform changes and if there is no hardware entropy present, > then again we need to redefine the API. > > > > Thanks > > 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 mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls >

6 years, 3 months

1
0
0 0

Re: [mbed-tls] Random Number Generator module in mbed TLS

by Janos Follath

Hi, Hanno described perfectly how it works and I just would like to add a single remark. You mentioned that some of your platforms don’t have a hardware entropy source. In cases like that, depending on your threat model you might need to use the MBEDTLS_ENTROPY_NV_SEED feature to achieve security. (This uses a stored secret value as a seed and on embedded systems without a hardware entropy source it is more secure against a remote adversary than trying to collect the entropy from the environment. On systems like that NV_SEED can have an edge against physical attackers – compared to attempting to collect entropy from the environment – if the seed is stored in secure storage/internal flash.) Regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Hanno Becker via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Reply to: Hanno Becker <Hanno.Becker(a)arm.com> Date: Tuesday, 28 April 2020 at 07:55 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org>, ROSHINI DEVI <roshinilachi(a)gmail.com> Subject: Re: [mbed-tls] Random Number Generator module in mbed TLS Hi, Mbed TLS establishes variable-length access to random data in a three step fashion: 1) At the bottommost layer, there is a variable number of entropy sources external to the library. Such sources are supposed to provide some true randomness, though the exact amount of entropy they contain isn't yet specified (at least to my knowledge). 2) Mbed TLS' entropy module mixes those entropy sources into a single source of randomness. In contrast to the entropy sources themselves, the idea here is that, ideally, the data obtained from the entropy module has full entropy. This is achieved by (a) accumulating random data from available entropy sources and depending on the amount of entropy each of them offers, and (b) 'mixing' them by a application of hash functions. 3) Based on true randomness, Mbed TLS' provides two implementations of pseudo random number generators: CTR-DRBG and HMAC-DRBG. Those build on top of an entropy context and expand the underlying randomness as standardized in NIST SP 800-90. Applications should use the PRNGs from step 3) as their actual source of randomness, and not directly hook into the underlying TRNGs. Take a look at the example programs such as `ssl_client2` or `ssl_server2` to see how this works practically. Also see https://tls.mbed.org/kb/how-to/add-a-random-generator. Now specifically to your question: You should register your STM32 hardware entropy as an entropy source via `mbedtls_entropy_add_source()` but not (need) to change anything else in your code. In particular, steps 2) and 3) above are entirely independent of the exact source of true randomness. Hope this helps, Hanno ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of ROSHINI DEVI via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: Tuesday, April 28, 2020 6:06 AM To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: Re: [mbed-tls] Random Number Generator module in mbed TLS Hello, Can anyone confirm this? Its urgent. Thanks On Fri, Apr 17, 2020 at 4:50 PM ROSHINI DEVI <roshinilachi(a)gmail.com<mailto:roshinilachi@gmail.com>> wrote: Hello, Is there any random number library available in mbedTLS? Right now, I am using hardware entropy in STM32 boards. If hardware platform changes and if there is no hardware entropy present, then again we need to redefine the API. Thanks 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.

6 years, 3 months

1
0
0 0

Re: [mbed-tls] Random Number Generator module in mbed TLS

by Hanno Becker

Hi, Mbed TLS establishes variable-length access to random data in a three step fashion: 1) At the bottommost layer, there is a variable number of entropy sources external to the library. Such sources are supposed to provide some true randomness, though the exact amount of entropy they contain isn't yet specified (at least to my knowledge). 2) Mbed TLS' entropy module mixes those entropy sources into a single source of randomness. In contrast to the entropy sources themselves, the idea here is that, ideally, the data obtained from the entropy module has full entropy. This is achieved by (a) accumulating random data from available entropy sources and depending on the amount of entropy each of them offers, and (b) 'mixing' them by a application of hash functions. 3) Based on true randomness, Mbed TLS' provides two implementations of pseudo random number generators: CTR-DRBG and HMAC-DRBG. Those build on top of an entropy context and expand the underlying randomness as standardized in NIST SP 800-90. Applications should use the PRNGs from step 3) as their actual source of randomness, and not directly hook into the underlying TRNGs. Take a look at the example programs such as `ssl_client2` or `ssl_server2` to see how this works practically. Also see https://tls.mbed.org/kb/how-to/add-a-random-generator. Now specifically to your question: You should register your STM32 hardware entropy as an entropy source via `mbedtls_entropy_add_source()` but not (need) to change anything else in your code. In particular, steps 2) and 3) above are entirely independent of the exact source of true randomness. Hope this helps, Hanno ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of ROSHINI DEVI via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: Tuesday, April 28, 2020 6:06 AM To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: Re: [mbed-tls] Random Number Generator module in mbed TLS Hello, Can anyone confirm this? Its urgent. Thanks On Fri, Apr 17, 2020 at 4:50 PM ROSHINI DEVI <roshinilachi(a)gmail.com<mailto:roshinilachi@gmail.com>> wrote: Hello, Is there any random number library available in mbedTLS? Right now, I am using hardware entropy in STM32 boards. If hardware platform changes and if there is no hardware entropy present, then again we need to redefine the API. Thanks 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.

6 years, 3 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

mbed-tls