- mbed-tls - lists.trustedfirmware.org

Re: [mbed-tls] 3.0 plans - move timing.c out of the library

by Manuel Pegourie-Gonnard

Hi all, So personally I'm quite strongly inclined to remove timing.c from the library, and move most of its content elsewhere, with one possible exception: > - mbedtls_timing_set_delay() and mbedtls_timing_get_delay() are an example > implementation (only for Unix and Windows) of timer callbacks for DTLS, only > used in programs/ssl/*.c Since timer callbacks are a hard requirement for using DTLS, and it seems quite desirable to be able to support DTLS out of the box at least on some platforms, I was thinking this pair of function (and the associated context type) could be kept in the library, in a new module that would be called something like ssl_dtls_timer.c. This would be somewhat similar to ssl_cookies.c, ssl_tickets.c and ssl_cache.c: they all provide implementations of callbacks that can be used with the main SSL/(D)TLS module, but users are obviously free to compile them out and use their own implementation if the one we provide does not meet their needs. As it happens, all three of these support modules work best if MBEDTLS_HAVE_TIME is defined, but can work without it. For the new ssl_dtls_timer.c I'm suggesting, the situation would be different: the module could have a hard dependency on MBEDTLS_HAVE_TIME, but work better on selected platforms (say, C11, POSIX and Windows) where we know how to access sub-second timing information. (Or alternatively, have a hard dependency on C11-or-Posix-or-Windows.) For the record, mbedtls_ssl_conf_handshake_timeout() accepts timeout values in milliseconds, but recommended values for use over the general internet start at 1 second: https://tools.ietf.org/html/rfc6347#section-4.2.4.1 So it might make sense to provide this module even when we only have second resolution - we'd just have to work out how the timer function would behave when passed sub-second values. (My first thought it rounding up to the next second would be quite OK.) What do you'all think? Personnally, I don't have a strong opinion between the three following options, though I have a slight preference for the first one: 1. Provide ssl_dtls_timer.c in the library with hard dep on HAVE_TIME and enhanced features with C11/Posix/Windows. 2. Provide ssl_dtls_timer.c in the library with hard dep on C11/Posix/Windows. 3. Move it all out of the library and let the thing live somewhere under programs/ as it's only used by example/testing programs. Note though that we could also choose to go with option 3 for Mbed TLS 3.0, see how it goes, and later switch to option 2 or 1 if we want, as adding modules can be done at any time. (In the same vein, we could start with 2 and switch to 1 at any time as well.) Regards, Manuel.

5 years, 7 months

1
0
0 0

Re: [mbed-tls] 3.0 plans - move timing.c out of the library

by Manuel Pegourie-Gonnard

Hi Torsten, [I'm assuming didn't mean to reply on the list and not just to me, so I'm replying on the list.] > On 20/04/2020 11:51, Manuel Pegourie-Gonnard via mbed-tls wrote: >> For reference, this module includes the following functions, which are used >> in the following places: >> >> - mbedtls_timing_hardclock() implements cycle counting (on selected >> architectures, not including M-class), used only in >> programs/test/benchmark.c > > I used mbedtls_timing_hardclock() for my own benchmarking experiments on > Linux and Windows, but couldn't get it to run on the target machine. So > I've use my own ms counter instead. So, it could be easily removed as > part of the library. > Good to know, thanks for sharing this data point. > Question: How do you want to do the benchmarking instead? With the same > code, but outside the library? > Yes, I was thinking that the functions that are only used in benchmark.c could be defined in benchmark.c, and the functions that are only used in udp_proxy.c could be defined in udp_proxy.c. (Or actually for the latter, we might want to start using them in ssl_client2.c and ssl_server2.c as well, as including millisecond timestamps in the debug output would be usefull to debug some issues. In that case, we'll probably put those functions in a new file, used by udp_proxy, ssl_client2 and ssl_server2 (just like query_config.c is currently used by ssl_client2, ssl_server2 and query_compile_time_config).) Regards, Manuel.

5 years, 7 months

1
0
0 0

Re: [mbed-tls] Some thoughts towards mbed TLS 3.0

by Manuel Pegourie-Gonnard

Hi Torsten, > this will be a long mail. Sorry for that. > On the contrary, thank you so much for this extensive and well though-out feedback, that's very helpful! I'll try to complement Gilles's reply, and skip the points he already answered unless I have something to add, as I'm generally in full agreement with what he wrote. > 3. For certification and evaluation purposes I need some test vectors > for each crypto function on target. While I know about the > comprehensive self-test program I'm now talking about built-in > functions like mbedtls_sha512_self_test(), etc to be enabled with > #define MBEDTLS_SELF_TEST. > > These self-tests are very different in coverage. For SHA-384 and > SHA-512 they are fine, for HMAC-SHA-384 and HMAC-SHA-512 I couldn't > find any as well as for HKDF-HMAC-SHA-256 (in RFC 5869) or > HKDF-HMAC-SHA-384/512 (official test vectors difficult to find). > AES-CTR and AES-XTS are only tested with key length 128 bit, not with > 256 bit. AES-CCM is not tested with 256 bit and even for 128 bit, > the test vector from the standard NIST SP 800-38C with long > additional data is not used. > The builtin self-test for GCM is the best I've seen with mbedtls: > all three key lengths are tested as well as the IUF-interface and > the comfort function. Bravo! > Indeed so far we don't have clear guidelines on self-test functions, and we should try to have more consistency here. Since this is incremental, backwards-compatible improvements, it can be done at any time (unlike some API improvements that can only be done when preparing major versions). Contributions in this area are certainly welcome! > 7. While at Elliptic Curve Cryptography: I assume that some of you > know that projectives coordinates as outer interface to ECC are > dangerous, see David Naccache, Nigel P. Smart, Jacques Stern: > Projective Coordinates Leak, Eurocrypt 2004, pp. 257–267. Yes, and as it happens this was revisited recently by researchers, and brought back to our attention: https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advi… > you have Jacobian coordinates, i.e. projective coordinates, as outer > interface. In the comment, its is noted that only the affine part is > used, but can this be assured? In all circumstances? > In practice, I'm pretty confident this is the case, because both ecp_normalize_jac() and ecp_normalize_mxz() set Z to 1, these functions are always called before returning data, and if we forgot to call those functions, we'd get incorrect X and Y coordinates and fail unit test and interop tests. But as a matter of principle, I agree that exposing Jacobian coordinates in the API was a poor decision. Fortunately, we already intended to start phasing out the existing ECP interface in 3.0 (to which extend exactly is still to be discussed), and in the future is should be fully removed in favour of the PSA Crypto API, which doesn't have this problem. > 8. In my personal opinion the definition > [...] > mbedtls_ecp_keypair; > > is dangerous. Why not differentiate between private and public key > and domain parameters? I agree, and I think it's a generally accepted opinion in the crypto implementation community that private and public keys should be clearly distinguished from one another, for example by using distinct types (in typed languages). This is by the way a long-standing problem that existed in the RSA module from the start, and when ECC was added it followed a similar pattern. Again, I think the transition of the PSA Crypto API is going to be the answer here, as it will provide much cleaner key management. > 9. Regarding ECC examples: I found it very difficult that there isn't > a single example with known test vectors as in the relevant crypto > standards, i.e. FIPS 186-4 and ANSI X9.62-2005, with raw public > keys. What I mean are (defined) curves, public key value Q=(Qx,Qy) > and known signature values r and s. In the example ecdsa.c you > generate your own key pair and read/write the signature in > serialized form. In the example programs/pkey/pk_sign.c and > pk_verify.c you use a higher interface pk.h and keys in PEM format. > > So, it took me a while for a program to verify (all) known answer > tests in the standards (old standards as ANSI X9.62 1998 have more > detailed known answer tests). One needs this interface with raw > public keys for example for CAVP tests, see The FIPS 186-4 Elliptic > Curve Digital Signature Algorithm Validation System (ECDSA2VS). > > 11. In the moment, there is no single known answer tests for ECDSA > (which could be activated with #define MBEDTLS_SELF_TEST). I > wouldn't say that you need an example for every curve and hash > combination, as it is done in ECDSA2VS CAVP, but one example for > one of the NIST curves and one for Curve25519 and - if I have a > wish free - one for Brainpool would be fine. And this would solve > #9 above. > I might be misunderstanding, but isn't the function ecdsa_prim_test_vectors() in tests/suites/test_suite_ecdsa.function close to what you're looking for? I mean, except for the fact that it's not in the self-test function, and that it's using data from RFCs rather than from NIST or ANSI? But I agree this is a bit messy and could be made cleaner. Also, if you ever feel like contributing your dream self-test function for ECDSA as PR, this will be a very welcome contribution! > 13. Feature request: Since it was irrelevant for my task (only > verification, no generation) I didn't have a detailed look a your > ECC side-channel countermeasures. But obviously you use the same > protected code for scalar multiplication in verify and sign, > right? Wouldn't it be possible to use Shamir's trick in > verification with fast unprotected multi-scalar multiplication. In > the moment, mbedtls_ecdsa_verify is a factor 4-5 slower than > mbedtls_ecdsa_sign, while OpenSSLs verify is faster than sign. > Yes, this was done to save both on code size and developer time, but I agree it's suboptimal for performance. As Gilles wrote, as a general rule we tend to favour code size and security/maintainability over performance, but in that instance if we provide an option for a verify-only ECDSA build (which I agree we should), then we're likely to reach smaller code size by having a standalone unprotected implementation of multi-scalar multiplication, so that would probably be a great option: better performance _and_ smaller code. Unfortunately we're already quite busy with other things, so this kind of optimisation will probably have to wait for a bit more, but we're taking good note of the suggestion and will try to implement it in the future. Again, thanks for this comprehensive and useful feedback. Regards, Manuel.

5 years, 7 months

1
0
0 0

Re: [mbed-tls] 3.0 plans - move timing.c out of the library

by Torsten Schuetze

On 20/04/2020 11:51, Manuel Pegourie-Gonnard via mbed-tls wrote: > [ Context: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ ] > > Currently the crypto library includes a module called timing.c, enabled by > default in config.h (but disabled by config.py baremetal), containing various > functions related to timing (not to be confused with the time abstration > present in the platorm module). > > In Mbed TLS 3.0, as part of our effort to clean up and minimize our API, > we're considering removing (parts of) this module from the library, and > moving its parts to a variety of other places, such as example programs (or > a library/file shared by them, like the current query_config mechanism). > > For reference, this module includes the following functions, which are used in > the following places: > > - mbedtls_timing_hardclock() implements cycle counting (on selected > architectures, not including M-class), used only in > programs/test/benchmark.c I used mbedtls_timing_hardclock() for my own benchmarking experiments on Linux and Windows, but couldn't get it to run on the target machine. So I've use my own ms counter instead. So, it could be easily removed as part of the library. Question: How do you want to do the benchmarking instead? With the same code, but outside the library? Torsten

5 years, 7 months

1
0
0 0

3.0 plans - move net.c out of the library

by Manuel Pegourie-Gonnard

Hi all, [ Context: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ ] Currently the SSL/TLS library includes a module called net_sockets.c (formerly net.c), enabled by default in config.h (but disabled by config.py baremetal), that contains some networking functions based on POSIX or Windows sockets, including functions suitable for use as I/O callbacks with our SSL/TLS modules. Those functions are used only in example/testing programs, but nowhere in the library itself. In Mbed TLS 3.0, as part of our effort to clean up and minimize our API, we're considering removing (parts of) this module from the library, and moving its parts to a variety of other places, such as example programs (or a library/file shared by them, like the current query_config mechanism). Reasons for removing this module from the library include: - overall the module is less portable and perhaps of lesser quality than the rest of the library - it's currently entirely untested on Windows (despite being very platform-specific) - there are often confusions about whether the module is meant to be a general-purpose networking library, or just provide basic support for our example and test, as well a simple prototypes - it's not our core area of expertise, let's do one thing and to it well Reasons for keeping (parts of) it in the library include: - having mbedtls_net_recv{,_timeout}() and mbedtls_net_send() available right in the library makes it easier to test and develop prototype - this module is listed as a component in our high-level design document [2], so perhaps removing it from the library can be seen as a bigger change? [2]: https://tls.mbed.org/high-level-design What do you think? Should we remove the entire module from the library, keep it all, or just keep some parts? In that case, which parts and where? Regards, Manuel.

5 years, 7 months

1
0
0 0

3.0 plans - move timing.c out of the library

by Manuel Pegourie-Gonnard

