Hi artur,

The issue that debug is trying to show is that the server doesn't have an ECC key or certificate.
Please try the following server command line:

./example/server/server -l TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 -c ./certs/server-ecc-rsa.pem -k ./certs/ecckey.pem

Alternatively, if you are using ECC for all certificates in the chain, then this pair of command lines show the use:

./example/server/server -l TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 -c ./certs/server-ecc.pem -k ./certs/ecckey.pem

./example/client/client -l TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 -A ./certs/ca-ecc-cert.pem

Note that, by default, the client and server will use RSA keys and certificates.
These command lines are explicitly loading ECC keys and certificates. If you compile out RSA, then ECC keys and certificates are used by default.

Let us know if this works for you.

Sean

--
Sean Parkinson, wolfSSL
Senior Software Engineer

Hi Alex,

David asked me if I had any thoughts on this.

ECIES is about securely sending a message from the client to the server.
The client uses a server's public, along with an ephemeral key, to create a secret that becomes the encryption key for an algorithm like AES.
Only the owner of the private key corresponding to the public key used can decrypt the message.
The client does not know who the public key is for unless PKI is used.
The server does not know who the client is.

PKI is used to authenticate the owner of the public key.
A certificate wraps the public key with information that identifies the server and the a chain of certificate is used to authenticate the certificate up to a root of trust. The root of trust is a known trusted certificate.

From your postings, you want to authenticate the client.
Creating an ephemeral key and signing is not going to allow the server to authenticate the client.
Any client can send a message with any ephemeral key.
PKI, using certificates, should be used again to authenticate the client's public key.

Does any of this help?

Sean Parkinson, wolfSSL

Hi Christos,

It appears you want to replace our internal format of the ticket data.
CreateTicket() is where this is created and DoClientTicket() processes the internal data.

You will need to modify these functions to handle the format that you need.

Sean

Hi Remy,

I'm not sure what's going wrong here.
The function Pkcs11EcKeyGen() is calling Pkcs11GetEccPublicKey() which will fail when the key doesn't load.
Does your version of wc_pkcs11.c have this call sequence?

Note: WOLFSSL_DEBUG_PKCS11 will show more debug information about the PKCS #11 calls.

Thanks,
Sean Parkinson, wolfSSL

Hi @CGH,

I'm surprised that it isn't using TLS 1.2!
The client method only allows use of the TLS 1.2 protocol.
I'll have to think on this.

Have you replaced the HMAC or hash implementation with a hardware one?

Sean

--
Sean Parkinson, wolfSSL
Senior Software Engineer

Hi @CGH,

Looking at the code, good will be zero when everything works.
That means that the bits are flipped and good will be all 1s.
Then good is reduced down to a single bit and therefore will have a value of 1.
Therefore ret is unchanged when things work.

Can you confirm that good is 0 before negation and that good is 0 before subtracting from 1?
Also, can you give me a context in which you are testing? That is, which client/servers are using.

Thanks,
Sean
--
Sean Parkinson, wolfSSL
Senior Software Engineer