1

(9 replies, posted in wolfSSL (formerly CyaSSL))

Hi MO380,

This means you have WOLFSSL_USER_IO defined, which requires setting your own TLS send/recv callbacks. If you remove WOLFSSL_USER_IO then it will attempt to use our default socket implementations in src/wolfio.c. These support POSIX and LWIP for example.

You can find examples for using the IO callbacks here:
https://github.com/wolfSSL/wolfssl-exam … aster/lwip

You can see our user manual section here:
https://www.wolfssl.com/documentation/m … sl_user_io

Thanks,
David Garske, wolfSSL

2

(1 replies, posted in wolfCrypt)

Hi Alex,

What ECC curve(s) are you trying to use? I assume NIST Prime 256-bit (SECP256R1)?

Please try with our single precision math and assembly options. This should make a greater than 10x improvement.

#define WOLFSSL_HAVE_SP_ECC
#define WOLFSSL_SP_ARM_CORTEX_M_ASM
#define WOLFSSL_SP_SMALL      /* use smaller version of code */

These are documented here:
https://www.wolfssl.com/documentation/m … th-support

We have a good section that covers our math options here:
https://www.wolfssl.com/documentation/m … th-options

Thanks,
David Garske, wolfSSL

Hi Sushanth,

Thanks for your interest in using wolfSSL and TLS v1.3 on the STM32 targets.

* STM32F407VGT6 Cortex-M4, 1-Mbyte Flash and 192 KB RAM
* STM32G431xB Cortex-M4, 170 MHz, 128-KB Flash and 22 KB RAM

Roughly a TLS v1.3 only client session takes about 70KB flash and 20 KB RAM. These are rough estimations and I recommend you try for yourself.

Our STM32Cube pack makes it easy to evaluate in the STM32CubeIDE. See https://github.com/wolfSSL/wolfssl/tree … /STM32Cube

We have some TLS v1.3 only examples here:
https://github.com/wolfSSL/wolfssl-exam … nt-tls13.c

For building with reduced code size and memory usage see this section of the user manual:
https://www.wolfssl.com/documentation/m … code-usage
https://github.com/wolfSSL/wolfssl/blob … e.ac#L1735

I recommend using an ECC only build (disable RSA/DH), since it uses much less memory.

Looking forward to hearing your progress. If you can send a note to support@wolfssl.com and tell us more about your project that would be wonderful.

Thanks,
David Garske, wolfSSL

Hi Alex,

Have you reviewed the BTLS example that uses ECIES here?
https://github.com/wolfSSL/wolfssl-exam … btle/ecies

The public key provided there is X.963 format, which is a small ASN.1 header and public X/Y (same format TLS uses). The public key is used to derive the shared secret used for encryption. It should be the public key provided by the peer.

Note: We have several ECIES modes. Perhaps you might consider one of these?
* yes = SEC1 standard (default)
* geniv = Generate IV (WOLFSSL_ECIES_GEN_IV)
* iso18033 = ISO 18033 standard (WOLFSSL_ECIES_ISO18033)
* old = original wolfSSL algorithm (WOLFSSL_ECIES_OLD)

Thanks,
David Garske, wolfSSL

Hi Akram,

My recommendation would be to get it working without static memory and use traditional heap first. Get that working then try using static memory. You are welcome to use my code snippets. You would inject that where you create the WOLFSSL_CTX with wolfSSL_CTX_new.

Let me know how it goes.

Thanks,
David Garske, wolfSSL

Hi khalesiakram,

Your issue is the static memory feature `WOLFSSL_STATIC_MEMORY`. This is an advanced feature that replaces the XMALLOC heap calls with a static pool. This requires additional configuration to support properly.


See documentation for this feature here:
https://docs.google.com/document/d/1nST … sp=sharing

Example for setting it up with TLS here:
https://github.com/wolfSSL/wolfssl/blob … nt.c#L2053

Code example:

byte memory[80000];
byte memoryIO[34500]; /* max for IO buffer (TLS packet can be 16k) */
WOLFSSL_HEAP_HINT *heap = NULL;

