1

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.

3iL
  • 2,146
  • 2
  • 23
  • 47
Freedlight
  • 33
  • 5
  • 1
    Hi @Freedlight, I've asked the wolfSSL engineer that did the work on the ATECC508A/608A wolfSSL product to reach out if he has a chance. The ATECC508/608 product from wolfSSL is a solution for offloading ECC key operations to a Microchip (formerly Atmel) piece of hardware dedicated to ECC key management for users who are unfamiliar with the part and curious about this topic. JFYI for best response times feel free to reach out to us at support@wolfssl.com. – Kaleb Jun 13 '19 at 14:57

2 Answers2

1

It turns out that internally, WolfSSL calls out to atcab_ecdh_enc(), which intends to do an encrypted read from (slot+1). The default configuration for the ATECC chip sets slot 3 sets this to never read. WolfSSL suggests a configuration different from the MicroChip standard, which (ahem, cheap) companies like mine don't want to pay extra for. So, it works with the ATECC configuration as WolfSSL specifies it, but does not work with the default configuration.

Our fix was to call atcab_ecdh() instead, which avoids the encrypted read, and passes the pre-master secret key back directly from the temp register. This appears to work correctly (although I'm still testing). MicroChip FAE assures me that this is not a security risk.

Thanks for the response.

Kit Taylor

Freedlight
  • 33
  • 5
  • it was a pleasure to assist on this and we are pleased to hear you found a resolution. Please let us know if anything else comes up, we are always happy to help out if we can! - the wolfSSL Support Team - – Kaleb Jun 19 '19 at 14:55
0

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

Kaleb
  • 591
  • 4
  • 17