configuration issue with WolfSSL and ATECC508A

We are using the ATECC508A to support WolfSSL on a Renesas RX600 CPU (sorry - customer spec). We are trying to do TLS 1.3 on an IoT device. Software ECC mode using WolfSSL - works fine. ATECC hardware supported mode - fails with error -248 (0xF4 in cryptoauthlib). Traced the program in debugger down to the Pre-Master Secret step of the TLS 1.3 handshake, where it fails doing a read from a slot of the ATECC chip. We are using MicroChip's default provision configuration for ATECC508A. It looks like the Pre-Master Secret is calculated using private keys internally, and gets returned by encrypted read from ATECC slot3. However, the default ATECC configuration has slot 3 set to "Never Read" mode. So, no surprise that it errors.

But, this is using default configuration of the ATECC508A slots, default setting from the cryptoauthib library, and unchanged code in WolfSSL (except for added debugs). Am I missing something here?

Versions: WOlfSSL 4.0.0, CryptoAuthLib 20190304 Renesas RTOS RI600v4

Any suggestions as to other things to look at? I can provide user_settings.h, all the logs you could possibly want, etc. Thanks in advance for any ideas.

Solution

Original answer posted here: https://www.wolfssl.com/forums/topic1396-configuration-issue-with-wolfssl-and-atecc508a.html

Begin Quote

The call to generate an ECC shared secret uses an encrypted channel [which] requires a paired encryption key. The default wolfSSL examples use atmel_get_enc_key_default, which is all 0xFF's. [One] should override this function with [their] own implementation and key. This can be done at build-time using ATECC_GET_ENC_KEY.

If [one would] like to use a different slot for the ephemeral key generation [the user] can override at build time with macro ATECC_SLOT_ECDHE_PRIV or at runtime by registering a slot allocator using atmel_set_slot_allocator. [A user] can test if its the encryption key by replacing the atcab_ecdh_enc with atcab_ecdh in atmel_ecc_create_pms.

Also the ATECC chips have a watchdog that will occur if the chip isn't put into idle state when done. [User will] notice calls to atcab_idle in [] wolfcrypt/port/atmel/atmel.c to resolve this.

Feel free to email [the wolfSSL support team] directly at support@wolfssl.com with [] user_settings.h and logs. These emails get directed [] to [the wolfSSL] ZenDesk system and [one of our engineers will] make sure and grab the incoming ticket.

Thanks,

[D.G.], wolfSSL

End Quote