if (wc_LoadStaticMemory(&heap, memory, sizeof(memory), WOLFMEM_GENERAL, 1)
        != 0) {
    err_sys("unable to load static memory");
}

ctx = wolfSSL_CTX_new_ex(method(heap), heap);
if (ctx == NULL)
    err_sys("unable to get ctx");

    if (wolfSSL_CTX_load_static_memory(&ctx, NULL, memoryIO, sizeof(memoryIO),
        WOLFMEM_IO_POOL_FIXED | WOLFMEM_TRACK_STATS, 1) != WOLFSSL_SUCCESS) {
    err_sys("unable to load static memory");
}

You can configure the memory buckets using something like this:

#define WOLFSSL_STATIC_MEMORY
#define WOLFMEM_BUCKETS 64,256,384,432,512,1632,3456,16128
#define WOLFMEM_DIST 12,6,5,3,4,2,1,1
#define LARGEST_MEM_BUCKET 16128

Thanks,
David Garske, wolfSSL

Hi khalesiakram,

This typically suggests a math failure with the ECC shared secret due to a misconfigured stack. I would suggest a few things:
1) Increase your stack space on each board. In bare-metal this is done via the linker script.
2) Run the wolfCrypt test and verify all algorithms operate correctly. See: https://github.com/wolfSSL/wolfssl/blob … le.c#L1846

If that doesn't help please share your build settings (user_settings.h or wolfSSL.I-CUBE-wolfSSL_conf.h).

Thanks,
David Garske, wolfSSL

Hi Alex,

That comment is not very clear and I am sorry. It is referring to authentication specifically which is not handled in ECIES. The idea to hash the peers public key, sign it and send back is just an example for how to implement authentication. The important thing is to sign with a long term key, not the ephemeral key.

Thanks,
David Garske, wolfSSL

Hi Alex,

This does not sound right. When you create an ECC key it generates a public and private key pair. The public portion is sent across (in the clear is fine).

The ECIES scheme itself establishes a secure channel by generating ECC keys (ephemeral / one time use), exchanging public keys and deriving a shared secret. The shared secret is then used to derive a symmetric key used for the cipher (like AES-GCM or ChaCha20/Poly1305).

If you want to authenticate in your application then on first connection you create an ECC key used for long term and provide that public key and some nonce for the peer to sign. The nonce can be random data or even a hash of the messages exchanged so far. For this to work on-going each peer should store the public key used to identify the peer as trusted. And for every connection the peer must sign something new to prove it has the private key associated with the public key.

Thanks,
David Garske, wolfSSL

Hi Alex,

If the peer generates something "random" and asks the peer to "sign" it then you know the peer has the private key. TLS does something similar by signing the digest of the handshake messages received.

Thanks,
David Garske, wolfSSL

Hi Alex,

Yes that would work fine and is known as public key authentication. Just make sure you use a different key for authentication. Typically that key is generated one time and use for all future authentications. Each side would present something to sign to prove having the private key. ECC is a very good algorithm for this.

The X.509 just adds the ability to have a chain of trust, however the overhead for certificates is quite large.

Thanks,
David Garske, wolfSSL

Hi Alex,

Thanks for your interest in our BTLE security.

ECIES typically does authentication after establishing a secure connection. For example in your application code you could require the peers to each present their signed certificates before allowing anything else.

If you want to use certificates you might consider just using TLS v1.3. See: https://github.com/wolfSSL/wolfssl-exam … r/btle/tls

Thanks,
David Garske, wolfSSL

13

(5 replies, posted in wolfSSL (formerly CyaSSL))

FYI: As a followup we did add DTLS SRTP support via https://github.com/wolfSSL/wolfssl/pull/4755 in wolfSSL v5.2.0 on Jan 20, 2022

14

(4 replies, posted in wolfSSL (formerly CyaSSL))

Hi Lili,

I believe you are trying to printf the IO buffers, which are binary (not ASCII), so printf will not work. Where did you place the printf? Perhaps you can share the code you are using?

Thanks,
David Garske, wolfSSL