[ Context: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ ] Currently the crypto library includes a module called timing.c, enabled by default in config.h (but disabled by config.py baremetal), containing various functions related to timing (not to be confused with the time abstration present in the platorm module). In Mbed TLS 3.0, as part of our effort to clean up and minimize our API, we're considering removing (parts of) this module from the library, and moving its parts to a variety of other places, such as example programs (or a library/file shared by them, like the current query_config mechanism). For reference, this module includes the following functions, which are used in the following places: - mbedtls_timing_hardclock() implements cycle counting (on selected architectures, not including M-class), used only in programs/test/benchmark.c - mbedtls_timing_get_timer() is a millisecond counter (only for Unix and Windows), used only in programs/test/udp_proxy.c - mbedtls_set_alarm() is an abstraction of alarm() (only for Unix and Windows), used only in programs/test/benchmark.c - mbedtls_timing_set_delay() and mbedtls_timing_get_delay() are an example implementation (only for Unix and Windows) of timer callbacks for DTLS, only used in programs/ssl/*.c Reasons for removing this module from the library include: - overall the module is less portable and of lesser quality than the rest of the library - it's also very hard to test and we've lost a lot of time and energy to that, with very limited success - it doesn't really belong in libmbedcrypto - it's not our core area of expertise, let's do one thing and to it well Reasons for keeping (parts of) it in the library include: - for mbedtls_timing_set_delay() and mbedtls_timing_get_delay(): they're convenient to have for DTLS examples and prototyping, we could keep them in some place in libmbedtls (not libmbedcrypto). What do you think? Should we remove the entire module from the library, or keep some parts? In that case, which parts and where should they live? Regards, Manuel.

5 years, 7 months

1
0
0 0

3.0 plans - move certs.c out of the library

by Manuel Pegourie-Gonnard

Hi all, In this new installment of "let's discuss ideas for Mbed TLS 3.0" [1]: should we move certs.c out of the library? [1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ Currently the X.509 library includes test certificates and keys, which are enabled by default in config.h - `MBEDTLS_CERTS_C`. These are used in the following places: - in library/x509.c in mbedtls_x509_self_test() - in tests/suites/test_suite_ssl.function - in programs/fuzz and programs/ssl In Mbed TLS 3.0, as part of our effort to clean up and minimize our API, we'd like to remove certs.h and the certificates it contains from the library (except perhaps one static cert for mbedtls_x509_self_test()). Tests and example programs that need built-in certificates could still get them using any mechanism, included a file certs.c similar to the current one - but this file would no longer live in library or be included when building libmbedx509. Reasons include: - Including test certificates and keys in the library provides little value, as users will want to use their own certificates and keys anyway. - Shipping private keys as part of the library is bad practice, even under the `mbedtls_test_` sub-namespace. There's a slight risk that some users could use them for prototyping and then inadvertently keep using unsafe private keys in production. If you disagree or have concerns, please speak up! Also, if want to suggest ideas for where the replacement to library/certs.c should live or how it could be maintained, now's a good time as well! Regards, Manuel.

5 years, 7 months

1
0
0 0

Session resumption + PSKs in Mbed TLS 3.X

by Hanno Becker

Hi all, I would like to bring up the following: (How) Shall the APIs for PSKs and TLS session resumption be modified in Mbed TLS 3.0? The motivation for this question is the consolidation of PSKs, ticket-based resumption and session-id-based resumption in TLS 1.3. Now, while there will be no TLS 1.3 support in Mbed TLS 3.0 as it stands, I think it would be beneficial to make the API amenable to TLS 1.3 as much as possible already now. Finding the right API here is non-trivial, and I'll describe first how the current API works and how TLS 1.2 and 1.3 differ, before making suggestions on how the Mbed TLS 3 API might look like. The mail is therefore quite long, but I hope you'll bear with me. # Session Resumption in Mbed TLS 2.X Recall how resumption works in Mbed TLS 2.X on the client: 1. Establish a connection as usual 2. Store established session for later re-use `mbedtls_ssl_session_save()` saves connection parameters relevant for session resumption in an instance of `mbedtls_ssl_session`. Optional: 2.1: Serialize session for offline storage 2.2: Deserialize session 3. Loading a stored session `mbedtls_ssl_session_load()` is called on the stored session after initialization and before running the handshake via `mbedtls_ssl_handshake()`. 4. Connect using stored session Run `mbedtls_ssl_handshake()` as usual. To my knowledge, the following is transparent to the user: * The means by which resumption is achieved, which can be either id- or ticket-based. * Whether the session was resumed or not - there is a silent fallback to a full handshake when session resumption is rejected by the server. On the server, ticket- and id-based resumption are configured independently as follows: - ID-based resumption is controlled via `mbedtls_ssl_conf_session_cache()` - Ticket-based resumption is controlled via `mbedtls_ssl_conf_session_tickets_cb()`. # PSKs in Mbed TLS 2.X Coming to PSKs: First, recall that, under the hood, resumed connections establish a master secret purely on the basis of a previous master secret, without resorting to asymmetric crypto. The same is true for PSK-based connections, and this observation is embodied in TLS 1.3 which, as mentioned, consolidates resumption and PSKs. In TLS 1.2, though, PSKs and session resumption are different, and consequently Mbed TLS handles them through a separate API `mbedtls_ssl_conf_psk()`, which takes the PSK identifier and the PSK itself. Side-question: Should this apply to the SSL configuration or the SSL context? It seems to me that somebody might want to run multiple PSK-based connections with different PSKs, but same configuration otherwise. At the moment, this would require a configuration per connection. Maybe this decision of what belongs at the level of the config could be thoroughly discussed independently? # PSKs in TLS 1.3 In TLS 1.3, all kinds of resumptions are hanlded ander the umbrella of PSKs: The client offers PSK identities in its ClientHello, the server picks one or leaves it, and the master secret for the connection is derived from the PSK associated with the PSK identity. Underlying this is some form of translation `PSK-Identity -> PSK` on the server which allows to derive the PSK from the PSK identity. How this mapping is realized is entirely implementation-specific, but it can take at least the following forms, giving back all forms of session resumption: - 'PSK Identity -> PSK' via database lookup: This subsumes classical PSKs and ID-based resumption, since the data necessary to resume a session is stored on the server. - 'PSK Identity -> PSK' via AEAD: The PSK can be encoded in the PSK identity itself by using some authenticated encryption of the PSK as the PSK identity, the key for which resides on the server. This subsumes Ticket-based resumption. There are the following noteworthy differences, though: 1. In TLS 1.2, the server provides a 'PSK identity hint' and the client picks a particular PSK identity. In TLS 1.3, the client offers a _list_ of PSKs, and the server picks one or none. 2. In TLS 1.2, the server can issue only a single session ticket. In TLS 1.3, the server can issue as many session tickets as he wishes, and the client can use any of those for later session resumption. This has the following consequences for the API: 1. The PSK-configuration API must allow the configuration of multiple PSKs on the client. 2. There must be a means to export more than one session ticket for later resumption. # API considerations for Mbed TLS 3.X ## Part 1: Load/Save API In essence, keep the flow of `mbedtls_ssl_session_load/save()`, but make the following adjustments. Whether the target structure remains `mbedtls_ssl_session` and how it looks like internally isn't relevant at this point and is up to discussion. 1. It must be possible 'save' a session multiple times, which in TLS 1.3 amounts to exporting the tickets issued by the server one-by-one. This can be realized in a variety of ways, for example: - Allow calling `mbedtls_ssl_session_save()` multiple times, and modify its semantics from the idempotent nature of Mbed TLS 2.X to iterating through the available tickets, and returning an error when no more tickets are available. This has the benefit that it likely requires no code change for users migrating from Mbed TLS 2.X, since a change is needed only when an application stores a single session multiple times, which could be done by calling `mbedtls_ssl_session_save()` multiple times before, while now one would need to call it once and manually replicate the obtained session structure. On the negative side, this wastes memory for applications not interested in session resumption, or those that only need a single ticket. We don't want the server to be able to flood the client with arbitrarily many tickets. - Allow registering a callback that's triggered whenever a new ticket arrives. The drawback of this is that it is larger deviation from the Mbed TLS 2.X API. On the positive side, applications that don't need tickets, or only need a limited number of such, can simply drop further tickets and thereby prevent allocating RAM for them. 2. It must be possible to 'load' multiple sessions, meaning that the client should offer any of them to the server for resumption. ## Part 2: Consolidation with PSK Make it possible to setup an `mbedtls_ssl_session` (or whatever it will be called) structure manually from an externally PSK provisioned PSK, and allow loading this session for resumption as above, via one of potentially many calls to `mbedtls_ssl_session_load()`. There are multiple variants to this, for example: 1. Make `mbedtls_ssl_session` transparent so users can build it manually by filling the respective fields. 2. Provide a helper API to build a session from a PSK. The old API `mbedtls_ssl_conf_psk()` can then be _derived_ from this for convenience, building a session from the provided PSK and loading it, in a single API. Before going into further details and making the mail even longer: What do you think of this approach? Do you see alternatives? Best, Hanno 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.

5 years, 8 months

1
0
0 0

Re: [mbed-tls] Some thoughts towards mbed TLS 3.0

by Gilles Peskine

Wow! First, thanks for this extensive feedback! That's very helpful, and appreciated. I'm going to reply to a few points. On a general note, you can see headlines for the main topics we're currently planning to work on in the Mbed TLS roadmap at https://developer.trustedfirmware.org/w/mbed-tls/roadmap/ . Please note that everything I write is based on current plans, which may change through the TrustedFirmware planning process or if real life shows that a current plan is not doable. Over time, we're transitioning the API for the crypto part of the library from the current mbedtls_xxx functions to psa_xxx, which have a somewhat different philosophy: less exposure of internals, more protection against misuse, no reliance on malloc. Mbed TLS 3.0 will start the transition. On 14/04/2020 21:10, Torsten Schuetze via mbed-tls wrote 1. I really missed an Initialize, Update, Finalize (IUF) interface for CCM. For GCM, we have mbedtls_gcm_init(), mbedtls_gcm_setkey(), mbedtls_gcm_starts(), mbedtls_gcm_update() iterated, mbedtls_gcm_finish(), mbedtls_gcm_free() or the comfort functions mbedtls_gcm_crypt_and_tag() and mbedtls_gcm_auth_decrypt(). For CCM, only mbedtls_ccm_init(), mbedtls_ccm_setkey(), mbedtls_ccm_encrypt_and_tag() or mbedtls_ccm_auth_decrypt() and mbedtls_ccm_free(). With this interface it was only possible to encrypt and tag 128 kByte on my target system, while with GCM I could encrypt much larger files. see Github issue #662 and my comment there In Mbed TLS 3.0, mbedtls_ccm_xxx() will not be a public interface anymore. We are planning to add support for multipart CCM in the psa_aead_xxx() interface (the prototypes are already in psa/crypto.h but their implementation is planned for some time in the next few months). We are not currently planning to add support for multipart CCM through mbedtls_cipher_xxx(), which in Mbed TLS 3 will be legacy functions. However, we would probably accept such support if it was contributed externally. 2. The next step, of course, is to integrate this into the higher mbedtls_cipher layer. Regarding higher, abstract layers: I often didn't understand which interface I was supposed to use. In general, I like to use the lowest available interface, for example, #include "mbedtls/sha512.h" when I want to use sha512. However, if I need HMAC-SHA-512 or HKDF-HMAC-SHA-512 then I have to use the interface in md.h. For hash functions this is fine. Almost all hash functions are supported via md.h. (I missed SHA-512/256 which is sometimes preferable to SHA-256 on 64bit systems). But with cipher.h, I can only access Chacha20Poly1305 and AES-GCM, not AES-CCM. In Mbed TLS 3, there will generally be a single public layer. Exposing lower layers helps with code size on resource-constrained devices, but it also has downsides, including locking down the APIs. 4. That I couldn't configure AES-256 only, i.e. without AES-128 and AES-192, was to be expected (and the code overhead is not that much). But in modern modes of operations nobody needs AES decryption, only the forward direction. Sometimes modern publications as Schwabe/Stoffelen "All the AES you need on Cortex-M3 and M4" provide only the forward direction. So, it would be fine if one could configure an AES (ECB) encryption only without decryption. Of course, this is only possible if we don't use CBC mode, etc. This wouldn't only save the AES decryption code but also the rather large T-tables for decryption. For information, there is a branch of Mbed TLS called "baremetal", forked from Mbed TLS 2.16, which you can find on GitHub: https://github.com/ARMmbed/mbedtls/blob/baremetal . This branch is optimized for small code size, sometimes at the expense of speed and often at the expense of features. It has build options MBEDTLS_AES_ONLY_ENCRYPT and MBEDTLS_AES_ONLY_128_BIT_KEY_LENGTH. However I would not recommend using it in production because Arm (who still maintain this branch even after Mbed TLS itself has moved to TrustedFirmware) does not make any promise of stability. A feature that you rely on may be removed without notice. I mention this branch because eventually, we do plan to port the improvements that don't sacrifice features to the Mbed TLS development branch. I can't give a timeline for this however. With the current Mbed TLS, if you don't use CBC, I think you can save some code in aes.o by defining MBEDTLS_AES_DECRYPT_ALT and MBEDTLS_AES_SETKEY_DEC_ALT and providing functions mbedtls_aes_setkey_dec() and mbedtls_internal_aes_decrypt() that do nothing. 5. Regarding AES or better the AES context-type definition [snip] 6. In general, the contexts of mbedTLS are rather full of implementation specific details. Most extreme is mbedtls_ecp_group in ecp.h. Wouldn't it be clearer if one separates the standard things (domain parameters in this case) from implementation specific details? As a general design principle, context types in Mbed TLS 3 will be opaque. This will let us, for example, redesign mbedtls_aes_context and mbedtls_cipher_context. 9. Regarding ECC examples: I found it very difficult that there isn't a single example with known test vectors as in the relevant crypto standards, i.e. FIPS 186-4 and ANSI X9.62-2005, with raw public keys. What I mean are (defined) curves, public key value Q=(Qx,Qy) and known signature values r and s. In the example ecdsa.c you generate your own key pair and read/write the signature in serialized form. In the example programs/pkey/pk_sign.c and pk_verify.c you use a higher interface pk.h and keys in PEM format. So, it took me a while for a program to verify (all) known answer tests in the standards (old standards as ANSI X9.62 1998 have more detailed known answer tests). One needs this interface with raw public keys for example for CAVP tests, see The FIPS 186-4 Elliptic Curve Digital Signature Algorithm Validation System (ECDSA2VS). 11. In the moment, there is no single known answer tests for ECDSA (which could be activated with #define MBEDTLS_SELF_TEST). I wouldn't say that you need an example for every curve and hash combination, as it is done in ECDSA2VS CAVP, but one example for one of the NIST curves and one for Curve25519 and - if I have a wish free - one for Brainpool would be fine. And this would solve #9 above. I don't get the point here. ECDSA is randomized, so you can't have a known answer test. The test suite does have known answer tests for deterministic ECDSA. 10. While debugging mbedtls_ecdsa_verify() in my example program, I found out, that the ECDSA, ECC and MPI operations are very, let's say, nested. So, IMHO there is a lot of function call overhead and special cases. It would be interesting to see what's the performance impact of a clean, straight-forward mbedtls_ecdsa_verify without restartable code, etc. to the current one. As far as I remember, the refactoring done to add the restartable code had no measurable impact on performance. What does have a significant impact on performance is that the bignum module uses malloc all the time. We would like to completely rewrite bignum operations at some point during the 3.x series, not only for performance but also because its design makes it hard not to leak information through side channels. 12. Just a minor issue: I only needed ECDSA signature verification, therefore I only included MBEDTLS_ASN1_PARSE_C. But it is not possible to compile without MBEDTLS_ASN1_WRITE_C needed for ECDSA signature generation. I'm not sure if I've written it down anywhere, but I'd like to remove the dependency of ECDSA on ASN1 altogether. Parsing and writing a SEQUENCE of two INTEGERs can be done with ad hoc code. Likewise for what little ASN1 the RSA module uses. And then asn1*.o can move out of libmbedcrypto and libpsacrypto, and into libmbedx509 where it belongs. Having only signature verification would be useful, indeed. That may happen with the bignum rewrite I mentioned above, if signature verification ends up using some faster non-constant-time code (this is also relevant for #13). 14. Design question: In the moment, both GCM and CCM use their own implementation of CTR encryption which is very simple. But then we have mbedtls_aes_crypt_ctr() in aes.h which is very simple, too. Let's assume at one day we have a performance optimized CTR encryption (for example from Schwabe & Stoffelen) with all fancy stuff like counter-mode caching etc. Then this would have to be replaced at three places at minimum. While isn't the code at this point more modularized? Is this a dedicated design decision? Having a single implementation of CTR is on the PSA roadmap because if there's a hardware accelerator that does it, we want to use it everywhere it's relevant. In Mbed TLS (or more precisely in its ancestor PolarSSL, if not _its_ ancestor XySSL), there was a conscious design decision to make each .c file as independent from the others as possible, which explains why camellia_ctr is completely independent from aes_ctr. But I don't know why ccm and gcm reimplement ctr. Why do I find at so many places for( i = 0; i < 16; i++ ) y[i] ^= b[i]; instead of a fast 128-bit XOR macro with 32bit aligned data? As a programmer who doesn't write compilers, I think this is the right way to xor 16 bytes, and it's the compiler's job to optimize it to word or vector operations if possible. Admittedly this does mean the compiler has to know that the data is well-aligned, which can be hard to guarantee and easy to forget. So, that's it for the moment. I hope I could give some hints for the further development of mbedTLS. Feel free to discuss any of the above points. It's clear to me that we cannot have both: clear and simple to understand code and performance records. Right. Also maintainable code and minimal code size, because minimal code size comes from letting the application developer #ifdef out everything that they don't care about, but this is a nightmare to test. It's one of the topics we're thinking about for Mbed TLS 3 and beyond. In general, Mbed TLS is primarily targeted at embedded systems, and is likely to privilege 1. security (including side channel resistance) and 2. code size. This doesn't mean that we don't care about performance, just that it isn't our top priority. That being said, we also do have some code that's optimized for performance (without compromising security) and not code size: the library already includes X25519 from Project Everest (https://project-everest.github.io/) (turn it on with MBEDTLS_ECDH_VARIANT_EVEREST_ENABLED). This is code that's formally proven not only for functional correctness, but also for side channel resistance; the implementation has aggressive inlining which makes it very fast, but obviously also large in terms of code size. Hopefully other algorithms will follow soon. Ciao, Torsten Once again, thanks for the detailed feedback, and I hope we can improve Mbed TLS for everyone! -- 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.

5 years, 8 months

2
2
0 0

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

by Gilles Peskine

>From the perspective of an application developer whose platform doesn't have a native malloc, the advantage for Mbed TLS to include its own malloc is one less dependency to integrate (so one less source of potential incompatibilities, one less component to integrate into the build, one less set of parameters to configure, one less feed of security updates to keep up with, etc.). I expect that choosing the Mbed TLS allocator would give poorer performance and higher RAM consumption than choosing the best allocator that exists out there. But it gives better time to market, and potentially a better security posture (the highest-performance allocator may or may not turn out to be actively maintained). -- Gilles Peskine Mbed TLS developer On 16/04/2020 14:19, Janos Follath via mbed-tls wrote: > Hi, > > Thank you for sharing your view, it makes perfect sense. > > You mention that you would consider keeping the module internally for the sake of baremetal applications. How would this serve the user better than choosing a third party malloc implementation? (Assuming that there are better implementation out there than ours, which I haven't confirmed, but it is not hard to imagine that such exists.) > > Regards, > Janos > > > On 15/04/2020, 21:11, "mbed-tls on behalf of Gilles Peskine via mbed-tls" <mbed-tls-bounces(a)lists.trustedfirmware.org on behalf of mbed-tls(a)lists.trustedfirmware.org> wrote: > > On 09/04/2020 13:17, Janos Follath via mbed-tls wrote: > > Hi, > > > > Based on what I read on this thread it seems an accepted point of view that the toolchain provided C standard library implementations are less trusted than the toolchains themselves. Can somebody please help me understand the reasoning behind this distinction? > > Well, I disagree with this statement. I trust the toolchain to implement > the C standard library correctly, and with good performance for the > target platform. I do not want to provide my own implementation of > standard functions. > > I only trust the toolchain to be functionally correct. I don't know > about its security. I certainly can't rely on the toolchain to have > security characteristics that are not guaranteed by the language > definition. For example, I do trust memset_s() to zero out sensitive > memory if the toolchain provides it, but I don't trust memset() for this > task. > > On the topic at hand, my personal opinion of memory_buffer_alloc is that > it doesn't belong in Mbed TLS. I hope that when PSA crypto is a > standalone product, it won't use malloc internally, and so it certainly > won't provide a malloc implementation. I wouldn't necessarily say the > same thing of Mbed TLS 4.0: it's difficult to design an X.509 interface > that doesn't use malloc. But if we can do it, I think we should. > > I recognize that there are many bare-metal applications that don't use > malloc themselves, but use Mbed TLS. For their sake, it does make some > sense for Mbed TLS to have its own malloc implementation. But the focus > is for internal use, not on serving as a general-purpose allocator for > applications that also use malloc for non-mbedtls-related purposes. > > -- > 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 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.

