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,

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,

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

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

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 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 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,

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

Hi SRSR333,

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

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

Hi labonte_d,

These errors indicate you did not include wolfssl/options.h before any of the wolfSSL headers. When you run ./configure --enable-opensslextra is generated a file containing the build options used in wolfssl/options.h. It is important your application also includes this before any other wolfSSL headers to enable the same build options in the header.

We do support the compatibility functions mentioned above. Make sure you setup the include path for the wolfssl-root and also wolfssl-root/wolfssl. Then make sure you have wolfssl/option.sh included and then openssl/sha.h, openssl/bio.h, etc...

Let me know if that does not help.

Thanks,
David Garske, wolfSSL

Hi lili,

It is "-fomit-frame-pointer" added to the CFLAGS that you can use in debug mode to resolve this.

Thanks,
David Garske, wolfSSL