15

(4 replies, posted in wolfSSL (formerly CyaSSL))

Hi lili,

See out wolfssl/test.h example for the PSK values:

/* identity is OpenSSL testing default for openssl s_client, keep same */
static const char* kIdentityStr = "Client_identity";

static WC_INLINE unsigned int my_psk_client_cb(WOLFSSL* ssl, const char* hint,
        char* identity, unsigned int id_max_len, unsigned char* key,
        unsigned int key_max_len)
{
    (void)ssl;
    (void)hint;
    (void)key_max_len;

    /* see internal.h MAX_PSK_ID_LEN for PSK identity limit */
    XSTRNCPY(identity, kIdentityStr, id_max_len);

    if (wolfSSL_GetVersion(ssl) < WOLFSSL_TLSV1_3) {
        /* test key in hex is 0x1a2b3c4d , in decimal 439,041,101 , we're using
           unsigned binary */
        key[0] = 0x1a;
        key[1] = 0x2b;
        key[2] = 0x3c;
        key[3] = 0x4d;

        return 4;   /* length of key in octets or 0 for error */
    }
    else {
        int i;
        int b = 0x01;

        for (i = 0; i < 32; i++, b += 0x22) {
            if (b >= 0x100)
                b = 0x01;
            key[i] = b;
        }

        return 32;   /* length of key in octets or 0 for error */
    }
}

These values need to be agree'd upon by both the server and client. You should use your own key.

I would also recommend setting your cipher suite list to just the PSK ones so the peer is forced to use PSK.

wolfSSL_CTX_set_cipher_list(ctx, "DHE-PSK-AES128-CBC-SHA256:ECDHE-PSK-AES128-CBC-SHA256");

The send size of 121 is a client_hello. As the client it starts the connection and sends the "client_hello" then it will try and read 5 bytes (the TLS header) then the remainder.

We have some good PSK and IO callback examples here:
https://github.com/wolfSSL/wolfssl-exam … callback.c
https://github.com/wolfSSL/wolfssl-exam … master/psk

Thanks,
David Garske, wolfSSL

Hi Sam,

I've put up the changes into PR: https://github.com/wolfSSL/wolfTPM/pull/231

The issue you reported is specific to the way you are building for 32-bit and not properly having word64 setup properly. The solution I provided simply makes use of the GCC builtin swap functions and avoids the 32 bit shifting.

Thanks,
David Garske, wolfSSL

Hi stroebeljc,

Thank you for sharing the example. The best examples are here:
https://github.com/wolfSSL/wolfssl-exam … er/certgen

I don't see an example for setting DirName, so I am having another engineer research this.

Thanks,
David Garske, wolfSSL

Hi stroebeljc,

I am not sure what you mean about the DN inside a Directory Name. Can you provide an example of what you are trying to accomplish?

Thanks,
David Garske, wolfSSL

Hi Stoebeljc,

The only other option is setting the alternate names `.altNames` as raw DER. See the example here:
https://github.com/wolfSSL/wolfssl-exam … -alt-names
https://github.com/wolfSSL/wolfssl-exam … mple.c#L68

Thanks,
David Garske, wolfSSL

Hi tpm2user,

I am not familiar with `openssl.ctx` or ` --key-context`, however I can show you have to load an external private key to the null hierarchy.

1) make sure you are using DER format (binary ASN.1, not PEM). Use `-outform der`.
2) Use `wc_RsaPrivateKeyDecode`
3) `wolfTPM2_RsaKey_WolfToTpm_ex` to load into a WOLFTPM2_KEY.

We have an example here:
https://github.com/wolfSSL/wolfTPM/blob … est.c#L431

However I don't have one loading a PEM or DER to the null hierarchy. I'll see about adding an example for this.

Thanks,
David Garske, wolfSSL

21

(5 replies, posted in wolfTPM)

Hi tpm2user,

