- mbed-tls - lists.trustedfirmware.org

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

4 years, 5 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.

4 years, 5 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

4 years, 5 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

4 years, 5 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.

4 years, 5 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.

4 years, 5 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.

4 years, 5 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 >

4 years, 5 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.

4 years, 5 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.

4 years, 5 months

1
0
0 0

2024

2023

2022

2021

2020

mbed-tls