May 2020 - mbed-tls - lists.trustedfirmware.org

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

by Jesus Gualberto Palomo Garcia

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

3 years, 10 months

2
2
0 0

Feedback sought on a new PSA Crypto driver interface

by Gilles Peskine

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

3 years, 11 months

1
0
0 0

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

by Gilles Peskine

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

3 years, 11 months

1
0
0 0

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

by Hanno Becker

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

3 years, 11 months

2
1
0 0

support mbedTLS no entropy source

by Jesus Gualberto Palomo Garcia

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

3 years, 11 months

1
0
0 0

Re: [mbed-tls] Psk tls with trustzone

by Gilles Peskine

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

3 years, 11 months

1
0
0 0

Psk tls with trustzone

by mayuri janawad

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

3 years, 11 months

1
0
0 0

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

by Manuel Pegourie-Gonnard

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

3 years, 11 months

1
0
0 0

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

by Manuel Pegourie-Gonnard

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

3 years, 11 months

1
0
0 0

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

by Manuel Pegourie-Gonnard

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

3 years, 11 months

2
1
0 0

2024

2023

2022

2021

2020

mbed-tls May 2020