1) Load the TPM public key into a wolfCrypt ecc_key struct: https://github.com/wolfSSL/wolfTPM/blob … ent.c#L226
2) Extract public key as DER: wc_EccPublicKeyToDer: https://github.com/wolfSSL/wolfTPM/blob … ent.c#L363
3) Use DER with wolfSSL_CTX_use_PrivateKey_buffer and WOLFSSL_FILETYPE_ASN1

Thanks,
David Garske, wolfSSL

22

(5 replies, posted in wolfTPM)

Hi tpm2user,

1) For wolfSSL when using a TPM private key for TLS you need to extract the public key and pass it to the `wolfSSL_CTX_use_PrivateKey_*` function. The TLS examples were all updated recently to do this. See PR https://github.com/wolfSSL/wolfTPM/pull/210
The use_PrivateKey functions support variations to allow using a file or buffer as PEM or DER.

2) The crypto callback requires registering a callback function (like wolfTPM2_CryptoDevCb) with a devId value. Then you use `wolfSSL_CTX_SetDevId` to tell the TLS layer and all internal keys to use the crypto callback.

Thanks,
David Garske, wolfSSL

Hi SRSR333,

FYI: The fix has also been published here:
https://github.com/wolfSSL/wolfssl/pull/5328

Thanks,
David Garske, wolfSSL

Hi celov65111,

An X.509 certificate only contains a public key.

To compare the public key of the certificate to the TPM:
1) Read the public key from the TPM using something like `wolfTPM2_ReadPublicKey`
2) Export a RSA public key DER/ASN.1 using `wolfTPM2_RsaKey_TpmToWolf` and `wc_RsaKeyToPublicDer_ex. For ECC public key you can use `wolfTPM2_EccKey_TpmToWolf` and `wc_EccPublicKeyToDer`.
3) Extract the public key from the X.509 certificate.

#include "wolfssl/wolfcrypt/settings.h"
#include "wolfssl/wolfcrypt/asn.h"

int ret;
DecodedCert cert;

InitDecodedCert(&cert, certBuffer, certLen, NULL);
ret = ParseCert(&cert, CERT_TYPE, NO_VERIFY, NULL);
if (ret == 0) {
    printf("Public Key %d\n", cert.pubKeySize);
    WOLFSSL_BUFFER(cert.publicKey, cert.pubKeySize);
    
}
FreeDecodedCert(&cert);

Also make sure you verify the signature of the certificate. You can pass `VERIFY` instead of `NO_VERIFY` on ParseCert. The 4th argument lets you pass in a Certificate Manager pointer for validating the signature against a trusted certificate. We have an example for that here: https://github.com/wolfSSL/wolfssl-exam … fybuffer.c

Thanks,
David Garske, wolfSSL

Hi celov65111,

A certificate contains a public key which is signed by another key who is trusted. To verify a certificate you only need the public key for the signer. Typically the AKID (Authority Key Identifier) is used to identify the signer key. It is a hash of the signers public key.

If a TPM private key was used to sign you only need to have the public key to verify a certificate, since a verify is a pubic only operation.

You can export a TPM RSA public key using `wolfTPM2_RsaKey_TpmToPemPub`. Or you could export a RSA public key DER/ASN.1 using `wolfTPM2_RsaKey_TpmToWolf` and `wc_RsaKeyToPublicDer_ex. For ECC public key you can use `wolfTPM2_EccKey_TpmToWolf` and `wc_EccPublicKeyToDer`.

For validating a certificate you could leverage our wolfSSL Certificate Manager to do a certificate validation. See example here:
https://github.com/wolfSSL/wolfssl-exam … fybuffer.c

If you are looking for a more direct approach you could just do:
1) Hash the certificate (minus trailing signature)
2) Use wc_ecc_verify_hash or wc_RsaSSL_VerifyInline with the public key and hash to verify signature.

For reference a KEYBLOB is key material from the TPM in a TPM format. The private key is encrypted and not usable except when loaded to the TPM. The public portion of a key blob is exportable and can be used for wolfCrypt operations using the above conversion API's.

If you have more questions if would be helpful to know more about your project. Feel free to email us directly support at wolfssl.com and reference this ticket.

Thanks,
David Garske, wolfSSL