5 years, 8 months

1
0
0 0

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

by Janos Follath

Hi, Thank you for sharing your view, it makes perfect sense. You mention that you would consider keeping the module internally for the sake of baremetal applications. How would this serve the user better than choosing a third party malloc implementation? (Assuming that there are better implementation out there than ours, which I haven't confirmed, but it is not hard to imagine that such exists.) Regards, Janos On 15/04/2020, 21:11, "mbed-tls on behalf of Gilles Peskine via mbed-tls" <mbed-tls-bounces(a)lists.trustedfirmware.org on behalf of mbed-tls(a)lists.trustedfirmware.org> wrote: On 09/04/2020 13:17, Janos Follath via mbed-tls wrote: > Hi, > > Based on what I read on this thread it seems an accepted point of view that the toolchain provided C standard library implementations are less trusted than the toolchains themselves. Can somebody please help me understand the reasoning behind this distinction? Well, I disagree with this statement. I trust the toolchain to implement the C standard library correctly, and with good performance for the target platform. I do not want to provide my own implementation of standard functions. I only trust the toolchain to be functionally correct. I don't know about its security. I certainly can't rely on the toolchain to have security characteristics that are not guaranteed by the language definition. For example, I do trust memset_s() to zero out sensitive memory if the toolchain provides it, but I don't trust memset() for this task. On the topic at hand, my personal opinion of memory_buffer_alloc is that it doesn't belong in Mbed TLS. I hope that when PSA crypto is a standalone product, it won't use malloc internally, and so it certainly won't provide a malloc implementation. I wouldn't necessarily say the same thing of Mbed TLS 4.0: it's difficult to design an X.509 interface that doesn't use malloc. But if we can do it, I think we should. I recognize that there are many bare-metal applications that don't use malloc themselves, but use Mbed TLS. For their sake, it does make some sense for Mbed TLS to have its own malloc implementation. But the focus is for internal use, not on serving as a general-purpose allocator for applications that also use malloc for non-mbedtls-related purposes. -- 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 mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

5 years, 8 months

1
0
0 0

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

by Manuel Pegourie-Gonnard

Hi Gilles, Thanks for this precision, as well as the reminder of the existing github issue. With no opposition here in a week, and none on github for nearly 3 months either, plus no opposition when we marked it as deprecated in 2.21 in February, I'm also moving this to the "Accepted" section on the wiki discussion tracking page: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ - but again, it's still time to voice concerns until we've actually removed it from the code base. Regards, Manuel.

5 years, 8 months

1
0
0 0

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

by Manuel Pegourie-Gonnard

Hi Gilles, Thanks for your feedback and for providing a link to the existing issue, which I completely forgot about - I'll reference that in the wiki as well. Since it's been a week, with one agreement and no opposition, I'm also moving this to the "Accepted" section in the summary wiki page: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ - though again, it you have concerns it's still time to voice them. Regards, Manuel.

5 years, 8 months

1
0
0 0

Re: [mbed-tls] 3.0 plans: remove old TLS options from the code base entirely

by Manuel Pegourie-Gonnard

Hi all, Since this list of old options was probably not controversial in the first place and there has been no opposition in more than a week (a time that was sufficient for other thread in the same series to get several reactions), I'm moving this from "Under discussion" to "Accepted" in the summary wiki page: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ This is not meant to shut down discussion and if you disagree or have concerns it's still time to voice them - this is just to simplify tracking of the discussions. Best regards, Manuel.

5 years, 8 months

1
0
0 0

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

by Gilles Peskine

On 09/04/2020 13:17, Janos Follath via mbed-tls wrote: > Hi, > > Based on what I read on this thread it seems an accepted point of view that the toolchain provided C standard library implementations are less trusted than the toolchains themselves. Can somebody please help me understand the reasoning behind this distinction? Well, I disagree with this statement. I trust the toolchain to implement the C standard library correctly, and with good performance for the target platform. I do not want to provide my own implementation of standard functions. I only trust the toolchain to be functionally correct. I don't know about its security. I certainly can't rely on the toolchain to have security characteristics that are not guaranteed by the language definition. For example, I do trust memset_s() to zero out sensitive memory if the toolchain provides it, but I don't trust memset() for this task. On the topic at hand, my personal opinion of memory_buffer_alloc is that it doesn't belong in Mbed TLS. I hope that when PSA crypto is a standalone product, it won't use malloc internally, and so it certainly won't provide a malloc implementation. I wouldn't necessarily say the same thing of Mbed TLS 4.0: it's difficult to design an X.509 interface that doesn't use malloc. But if we can do it, I think we should. I recognize that there are many bare-metal applications that don't use malloc themselves, but use Mbed TLS. For their sake, it does make some sense for Mbed TLS to have its own malloc implementation. But the focus is for internal use, not on serving as a general-purpose allocator for applications that also use malloc for non-mbedtls-related purposes. -- 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.

5 years, 8 months

1
0
0 0

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

by Gilles Peskine

Yes, we should remove it. Unlike other features, I think we should remove HAVEGE _especially_ if someone is using it, because unlike the rest of the library, I cannot vouch for its security. I don't even know if our havege.c is implementing the HAVEGE specification correctly. And I cannot think of a platform where HAVEGE would give a useful amount of entropy, and where there isn't already a proper hardware RNG or an OS kernel with its own entropy gathering built with knowledge of the actual platform. (Also noted on https://github.com/ARMmbed/mbedtls/issues/2599 .) -- Gilles Peskine Mbed TLS developer On 08/04/2020 12:41, Manuel Pegourie-Gonnard via mbed-tls wrote: > Hi all, > > In this new installment of "let's discuss ideas for Mbed TLS 3.0" [1]: > should we remove havege.c from the code base? > > [1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ > > The crypto library currently includes an implementation of the HAVEGE entropy > gatherer [2], which is disabled in the default build (MBEDTLS_HAVEGE_C in > config.h), but used as a source by our entropy module if enabled. > > [2]: https://www.irisa.fr/caps/projects/hipsor/ > > We'd like to drop this module and remove it from the code base entirely for > the following reasons: > > - HAVEGE was designed for superscalar processors with high > microarchitectural complexity, and is unsuitable for microcontrollers (or > virtualized environments). We feel like when a complex enough CPU is used for > HAVEGE to stand a chance of being secure, it's very likely that an operating > system is also available, which probably already manages a random generator > better that what we can do in user space. > > - On a more practical note, our implementation relies on `timing_hardclock()` > provided by timing.c only for a limited number of architectures and > environments (funnily enough, not including any Arm architecture), with a > silent fallback to a definition relying on `gettimeofday()` which is clearly > not high-resolution enough to make HAVEGE secure. > > - As with any random source, it is very difficult to assess whether HAVEGE is > actually secure on any given platform. Further, the maintenance team > doesn't have any specific knowledge of HAVEGE and there hasn't been any > independent evaluation of our implementation of it. > > - As a result of the above points, we're afraid people using our HAVEGE > implementation on the wrong platforms, might be getting a false sense of > security, which might prevent them from using more secure options, such as the > OS RNG (when using an OS) or a hardware RNG (on microcontrollers). > > If you're using MBEDTLS_HAVEGE_C or know someone who does, or if for any other > reason you think we shouldn't drop it in Mbed TLS 3.0, please speak up now! > > Regards, > Manuel. 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.

5 years, 8 months

1
0
0 0

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

by Gilles Peskine

Hello, As noted in https://github.com/ARMmbed/mbedtls/issues/3006, I'm aware of only one project that is using Mbed TLS's pkcs11-helper support: OpenVPN. But this support has been removed from the development version. -- Gilles Peskine Mbed TLS developer On 08/04/2020 12:37, Manuel Pegourie-Gonnard via mbed-tls wrote: > Hi all, > > In this new installment of "let's discuss ideas for Mbed TLS 3.0" [1]: > should we remove pkcs11.c from the code base? > > [1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ > > The X.509 library currently includes a module called "pkcs11", excluded from > the default build, which provides a few wrappers around libpkcs11-helper [2], > a library that "simplifies the interaction with PKCS#11 providers for end-user > applications". In practice, it supports the use of X.509 certificates > associated with an RSA key (not ECDSA) managed by libpkcs11-helper. > > [2]: https://github.com/OpenSC/pkcs11-helper > > We'd like to drop this module and remove it from the code base entirely for > the following reasons: > > - It has limited functionality, and soon PSA Crypto will provide more flexible > support for secure management of private keys (not just RSA, and not just > associated with X.509 certificates). > > - It currently has not automated tests so we're not even sure if it still > works properly. > > - The documentation is scarce and no member of the current maintenance team > knows for sure how it's supposed to work. > > - We never receive any support request about it so we're not sure if anyone is > still using it. (As a weaker signal in the same direction, we deprecated it > in 2.21.0, released 2020-02-20, and nobody complained so far.) > > If you're using MBEDTLS_PKCS11_C or know someone who does, or if for any other > reason you think we shouldn't drop it in Mbed TLS 3.0, please speak up now! > > Regards, > Manuel. > 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.

5 years, 8 months

1
0
0 0

Running Mbed TLS unit tests on embedded targets

by Gilles Peskine

Hello, We're planning to make some changes to the way you can run Mbed TLS unit tests on embedded platforms. We want to make it easier to run the tests on platforms that have limited space for code and don't have a filesystem to read data from. At the moment, there are two ways to build the test suites. If you run 'make test', this builds one a host executable using host_test.function for each test_suite_*.function and one “compiled” data file for each test_suite_*.data, and the executable reads the compiled data file at runtime. It's also possible to build an executable with target_test.function, which includes calls to the Mbed-tools Greentea library to communicate over the serial port, and you can use the script mbedtls_test.py to run the tests with Greentea. Neither method works directly for embedded platforms other than Mbed OS. If you've run the Mbed TLS unit tests without reading the .datax file from the filesystem, and without using Mbed OS and Greentea, how did you do it? If you haven't run the unit tests but would like to do so, what changes would you like to see what Mbed TLS provides? I have a few more specific questions: • Does Mbed TLS need to include some abstraction for serial communication? If not, what would the interface of the test functions be? (Tests can currently take inputs that are zero-terminated text string, binary string with length, or int, and we'd like to add the possibility to add other integer types such as uint64_t, but nothing more complex. The outcome of a test is pass/fail/skip, and if fail/skip location information about the failure.) • Is it useful to have a way to build the test data into the executable, so that the only interaction that the executable needs is to write out the test results? It's more convenient but doesn't work everywhere (the biggest test suite has >200kB of test data). • Should test executables be self-contained in their reporting (including error messages)? Or should they minimize code size, and then you'd need an extra host-side script to make sense of results? • The current .function-to-.c transformation script (generate_test_code.py) generates a single C file with all of the test code (but not the test data). Is this a useful requirement? We welcome any thoughts you may have on the topic. -- 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.

5 years, 8 months

1
0
0 0

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

by Janos Follath

Hi Dan, Thank you for explaining, I see it now. I think we definitely should leave the choice open for Mbed TLS users and I agree that such a joint stdlib implementation project would be a much better place for a toolchain independent memory allocator. Regards, Janos On 09/04/2020, 14:31, "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 Janos It's not so much that the toolchain stdlib implementations are less trusted from a security point of view, it's that there is variation in their non-functional characteristics, e.g. * security * robustness * code size * performance * open-ness * ... If you remove this variation it's easier to reason about the non-functional characteristics of the code. This is perhaps more important for projects that build final executable images but may also be important for libraries, especially ones that export executable link libraries like Mbed TLS. On the other hand, Mbed TLS is deployed in many other places than Trusted Firmware and it may be hard to choose a stdlib implementation that works for all users. Perhaps the compromise is to create a shared stdlib implementation for Trusted Firmware deployments but leave the choice open for other Mbed TLS users? Regards Dan > -----Original Message----- > From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of > Janos Follath via mbed-tls > Sent: 09 April 2020 12:18 > To: mbed-tls(a)lists.trustedfirmware.org > Subject: Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code > base > > Hi, > > Based on what I read on this thread it seems an accepted point of view that > the toolchain provided C standard library implementations are less trusted > than the toolchains themselves. Can somebody please help me understand the > reasoning behind this distinction? > > Regards, > Janos > > On 09/04/2020, 12:07, "Dan Handley via mbed-tls" <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 > > > 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 -- 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.

5 years, 8 months

1
0
0 0

Some thoughts towards mbed TLS 3.0

by Torsten Schuetze

Hi all, this will be a long mail. Sorry for that. In the past weeks I've been using mbedTLS 2.16.5 for implementing crypto on an ARM Cortex M4 (STM32F479). This was my first experience with mbedTLS, but I have some (almost 20 years) experience with applied and high-assurance crypto. So maybe the following thoughts fit into the discussion of plans for version 3.0 of Mbed TLS. In the end, I achieved everything that was required for my project with mbedTLS, but some things surprised me or it took a while to find out. I'll enumerate the following points for easier reference. Nothing of the following is meant to embarrass anyone, just my personal thoughts. 1. I really missed an Initialize, Update, Finalize (IUF) interface for CCM. For GCM, we have mbedtls_gcm_init(), mbedtls_gcm_setkey(), mbedtls_gcm_starts(), mbedtls_gcm_update() iterated, mbedtls_gcm_finish(), mbedtls_gcm_free() or the comfort functions mbedtls_gcm_crypt_and_tag() and mbedtls_gcm_auth_decrypt(). For CCM, only mbedtls_ccm_init(), mbedtls_ccm_setkey(), mbedtls_ccm_encrypt_and_tag() or mbedtls_ccm_auth_decrypt() and mbedtls_ccm_free(). With this interface it was only possible to encrypt and tag 128 kByte on my target system, while with GCM I could encrypt much larger files. see Github issue #662 and my comment there 2. The next step, of course, is to integrate this into the higher mbedtls_cipher layer. Regarding higher, abstract layers: I often didn't understand which interface I was supposed to use. In general, I like to use the lowest available interface, for example, #include "mbedtls/sha512.h" when I want to use sha512. However, if I need HMAC-SHA-512 or HKDF-HMAC-SHA-512 then I have to use the interface in md.h. For hash functions this is fine. Almost all hash functions are supported via md.h. (I missed SHA-512/256 which is sometimes preferable to SHA-256 on 64bit systems). But with cipher.h, I can only access Chacha20Poly1305 and AES-GCM, not AES-CCM. 3. For certification and evaluation purposes I need some test vectors for each crypto function on target. While I know about the comprehensive self-test program I'm now talking about built-in functions like mbedtls_sha512_self_test(), etc to be enabled with #define MBEDTLS_SELF_TEST. These self-tests are very different in coverage. For SHA-384 and SHA-512 they are fine, for HMAC-SHA-384 and HMAC-SHA-512 I couldn't find any as well as for HKDF-HMAC-SHA-256 (in RFC 5869) or HKDF-HMAC-SHA-384/512 (official test vectors difficult to find). AES-CTR and AES-XTS are only tested with key length 128 bit, not with 256 bit. AES-CCM is not tested with 256 bit and even for 128 bit, the test vector from the standard NIST SP 800-38C with long additional data is not used. The builtin self-test for GCM is the best I've seen with mbedtls: all three key lengths are tested as well as the IUF-interface and the comfort function. Bravo! 4. That I couldn't configure AES-256 only, i.e. without AES-128 and AES-192, was to be expected (and the code overhead is not that much). But in modern modes of operations nobody needs AES decryption, only the forward direction. Sometimes modern publications as Schwabe/Stoffelen "All the AES you need on Cortex-M3 and M4" provide only the forward direction. So, it would be fine if one could configure an AES (ECB) encryption only without decryption. Of course, this is only possible if we don't use CBC mode, etc. This wouldn't only save the AES decryption code but also the rather large T-tables for decryption. 5. Regarding AES or better the AES context-type definition typedef struct mbedtls_aes_context { int nr; /*!< The number of rounds. */ uint32_t *rk; /*!< AES round keys. */ uint32_t buf[68]; /*!< Unaligned data buffer. This buffer can hold 32 extra Bytes, which can be used for one of the following purposes: <ul><li>Alignment if VIA padlock is used.</li> <li>Simplifying key expansion in the 256-bit case by generating an extra round key. </li></ul> */ } mbedtls_aes_context; I really don't understand why we need additional 2176 bit in EVERY AES context. I would understand 128 bit (one block size) or even 512 bit (for example for CTR optimization which is not used!). But 2176 bit in every AES context? The VIA padlock is not very common, I suppose. But even if it were, this doesn't justify such memory overhead. How wasteful this is, one can see in the next type definition /** * \brief The AES XTS context-type definition. */ typedef struct mbedtls_aes_xts_context { mbedtls_aes_context crypt; /*!< The AES context to use for AES block encryption or decryption. */ mbedtls_aes_context tweak; /*!< The AES context used for tweak computation. */ } mbedtls_aes_xts_context; The tweak context is for the encryption of exactly 128 bit, not more. 6. In general, the contexts of mbedTLS are rather full of implementation specific details. Most extreme is mbedtls_ecp_group in ecp.h. Wouldn't it be clearer if one separates the standard things (domain parameters in this case) from implementation specific details? 7. While at Elliptic Curve Cryptography: I assume that some of you know that projectives coordinates as outer interface to ECC are dangerous, see David Naccache, Nigel P. Smart, Jacques Stern: Projective Coordinates Leak, Eurocrypt 2004, pp. 257–267. Therefore, the usual interface in ECC standards are either affine points or compressed affine points (Okay, with the modern curves Curve25519 and Curve 448 it's X only.). Now with /** * \brief The ECP point structure, in Jacobian coordinates. * * \note All functions expect and return points satisfying * the following condition: <code>Z == 0</code> or * <code>Z == 1</code>. Other values of \p Z are * used only by internal functions. * The point is zero, or "at infinity", if <code>Z == 0</code>. * Otherwise, \p X and \p Y are its standard (affine) * coordinates. */ typedef struct mbedtls_ecp_point { mbedtls_mpi X; /*!< The X coordinate of the ECP point. */ mbedtls_mpi Y; /*!< The Y coordinate of the ECP point. */ mbedtls_mpi Z; /*!< The Z coordinate of the ECP point. */ } mbedtls_ecp_point; you have Jacobian coordinates, i.e. projective coordinates, as outer interface. In the comment, its is noted that only the affine part is used, but can this be assured? In all circumstances? 8. In my personal opinion the definition /** * \brief The ECP key-pair structure. * * A generic key-pair that may be used for ECDSA and fixed ECDH, for example. * * \note Members are deliberately in the same order as in the * ::mbedtls_ecdsa_context structure. */ typedef struct mbedtls_ecp_keypair { mbedtls_ecp_group grp; /*!< Elliptic curve and base point */ mbedtls_mpi d; /*!< our secret value */ mbedtls_ecp_point Q; /*!< our public value */ } mbedtls_ecp_keypair; is dangerous. Why not differentiate between private and public key and domain parameters? How often does it happen by accident with this structure that you give the private key (unneeded and dangerous) together with the public key to ECDSA signature verification? Obviously this was known (and perhaps it happened) to the authors of programs\ecdsa.c with the following comment /* * Transfer public information to verifying context * * We could use the same context for verification and signatures, but we * chose to use a new one in order to make it clear that the verifying * context only needs the public key (Q), and not the private key (d). */ What is sometimes useful, is to have the public key at hand when you have performed a private key operation (as countermeasure against fault attacks, verify after signing). But for ECC the verification procedure if often too expensive (in contrast to cheap RSA verify). 9. Regarding ECC examples: I found it very difficult that there isn't a single example with known test vectors as in the relevant crypto standards, i.e. FIPS 186-4 and ANSI X9.62-2005, with raw public keys. What I mean are (defined) curves, public key value Q=(Qx,Qy) and known signature values r and s. In the example ecdsa.c you generate your own key pair and read/write the signature in serialized form. In the example programs/pkey/pk_sign.c and pk_verify.c you use a higher interface pk.h and keys in PEM format. So, it took me a while for a program to verify (all) known answer tests in the standards (old standards as ANSI X9.62 1998 have more detailed known answer tests). One needs this interface with raw public keys for example for CAVP tests, see The FIPS 186-4 Elliptic Curve Digital Signature Algorithm Validation System (ECDSA2VS). 10. While debugging mbedtls_ecdsa_verify() in my example program, I found out, that the ECDSA, ECC and MPI operations are very, let's say, nested. So, IMHO there is a lot of function call overhead and special cases. It would be interesting to see what's the performance impact of a clean, straight-forward mbedtls_ecdsa_verify without restartable code, etc. to the current one. 11. In the moment, there is no single known answer tests for ECDSA (which could be activated with #define MBEDTLS_SELF_TEST). I wouldn't say that you need an example for every curve and hash combination, as it is done in ECDSA2VS CAVP, but one example for one of the NIST curves and one for Curve25519 and - if I have a wish free - one for Brainpool would be fine. And this would solve #9 above. 12. Just a minor issue: I only needed ECDSA signature verification, therefore I only included MBEDTLS_ASN1_PARSE_C. But it is not possible to compile without MBEDTLS_ASN1_WRITE_C needed for ECDSA signature generation. 13. Feature request: Since it was irrelevant for my task (only verification, no generation) I didn't have a detailed look a your ECC side-channel countermeasures. But obviously you use the same protected code for scalar multiplication in verify and sign, right? Wouldn't it be possible to use Shamir's trick in verification with fast unprotected multi-scalar multiplication. In the moment, mbedtls_ecdsa_verify is a factor 4-5 slower than mbedtls_ecdsa_sign, while OpenSSLs verify is faster than sign. 14. Design question: In the moment, both GCM and CCM use their own implementation of CTR encryption which is very simple. But then we have mbedtls_aes_crypt_ctr() in aes.h which is very simple, too. Let's assume at one day we have a performance optimized CTR encryption (for example from Schwabe & Stoffelen) with all fancy stuff like counter-mode caching etc. Then this would have to be replaced at three places at minimum. While isn't the code at this point more modularized? Is this a dedicated design decision? Why do I find at so many places for( i = 0; i < 16; i++ ) y[i] ^= b[i]; instead of a fast 128-bit XOR macro with 32bit aligned data? So, that's it for the moment. I hope I could give some hints for the further development of mbedTLS. Feel free to discuss any of the above points. It's clear to me that we cannot have both: clear and simple to understand code and performance records. Ciao, Torsten

5 years, 8 months

1
0
0 0

Security Advisory and Release of Mbed TLS 2.16.6 and 2.7.15

by Janos Follath

Hi, An Mbed TLS Security Advisory has been issued to accompany the release of Mbed TLS versions 2.16.6 and 2.7.15, which have just been released. 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://tls.mbed.org/techupdates/releases/mbedtls-2.16.6-and-2.7.15-released> and in the 2020-04 security advisory<https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advi…>. We recommend all users to consider whether they are impacted, and to upgrade appropriately. -- Janos Follath 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.

5 years, 8 months

1
0
0 0

mbedtls_base64_encode reports different olen's when used for size checking and when encoding

by Frederik Wedel-Heinen

Hi, I don't understand why mbedtls_base64_encode returns different olen's for the same source buffer. See example below: uint8_t s[10]; uint8_t d[17]; size_t sz; int ret; ret = mbedtls_base64_encode(NULL, 0, &sz, s, 10); // returns sz == 17 ret = mbedtls_base64_encode(d, 17, &sz, s, 10); // returns sz == 16 Shouldn't it be the same? Regards, Frederik

5 years, 8 months

1
0
0 0

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

by Dan Handley

Hi Janos It's not so much that the toolchain stdlib implementations are less trusted from a security point of view, it's that there is variation in their non-functional characteristics, e.g. * security * robustness * code size * performance * open-ness * ... If you remove this variation it's easier to reason about the non-functional characteristics of the code. This is perhaps more important for projects that build final executable images but may also be important for libraries, especially ones that export executable link libraries like Mbed TLS. On the other hand, Mbed TLS is deployed in many other places than Trusted Firmware and it may be hard to choose a stdlib implementation that works for all users. Perhaps the compromise is to create a shared stdlib implementation for Trusted Firmware deployments but leave the choice open for other Mbed TLS users? Regards Dan > -----Original Message----- > From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of > Janos Follath via mbed-tls > Sent: 09 April 2020 12:18 > To: mbed-tls(a)lists.trustedfirmware.org > Subject: Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code > base > > Hi, > > Based on what I read on this thread it seems an accepted point of view that > the toolchain provided C standard library implementations are less trusted > than the toolchains themselves. Can somebody please help me understand the > reasoning behind this distinction? > > Regards, > Janos > > On 09/04/2020, 12:07, "Dan Handley via mbed-tls" <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 > > > 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

5 years, 8 months

1
0
0 0

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

by Janos Follath

Hi, Based on what I read on this thread it seems an accepted point of view that the toolchain provided C standard library implementations are less trusted than the toolchains themselves. Can somebody please help me understand the reasoning behind this distinction? Regards, Janos On 09/04/2020, 12:07, "Dan Handley via mbed-tls" <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 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.

5 years, 8 months

1
0
0 0

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

by Dan Handley

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.

5 years, 8 months

1
0
0 0

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

by Ronald Cron

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.

5 years, 8 months

1
0
0 0

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

by ROSHINI DEVI

Hello All, In our embedded platform, we are using static memory allocator, instead of using heap memory of the platform. We thought it is better way to handle the memory. As the application grows, there might be multiple libraries using the heap memory. And also the possible cause of memory leaks. My suggestion is that it is better to have it. I have seen this kind of allocator in mocona secure library also. Thanks On Wed, Apr 8, 2020 at 4:11 PM Manuel Pegourie-Gonnard via mbed-tls < mbed-tls(a)lists.trustedfirmware.org> wrote: > 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 >

5 years, 8 months

1
0
0 0

3.0 plans: remove memory_buffer_alloc.c from the code base

by Manuel Pegourie-Gonnard

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.

5 years, 8 months

1
0
0 0

3.0 plans: remove havege.c from the code base

by Manuel Pegourie-Gonnard

Hi all, In this new installment of "let's discuss ideas for Mbed TLS 3.0" [1]: should we remove havege.c from the code base? [1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ The crypto library currently includes an implementation of the HAVEGE entropy gatherer [2], which is disabled in the default build (MBEDTLS_HAVEGE_C in config.h), but used as a source by our entropy module if enabled. [2]: https://www.irisa.fr/caps/projects/hipsor/ We'd like to drop this module and remove it from the code base entirely for the following reasons: - HAVEGE was designed for superscalar processors with high microarchitectural complexity, and is unsuitable for microcontrollers (or virtualized environments). We feel like when a complex enough CPU is used for HAVEGE to stand a chance of being secure, it's very likely that an operating system is also available, which probably already manages a random generator better that what we can do in user space. - On a more practical note, our implementation relies on `timing_hardclock()` provided by timing.c only for a limited number of architectures and environments (funnily enough, not including any Arm architecture), with a silent fallback to a definition relying on `gettimeofday()` which is clearly not high-resolution enough to make HAVEGE secure. - As with any random source, it is very difficult to assess whether HAVEGE is actually secure on any given platform. Further, the maintenance team doesn't have any specific knowledge of HAVEGE and there hasn't been any independent evaluation of our implementation of it. - As a result of the above points, we're afraid people using our HAVEGE implementation on the wrong platforms, might be getting a false sense of security, which might prevent them from using more secure options, such as the OS RNG (when using an OS) or a hardware RNG (on microcontrollers). If you're using MBEDTLS_HAVEGE_C or know someone who does, or if for any other reason you think we shouldn't drop it in Mbed TLS 3.0, please speak up now! Regards, Manuel.

5 years, 8 months

1
0
0 0

3.0 plans: remove pkcs11.c from the code base

by Manuel Pegourie-Gonnard

Hi all, In this new installment of "let's discuss ideas for Mbed TLS 3.0" [1]: should we remove pkcs11.c from the code base? [1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ The X.509 library currently includes a module called "pkcs11", excluded from the default build, which provides a few wrappers around libpkcs11-helper [2], a library that "simplifies the interaction with PKCS#11 providers for end-user applications". In practice, it supports the use of X.509 certificates associated with an RSA key (not ECDSA) managed by libpkcs11-helper. [2]: https://github.com/OpenSC/pkcs11-helper We'd like to drop this module and remove it from the code base entirely for the following reasons: - It has limited functionality, and soon PSA Crypto will provide more flexible support for secure management of private keys (not just RSA, and not just associated with X.509 certificates). - It currently has not automated tests so we're not even sure if it still works properly. - The documentation is scarce and no member of the current maintenance team knows for sure how it's supposed to work. - We never receive any support request about it so we're not sure if anyone is still using it. (As a weaker signal in the same direction, we deprecated it in 2.21.0, released 2020-02-20, and nobody complained so far.) If you're using MBEDTLS_PKCS11_C or know someone who does, or if for any other reason you think we shouldn't drop it in Mbed TLS 3.0, please speak up now! Regards, Manuel. 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.

5 years, 8 months

1
0
0 0

Mbed TLS/PSA Crypto Roadmap

by Shebu Varghese Kuriakose

Hi All, Here is the link to the roadmap for Mbed TLS and PSA Crypto in the coming quarters. https://developer.trustedfirmware.org/w/mbed-tls/roadmap/ If you are interested in collaborating on any of the roadmap features or other features in the project, please let your interest known via. the mailing lists. Note that the expected quarter when a feature will be completed is based on very rough estimates of the effort involved and therefore might change. Roadmap will be reviewed and updated at the start of every quarter depending on progress made in previous quarter. Thanks, Shebu (Mbed TLS, PSA Crypto Technology Manager, Arm)

5 years, 8 months

1
0
0 0

3.0 plans: remove old TLS options from the code base entirely

by Manuel Pegourie-Gonnard

Hi all, As a general rule I'll start a thread of each of the changes to be discussed for inclusion in Mbed TLS 3.0, but as an exception to that rule, I'm grouping several items here because I suspect they probably won't generate much discussion (if any). Note: in general we keep obsolete crypto primitives in the code base (disabled by default at compile time), so that people can still use them to process old data at rest. This list however is about TLS options, i. e. handling live data in transit, so it makes sense to completely remove them from the code base once they're not used any more. It also decreases the complexity of the code base, hence improving its maintainability, testability and security. * Drop support for parsing SSLv2 ClientHello (`MBEDTLS_SSL_SRV_SUPPORT_SSLV2_CLIENT_HELLO`). This was only needed back when common frameworks (old version of Java most motably) used this format for ClientHellos for compatibility with old an buggy servers, and when people would actually consider negociating SSL 2.0. Fortunately, that's not the case any more. Also, removing this unblocks some much-needed refactorings and simplification of the code (and this option has become hard to test). * Drop support for SSLv3 (`MBEDTLS_SSL_PROTO_SSL3`). This version of the protocol was deprecated by the IETF (MUST NOT use since 2015 - RFC 7568) and is no longer widely used. * Drop support for compatibility with our own previous buggy implementation of truncated HMAC (`MBEDTLS_SSL_TRUNCATED_HMAC_COMPAT`). This is only useful for people who want to interoperate with buggy pre-2.7 Mbed TLS. Since those versions are no longer maintained, hopefully everyone has updated by now. * Drop support for TLS record-level compression (`MBEDTLS_ZLIB_SUPPORT`). There are potential security issues with this option (compression if any should be done at the appplication level in order to separate secrets from attacker-controlled content), it's not widely used, and was removed in TLS 1.3. * Drop RC4 ciphersuites. These have been prohibited by RFC 7465 since 2015. (Note: as a bonus, we can then remove the config.h option `MBEDTLS_REMOVE_ARC4_CIPHERSUITES` as well.) * Drop the single-DES ciphersuites. 56-bit keys, need I say more? * Support for SSL record hardware acceleration (`MBEDTLS_SSL_HW_RECORD_ACCEL`). Nobody in the team knows how it's supposed to work, it's entirely untested, and we think nobody uses it, it's been failing to build for a while and nobody complained so far. (Note: we still fixed the bug, see PR #2262.) Do you agree with the above list? Are you (or people you know) using one of those features? Would you add things to that list (keeping the focus on SSL/TLS obsolete features for now)? Thanks in advance for sharing your thoughts! Regards, Manuel.

5 years, 8 months

1
0
0 0

Re: [mbed-tls] Plans for Mbed TLS 3.0

by Manuel Pegourie-Gonnard

Hi again, Note: I've created a wiki page [1] to summarize and consolidate the results of the discussions that will be happening here about Mbed TLS 3.0. [1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ I also wanted to note that the current goals, as announced yesterday, contain some changes compared to what had been announced nearly one year ago [2], so I'd like to briefly recap what changed and what didn't. [2]: https://tls.mbed.org/tech-updates/blog/working-towards-mbed-tls-3 Preparing a future based on PSA Crypto -------------------------------------- We remain committed to that, but are now taking a different route towards that goal. Initially we started to split Mbed Crypto out of Mbed TLS, which was not the clean split between PSA Crypto and TLS/X.509 than we want in the long run, so the plan was to evolve towards that. With the experience gained, we now think it's easier to evolve things in one place, so we merged back mbed-crypto into the mbedtls repo (see [3]), and still plan on making PSA Crypto its own product, but only when we're ready to make that split cleanly. [3]: https://github.com/ARMmbed/mbedtls/issues/3064 Also, we initially hinted that the long-standing `mbedtls_` crypto APIs would be removed in Mbed TLS 3.0 (superseded by the PSA Crypto APIs). We're now considering a more gradual and hopefully more realistic transition where Mbed TLS 3.0 continues to offer some of those APIs for compatibility with existing code-bases, and they would only be actually removed in Mbed TLS 4.0. TLS 1.3 and message processing rework ------------------------------------- This is still not part of a realistic roadmap for Mbed TLS 3.0, but still close to our hearts for the future. Switching to a new licensing and contribution model --------------------------------------------------- This has been done already. The development branch now uses Apache 2.0 only, while the LTS branches are still dual-licensed Apache/GPL2. We moved away from a CLA and closer to an inbound == outbound model (not quite == yet because of the differences between development and LTS branches), see [4]. [4]: https://github.com/ARMmbed/mbedtls/issues/3054 Opening up the governance of the project ---------------------------------------- This also happened already. Mbed TLS is now under open governance as part of the trustedfirmware.org structure. As a consequence of this move, Mbed TLS is now more focused on building and maintaining a healthy community of users, contributors and maintainers. Again, I hope that was clear and feel free to ask if you have any question or remark. I'll follow up by starting threads on more specific items. Regards, Manuel.

5 years, 8 months

1
0
0 0

mbedTLS on ESP8266 SDK - memory issue?

by LockSafe

Hi. I have posted an issue I am having with the use of mbedTLS with ESP8266 SDK (it is freeRTOS based), I have posted my explanation in the link below, then their support asked me to send new questions to this email. If you have any doubt regarding my tests, or if you want I make more different tests, please don't hesitate do ask me. https://forums.mbed.com/t/mbedtls-on-esp8266-sdk-memory-issue/7913 Regards. <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> Livre de vírus. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…>. <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

5 years, 8 months

1
0
0 0

Plans for Mbed TLS 3.0

by Manuel Pegourie-Gonnard

Hi all, In the next few months we'll be preparing version 3.0 of Mbed TLS (with a goal of releasing in the 3rd quarter of calendar year 2020, see our roadmap [1]). [1]: https://developer.trustedfirmware.org/w/mbed-tls/roadmap/ We've been maintaining full API compatibility since Mbed TLS 2.0.0 was released in July of 2015, so this will be our first chance in 5 years to clean up any API that we've found not to be entirely satisfactory, or no longer needed. This is the first in a series of threads discussing what we would like to do in Mbed TLS 3.0 and how (or what we should rather postpone or not do at all). It will present the high-level goals and list some items as examples. Specific items that deserve further discussion (either to decide whether to include them in 3.0, or refine their scope or meaning) will be discussed each in their own thread. Clean up the code by removing old things ---------------------------------------- This facilitates maintenance and testing. Examples: - Remove support for SSL 3.0 and other deprecated protocol options. (But keep support for old crypto that could be useful for data at rest.) - Remove API functions that have been superseded. Improve existing APIs, behaviours, and defaults ----------------------------------------------- This is mainly small things we just couldn't do in the 2.x line due to our compatibility rules. Examples: - Upgrade the default TLS config to only offer (D)TLS 1.2 with forward-secure key exchanges and AEAD ciphers. - Add the 'const' qualifier to various arguments of existing APIs. - Add size arguments to existing APIs that lack such arguments. Reduce the surface of the public API ------------------------------------ This makes it easier to evolve the library while maintaining API compatibility, and also makes testing easier. Examples: - Forbid direct access to members of most (all?) structures. - Define more clearly which APIs are internal and forbid access to them. - Move some non-core modules that are only useful for examples out of the library (for example, certs.s). Prepare the migration to PSA Crypto ----------------------------------- Currently Mbed TLS consists of three libraries: SSL/(D)TLS, X.509, and Crypto. Furthermore, currently Crypto provides both the long-standing `mbedtls_` APIs and the new PSA Crypto APIs, and the TLS and X.509 libraries still largely rely on the `mbedtls_` APIs, as does probably a large amount of external code. Ultimately, we want to move to place where TLS and X.509 only rely on the PSA Crypto API (whose reference implementation will be independent and longer part of Mbed TLS), and where nobody uses the legacy `mbedtls_` APIs any more. But that's a goal for Mbed TLS 4.0. In the meantime, Mbed TLS 3.0 should pave the way for this. The most important thing we want to do in 3.0 is to make most of the low-level crypto modules internal, and only keep the high-level crypto modules to ease the migration for existing users of the `mbedtls_` crypto APIs. Concretely, this would mean for example that the `mbedtls_aes_` functions and types would no longer be part of the API, but using AES via the `mbedtls_cipher_` APIs would still be supported for existing users until Mbed TLS 4.0 - and of course using AES via the PSA Crypto API is the way forward. As this is a vast and complex topic, there will be a specific thread on where exactly we can and would like to draw the line of which crypto APIs are becoming private in Mbed TLS 3.0 and which are maintained until Mbed TLS 4.0 to ease migration. Note: this strongly overlaps with the previous section (reduce the surface of the public API), but the two are still distinct as they're guided by different incentives: general maintainability vs supporting a specific migration. I hope this email starts to clarify what Mbed TLS 3.0 should look like. Feel free to ask questions if anything's not clear, and again, there will be follow-up threads in the coming days and week to discuss specific aspects in more details. Best regards, Manuel (Mbed TLS developer)

5 years, 8 months

1
0
0 0

Re: [mbed-tls] Static Memory allocation Buffer Size for DTLS #3146

by Manuel Pegourie-Gonnard

Hi Roshini, [please always repy to the list, this allows other people to help as well] > Thanks for your reply. >I am running into one weird issue in memory allocation part. Before moving to the issue, let me explain my configuration macros. > MBEDTLS_SSL_MAX_CONTENT_LEN - Default value > I have enabled platform memory macros > > I have allocated heap memory of around 60KB, which I though is sufficient for DTLS. > I am using ecc based certificates. > And also my application contains CoAP secured using DTLS. > The issue is - > 1. I am sending coap request and I successfully obtain the response also. > I continue the above step for 3 times. 3rd time I am observing the debug message - "ssl_srv.c:3808: |1| mbedtls_ecdh_calc_secret() returned -16 (-0x0010)". > The return code corresponds to memory allocation failure in BIGNUM. > To investigate further, I have customized my calloc function to print the function name - from which allocation failure is done. > I can see the memory allocation failure happened at API "mbedtls_mpi_grow". > > Further, I have increased the heap memory. But still issue is reproducing after certain number of iterations. > > Do you need to change any configuration setting? Not sure why this is happening? I am facing this issue for past 1 week. > It would be really helpful if you can guide me in this issue. If the connection is succeeding the first few times, and failing after a number of times with an out-of-memory message (and the larger the heap, the longer it goes before failing), to me this suggests two possible causes: 1. There could be a memory leak somewhere, in Mbed TLS or in other code used by your application. We do our best to avoid those in Mbed TLS, so I'd like to hope it's unlikely there is a leak in Mbed TLS, but it can't be completely excluded. If the core issue is a memory leak, it could also be in other parts of the code used by your application. One way to check for this would be to print out the current state of the allocator after each successful connection, and check if there is more memory still in use after each connection than after the previous connection. 2. Alternatively, if there is no leak, it could be that the heap is getting so fragmented that the allocator can't find enough consecutive space. Given that the failure happens in `mpi_grow()` which usually makes rather small allocations, that's probably not likely the issue here, but I thought I'd mention it for completeness. Regards, Manuel.

5 years, 8 months

1
0
0 0

Re: [mbed-tls] Allowing unsupported extensions in X.509 certificates

by Gilles Peskine

On 03/04/2020 10:11, Hanno Becker via mbed-tls wrote: > Hi Lev, > > I believe that this kind of functionality could be implemented on top > of the existing > verify-with-callback API `mbedtls_x509_crt_verify_with_cb()`. More > precisely, > you can enable `MBEDTLS_X509_ALLOW_UNSUPPORTED_CRITICAL_EXTENSION` > to ignore unknown extensions initially, and then chekc them yourself > in the > verification callback by manually > traversing `mbedtls_x509_crt::v3_ext`. If you detect > an extension you cannot make sense of and which is marked critical, > you can modify the > verification flags. > > Would that work for you, in principle? Note, though, that this would > work at the level > of verification, not parsing, which might or might not be acceptable. That's a possibility, but it's not very nice. It would be nicer if the library provided the extensions in a list, or provided an easy way to traverse them, which is the solution I'm currently leaning towards. > > In this regard you might also be interested in knowing about a > significant rewrite > of CRT parsing on the `baremetal` branch. The main difference is that > the X.509 CRT > structure has been stripped down to no longer make use of dynamically > allocated > memory but instead only provide pointers to the various fields in the > certificate. > In the case of dynamic-length fields such as the Subject or Issuer > names, but also > the extension list, inspection shall be done through a newline > introduced ASN.1 > parsing function > > int mbedtls_asn1_traverse_sequence_of( > unsigned char **p, > const unsigned char *end, > uint8_t tag_must_mask, uint8_t tag_must_val, > uint8_t tag_may_mask, uint8_t tag_may_val, > int (*cb)( void *ctx, int tag, > unsigned char* start, size_t len ), > void *ctx ); > > https://github.com/ARMmbed/mbedtls/blob/baremetal/include/mbedtls/asn1.h#L3… > > This function traverses an ASN.1 sequence and triggers a callback for > each item found. > This functionality could be used to perform the extension traversal in > the verification callback > or directly after parsing. > > Which extensions are you interested in, particularly, by the way? If > it is a standardized > extension, feel free to add support for it under a new compile-time > feature flag and > file a PR to add it. We do have to balance code size against the proliferation of compile-time options. A compile-time option dedicated for a specific extension is relatively easy to test (like we test the library with/without each cryptographic algorithm). But we should do this in a way that would work well if each extension is gated by a compile-time option, so let's please discuss the design first. -- Gilles Peskine Mbed TLS developer > > Cheers, > Hanno > ------------------------------------------------------------------------ > *From:* mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on > behalf of Lev Stipakov via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> > *Sent:* Friday, April 3, 2020 8:32 AM > *To:* mbed-tls(a)lists.trustedfirmware.org > <mbed-tls(a)lists.trustedfirmware.org> > *Subject:* Re: [mbed-tls] Allowing unsupported extensions in X.509 > certificates > > Hi, > > I am not too much into mbedTLS design and not sure if this would make > sense, > but what about if we introduce an API to let client decide, what to do > with unknown extensions? > > Let's provide a way for a client to specify a callback > > typedef int (*mbedtls_x509_crt_unsupported_extension_cb_t)( > const mbedtls_asn1_buf *oid ); > > which could be an argument to a new method > > int mbedtls_x509_crt_parse_with_ext_cb( mbedtls_x509_crt *chain, > const unsigned char *buf, > size_t buflen, > > mbedtls_x509_crt_unsupported_extension_cb_t f_ext_cb ); > > > which is called when parser encounters unsupported extension: > > /* > * Detect supported extensions > */ > ret = mbedtls_oid_get_x509_ext_type( &extn_oid, &ext_type ); > if( ret != 0 ) > { > /* No parser found, skip extension */ > *p = end_ext_octet; > > if( is_critical ) > { > /* Data is marked as critical: ask client what to do */ > if( f_ext_cb != NULL ) > { > ret = f_ext_cb( &extn_oid ); > } > > /* Client is OK with unsupported critical extension, continue */ > if( ret == 0 ) > continue; > > return( MBEDTLS_ERR_X509_INVALID_EXTENSIONS + > MBEDTLS_ERR_ASN1_UNEXPECTED_TAG ); > } > > continue; > } > > This would allow us to deprecate > MBEDTLS_X509_ALLOW_UNSUPPORTED_CRITICAL_EXTENSION - > those clients which want to allow all extensions could pass a callback > which always returns 0. > > What do you think? > > -- > -Lev > -- > 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. > 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.

5 years, 8 months

1
0
0 0

Re: [mbed-tls] How to generate a certificate request with X.509 OID MBEDTLS_OID_SERVER_AUTH

by Hanno Becker

Hi Thomas, Could you share the relevant piece of the code and perhaps the raw CSR data it generates? >From what you write, it looks like you have called `mbedtls_x509write_csr_set_extension()` with OID `MBEDTLS_OID_SERVER_AUTH`, which isn't quite right: `mbedtls_x509write_csr_set_extension()` registers a single extension, and the TLS Web Server Authentication usage is one usage constraint within the ExtendedKeyUsage extension. I'd therefore expect that you have to call `mbedtls_x509write_csr_set_extension()` with `MBEDTLS_OID_EXTENDED_KEY_USAGE` passing it the raw ASN.1 content of the ExtendedKeyUsage extension, part of which is `MBEDTLS_OID_SERVER_AUTH`. To my knowledge, there is currently no API within Mbed TLS which helps you writing this ASN.1 content from a list of usage constraints, so you will need to build it manually. If you have trouble with that, let us know. Alternatively, you might copy it from any certificate you know which has the desired ExtendedKeyUsage. Apologies for this inconvenience, I do think it would be beneficial to have some helper function for writing such an important extension as ExtendedKeyUsage which doens't force users to hand-craft ASN.1. Best, Hanno ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Volgmann via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: Friday, April 3, 2020 9:01 AM To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] How to generate a certificate request with X.509 OID MBEDTLS_OID_SERVER_AUTH Hello, I have a problem generating the following content in an certificate request : Requested Extensions: X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Basic Constraints: CA:FALSE The only thing I could produce was : Requested Extensions: X509v3 Key Usage: Digital Signature X509v3 Extended Key Usage: TLS Web Server Authentication: Can anybody help me with the function : mbedtls_x509write_csr_set_extension Mit freundlichen Grüßen Thomas Volgmann --------------------------------------- DSA-Volgmann Redcarstr. 20 53842 Troisdorf Tel: 02241 23416 11 Fax: 02241 23416 61 email : thomas.volgmann(a)dsa-volgmann.de<mailto:thomas.volgmann@dsa-volgmann.de> web: www.dsa-volgmann.de<http://www.dsa-volgmann.de/> --------------------------------------- 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.

5 years, 8 months

1
0
0 0

Re: [mbed-tls] Allowing unsupported extensions in X.509 certificates

by Hanno Becker

Hi Lev, I believe that this kind of functionality could be implemented on top of the existing verify-with-callback API `mbedtls_x509_crt_verify_with_cb()`. More precisely, you can enable `MBEDTLS_X509_ALLOW_UNSUPPORTED_CRITICAL_EXTENSION` to ignore unknown extensions initially, and then chekc them yourself in the verification callback by manually traversing `mbedtls_x509_crt::v3_ext`. If you detect an extension you cannot make sense of and which is marked critical, you can modify the verification flags. Would that work for you, in principle? Note, though, that this would work at the level of verification, not parsing, which might or might not be acceptable. In this regard you might also be interested in knowing about a significant rewrite of CRT parsing on the `baremetal` branch. The main difference is that the X.509 CRT structure has been stripped down to no longer make use of dynamically allocated memory but instead only provide pointers to the various fields in the certificate. In the case of dynamic-length fields such as the Subject or Issuer names, but also the extension list, inspection shall be done through a newline introduced ASN.1 parsing function int mbedtls_asn1_traverse_sequence_of( unsigned char **p, const unsigned char *end, uint8_t tag_must_mask, uint8_t tag_must_val, uint8_t tag_may_mask, uint8_t tag_may_val, int (*cb)( void *ctx, int tag, unsigned char* start, size_t len ), void *ctx ); https://github.com/ARMmbed/mbedtls/blob/baremetal/include/mbedtls/asn1.h#L3… This function traverses an ASN.1 sequence and triggers a callback for each item found. This functionality could be used to perform the extension traversal in the verification callback or directly after parsing. Which extensions are you interested in, particularly, by the way? If it is a standardized extension, feel free to add support for it under a new compile-time feature flag and file a PR to add it. Cheers, Hanno ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Lev Stipakov via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: Friday, April 3, 2020 8:32 AM To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: Re: [mbed-tls] Allowing unsupported extensions in X.509 certificates Hi, I am not too much into mbedTLS design and not sure if this would make sense, but what about if we introduce an API to let client decide, what to do with unknown extensions? Let's provide a way for a client to specify a callback typedef int (*mbedtls_x509_crt_unsupported_extension_cb_t)( const mbedtls_asn1_buf *oid ); which could be an argument to a new method int mbedtls_x509_crt_parse_with_ext_cb( mbedtls_x509_crt *chain, const unsigned char *buf, size_t buflen, mbedtls_x509_crt_unsupported_extension_cb_t f_ext_cb ); which is called when parser encounters unsupported extension: /* * Detect supported extensions */ ret = mbedtls_oid_get_x509_ext_type( &extn_oid, &ext_type ); if( ret != 0 ) { /* No parser found, skip extension */ *p = end_ext_octet; if( is_critical ) { /* Data is marked as critical: ask client what to do */ if( f_ext_cb != NULL ) { ret = f_ext_cb( &extn_oid ); } /* Client is OK with unsupported critical extension, continue */ if( ret == 0 ) continue; return( MBEDTLS_ERR_X509_INVALID_EXTENSIONS + MBEDTLS_ERR_ASN1_UNEXPECTED_TAG ); } continue; } This would allow us to deprecate MBEDTLS_X509_ALLOW_UNSUPPORTED_CRITICAL_EXTENSION - those clients which want to allow all extensions could pass a callback which always returns 0. What do you think? -- -Lev -- 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.

5 years, 8 months

1
0
0 0

Re: [mbed-tls] Allowing unsupported extensions in X.509 certificates

by Lev Stipakov

Hi, I am not too much into mbedTLS design and not sure if this would make sense, but what about if we introduce an API to let client decide, what to do with unknown extensions? Let's provide a way for a client to specify a callback typedef int (*mbedtls_x509_crt_unsupported_extension_cb_t)( const mbedtls_asn1_buf *oid ); which could be an argument to a new method int mbedtls_x509_crt_parse_with_ext_cb( mbedtls_x509_crt *chain, const unsigned char *buf, size_t buflen, mbedtls_x509_crt_unsupported_extension_cb_t f_ext_cb ); which is called when parser encounters unsupported extension: /* * Detect supported extensions */ ret = mbedtls_oid_get_x509_ext_type( &extn_oid, &ext_type ); if( ret != 0 ) { /* No parser found, skip extension */ *p = end_ext_octet; if( is_critical ) { /* Data is marked as critical: ask client what to do */ if( f_ext_cb != NULL ) { ret = f_ext_cb( &extn_oid ); } /* Client is OK with unsupported critical extension, continue */ if( ret == 0 ) continue; return( MBEDTLS_ERR_X509_INVALID_EXTENSIONS + MBEDTLS_ERR_ASN1_UNEXPECTED_TAG ); } continue; } This would allow us to deprecate MBEDTLS_X509_ALLOW_UNSUPPORTED_CRITICAL_EXTENSION - those clients which want to allow all extensions could pass a callback which always returns 0. What do you think? -- -Lev

5 years, 8 months

1
0
0 0

How to generate a certificate request with X.509 OID MBEDTLS_OID_SERVER_AUTH

by Thomas Volgmann

Hello, I have a problem generating the following content in an certificate request : Requested Extensions: X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Basic Constraints: CA:FALSE The only thing I could produce was : Requested Extensions: X509v3 Key Usage: Digital Signature X509v3 Extended Key Usage: TLS Web Server Authentication: Can anybody help me with the function : mbedtls_x509write_csr_set_extension Mit freundlichen Grüßen Thomas Volgmann --------------------------------------- DSA-Volgmann Redcarstr. 20 53842 Troisdorf Tel: 02241 23416 11 Fax: 02241 23416 61 email : thomas.volgmann(a)dsa-volgmann.de<mailto:thomas.volgmann@dsa-volgmann.de> web: www.dsa-volgmann.de<http://www.dsa-volgmann.de/> ---------------------------------------

5 years, 8 months

1
0
0 0

Re: [mbed-tls] TLS context serialization: can it be done?

by Hanno Becker

Hi Dmitrii! The reason why we focused on DTLS 1.2 + AEAD for the context serialization was because that's what we needed to support quickly at the time, and not because we saw some fundamental technical obstacles in implementing context serialization for TLS 1.2. I did the same as you, commenting out DTLS checks, and ran into the same problem during `mbedtls_cipher_auth_decrypt()`. The problem turns out to be the following: In TLS, the context contains an incoming record counter which, while in DTLS, the record counter is explicit and hence need not be maintained. In particular, when using the current serialization+deserialization functions with TLS 1.2, the incoming record counter will be corrupted. The core of the fix is simple: You need to duplicate https://github.com/ARMmbed/mbedtls/blob/development/library/ssl_tls.c#L6228… and https://github.com/ARMmbed/mbedtls/blob/development/library/ssl_tls.c#L6496… -- which save/load the _outgoing_ counter -- for the incoming counter `ssl->in_ctr`. I just tried this and things worked afterwards. Could you try and see if it works for you, too? If so, please feel free to adapt the serialization functions and file a PR to add support for serialization in TLS, and mark me as a reviewer. Note: There will likely be other things that need fixing, too, so please be careful in using the above patch as-is unless for experimentation. Cheers, Hanno ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Kuvaiskii, Dmitrii via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: Tuesday, March 31, 2020 8:58 PM To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] TLS context serialization: can it be done? Dear all, I have the following question. mbedTLS v2.21.0 has support for TLS context serialization in the form of two functions: `mbedtls_ssl_context_save()` and `mbedtls_ssl_context_load()`. I'm trying to use these functions in another project (Graphene, an Intel SGX framework). Slightly oversimplifying, I want to establish a secure communication channel between two different Linux processes. I'd like to persist one of them and then re-spawn it again with the communication channel intact (so that there is no need for a new TLS handshake). However, I notice that currently these functions support only DTLS 1.2, see e.g.: https://github.com/ARMmbed/mbedtls/blob/aaabe86ac1f47193f4fc499846a0b3abeae… But I want to use a normal TLS channel, in particular with a ciphersuite `MBEDTLS_TLS_PSK_WITH_AES_128_GCM_SHA256`. I commented out the checks on DTLS in these functions just to see what will happen. As expected, both functions serialized and then deserialized the context, but when doing a `write(ssl_ctx)` in one (not-persisted) process and a `read(loaded_ssl_ctx)` in another (re-spawned) process, I get an error in `mbedtls_cipher_auth_decrypt()`. Clearly, my deserialized context didn't restore some vital information on the TLS session, and this led to failure in decryption. Thus, I have two questions: 1. Is there any version of this code that also works on TLS? 2. What are the additional internal objects that must be serialized for TLS (if it makes things easier, in my particular case with AES-GCM and a pre-shared key)? I looked at the code and tried to dump more fields in `mbedtls_ssl_transform`, but it didn't help much. If you'd provide me with some pointers, I could tinker more with mbedTLS code and hopefully make it work. Thanks in advance for any pointers! -- Dmitrii -- 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.

5 years, 8 months

2
2
0 0

Re: [mbed-tls] question: SIGPIPE handling

by Gilles Peskine

On 01/04/2020 11:29, Anibal Portero via mbed-tls wrote: > SIGPIPE is handled with a signal( SIGPIPE, SIG_IGN ) in mbedtls_net_connect. While the examples in programs/ssl/ssl_client1.c or programs/ssl/ssl_client2.c are calling mbedtls_net_connect, programs/ssl/mini_client.c is not, and therefore not changing the default behavior of SIGPIPE. > Our client is based on mini_client.c. What would the best way to handle SIGPIPE? Would it be worth it to add signal( SIGPIPE, SIG_IGN ) to the mini_client.c example for future reference? maybe even make net_prepare() visible from outside so a mini client like application can use it? That's a good question. I wonder why mbedtls_net_connect() calls signal(). It's been the case ever since net.c was introduced in XySSL 0.5. But that's a global setting and I don't think a library function that's supposed to act on a specific socket should modify a global setting. Should mbedtls_net_send() call send(MSG_NOSIGNAL) instead of write()? But what about older systems without MSG_NOSIGNAL? Is there a portable way to disable SIGPIPE for a specific socket? -- 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.

5 years, 8 months

1
0
0 0

Allowing unsupported extensions in X.509 certificates

by Gilles Peskine

Hello, This is a discussion about the design of a new feature in X.509 parsing, and a possible deprecation of MBEDTLS_X509_ALLOW_UNSUPPORTED_CRITICAL_EXTENSION. Normally, when mbedtls_x509_crt_parse() (specifically x509_get_crt_ext()) encounters an extension that it doesn't support (unknown OID), it rejects the certificate if the extension is marked as critical and ignores it otherwise. This is usually the right thing. The application can inspect all extensions, including ignored ones, in crt->v3_ext. However there are use cases where it's useful to pass extensions through to the application and let the application decide, even for critical extensions. There's a compilation flag MBEDTLS_X509_ALLOW_UNSUPPORTED_CRITICAL_EXTENSION (default off) which causes critical extensions to be ignored. However the application must then parse the extension list again to check for all critical extensions, including ones that it doesn't support. https://github.com/ARMmbed/mbedtls/pull/1425 proposes to give the application better control. At least the application should be able to specify at runtime which extensions it allows. And perhaps the parser should provide pointers to the extensions that it finds. The design needs to reconcile several aspects, in particular: • With default compile-time and run-time options, unsupported critical extensions must be rejected, both for security and for backward compatibility. • With MBEDTLS_X509_ALLOW_UNSUPPORTED_CRITICAL_EXTENSION and default run-time options, all critical extensions must be accepted, for backward compatibility. • It's nicer if the library includes knowledge about extension OIDs. However this needs to be balanced against the needs of embedded systems where code size is important and the current size of oid.o is already a problem. • Compile-time options increase the testing burden, so it's better not to add one. And non-default compile-time options aren't useful for platforms that use a shared library built by a distribution. With these considerations, how should a runtime mechanism to select pass-through critical extensions be implemented? Can we do it without a new compile-time option and without increasing the code size? Should the new mechanism be present in the default build, only with MBEDTLS_X509_ALLOW_UNSUPPORTED_CRITICAL_EXTENSION or only with a new compile-time option? MBEDTLS_X509_ALLOW_UNSUPPORTED_CRITICAL_EXTENSION has been around since before my time. I don't know who might be using it. Should we deprecate it if there's a more flexible runtime mechanism that doesn't involve turning it on? -- Gilles Peskine Mbed TLS developer

5 years, 8 months

1
0
0 0

Re: [mbed-tls] Static Memory allocation Buffer Size for DTLS #3146

by Manuel Pegourie-Gonnard

Hi, > I am not sure how much memory to assign? I don't think there's a simple answer to that. I think the best you can do is measure how much memory is consumed in your workflow, and add a margin. When doing measurements, you should keep in mind that DTLS handshakes may consume more memory when happening over an unreliable transport, as it then needs to cache out-of-order messages, so you might want to use something like our programs/test/udp_proxy to simulate an unreliable link for you measurements. Also, the size of the messages exchanged (and potentially cached) depends on the size of the certificate chain, so you'll want to do you measurements with a configuration as close as possible to the final one. > > Current use: 33 blocks / 2508 bytes, max: 99 blocks / 5392 bytes (total 8560 bytes), alloc / free: 8803 / 8771 > What is blocks here and how many bytes per block? > My understanding is that - out of 99 blocks, 33 blocks are used. Is it right? In this context, a block just means an area of memory that is or was allocated. So for example if you do `malloc(128); malloc(1024);` you'll have two blocks used, the first being 128 bytes (plus overhead) and the second 1024 bytes (plus overhead). There is no fixed number or size of blocks in the allocator, so here the "max" means the peak of memory consumption - at that time, 5392 bytes had been allocated, over 99 blocks. You'll notice our allocator has a pretty large overhead: when adding administrative data used by the allocator, the peak memory consumption was actually 8560 bytes, out of which only 5392 were actually available to the application. > Does the memory fragmentation and de-fragmentation is handled inside mbedTLS itself? No, the provided allocator is very basic and doesn't protect against memory fragmentation. > And also after every handshake, does it release the used memory buffer for the connection? Once the handshake is complete, all the RAM that was allocated just for the handshake is freed, and the only buffers that are kept are those that are still necessary for the rest of the connection. Hope that helps! Best regards, Manuel.

5 years, 8 months

1
0
0 0

question: SIGPIPE handling

by Anibal Portero

Hi, SIGPIPE is handled with a signal( SIGPIPE, SIG_IGN ) in mbedtls_net_connect. While the examples in programs/ssl/ssl_client1.c or programs/ssl/ssl_client2.c are calling mbedtls_net_connect, programs/ssl/mini_client.c is not, and therefore not changing the default behavior of SIGPIPE. Our client is based on mini_client.c. What would the best way to handle SIGPIPE? Would it be worth it to add signal( SIGPIPE, SIG_IGN ) to the mini_client.c example for future reference? maybe even make net_prepare() visible from outside so a mini client like application can use it? Thanks!

5 years, 8 months

1
0
0 0

Static Memory allocation Buffer Size for DTLS #3146

by ROSHINI DEVI

I am directing the issue - https://github.com/ARMmbed/mbedtls/issues/3146 The content of the issue is - Hello, Currently I am using mbed tls 2.16.3 and I am using it on STM32L4xx platform. Before I was using dynamic memory allocation (heap), now planning to shift to static memory allocation. I am using x509 ecc based certificate. I am using DTLS handshake. I am also using "mbedtls_memory_buffer_alloc_status" to print the status of static buffer. The queries are - 1. I am not sure how much memory to assign? 2. I am not able to understand the message - *Current use: 33 blocks / 2508 bytes, max: 99 blocks / 5392 bytes (total 8560 bytes), alloc / free: 8803 / 8771* What is blocks here and how many bytes per block? My understanding is that - out of 99 blocks, 33 blocks are used. Is it right? 1. Does the memory fragmentation and de-fragmentation is handled inside mbedTLS itself? And also after every handshake, does it release the used memory buffer for the connection? I need the values correct to make sure not to get the memory allocation failure Please help me in these queries.

5 years, 8 months

1
0
0 0

TLS context serialization: can it be done?

by Kuvaiskii, Dmitrii

Dear all, I have the following question. mbedTLS v2.21.0 has support for TLS context serialization in the form of two functions: `mbedtls_ssl_context_save()` and `mbedtls_ssl_context_load()`. I'm trying to use these functions in another project (Graphene, an Intel SGX framework). Slightly oversimplifying, I want to establish a secure communication channel between two different Linux processes. I'd like to persist one of them and then re-spawn it again with the communication channel intact (so that there is no need for a new TLS handshake). However, I notice that currently these functions support only DTLS 1.2, see e.g.: https://github.com/ARMmbed/mbedtls/blob/aaabe86ac1f47193f4fc499846a0b3abeae… But I want to use a normal TLS channel, in particular with a ciphersuite `MBEDTLS_TLS_PSK_WITH_AES_128_GCM_SHA256`. I commented out the checks on DTLS in these functions just to see what will happen. As expected, both functions serialized and then deserialized the context, but when doing a `write(ssl_ctx)` in one (not-persisted) process and a `read(loaded_ssl_ctx)` in another (re-spawned) process, I get an error in `mbedtls_cipher_auth_decrypt()`. Clearly, my deserialized context didn't restore some vital information on the TLS session, and this led to failure in decryption. Thus, I have two questions: 1. Is there any version of this code that also works on TLS? 2. What are the additional internal objects that must be serialized for TLS (if it makes things easier, in my particular case with AES-GCM and a pre-shared key)? I looked at the code and tried to dump more fields in `mbedtls_ssl_transform`, but it didn't help much. If you'd provide me with some pointers, I could tinker more with mbedTLS code and hopefully make it work. Thanks in advance for any pointers! -- Dmitrii

5 years, 8 months

1
0
0 0

Stability of the development environment for long-time support branches

by Gilles Peskine

Hello, In Mbed TLS long-time support branches (currently 2.7.x and 2.16.x), we make bug fixes, but we preserve backward compatibility as much as possible. This means that as much as possible, we don't change existing behavior unless it's definitely wrong, we don't add new APIs, we don't increase the code size. We also preserve backward compatibility with build and deployment processes for projects that use the library. We don't create new source files, we don't change the name of makefile targets, we don't add new tools requirements or tool version requirements to build the library and its tests, etc. For example: * We added Python as a requirement to build the tests shortly before the 2.16 release, but kept the existing Perl script in the 2.7 LTS. * We've changed config.pl to a Python script in development, but kept it in Perl in LTS branches. * We've dropped support for older Visual Studio version in development, but kept it in LTS branches. How far should this extend to non-core files, such as documentation and higher-level test scripts? For example: * We're considering tweaking the format of the ChangeLog file. Should we preserve the format strictly in LTS branches? * How about renaming ChangeLog to CHANGES or CHANGES.md? * We're considering rewriting some multi-configuration test scripts and maintainer sanity checks such as tests/scripts/depends-*.pl, tests/scripts/all.sh, tests/scripts/check-names.sh, etc., in Python. (Note that we've already done that with new scripts added to all.sh: Python was not a requirement to pass all.sh in 2.7.0, but it is now.) -- Gilles Peskine Mbed TLS developer

5 years, 8 months

1
0
0 0

Welcome to Mbed TLS @ TrustedFirmware.org

by Dan Handley

Welcome to the Mbed TLS list @ TrustedFirmware.org! This mailing list is the primary channel for public discussion, questions and announcements about the Mbed TLS project. Please use this where possible in preference to the GitHub issue tracker or private support channels. The GitHub issue tracker should still be used for raising bugs and enhancement requests (after first checking the issue doesn't already exist). Thanks and regards Dan.

5 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

mbed-tls