• Registered: 2019-06-12
  • Posts: 2

Topic: configuration issue with WolfSSL and ATECC508A

This may not be the right place for this question, but I suspect you guys will tell me that smile

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?

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.

Kit Taylor
Embedded Software Engineer
Mitsubishi

Share

  • Registered: 2019-06-12
  • Posts: 2

Re: configuration issue with WolfSSL and ATECC508A

Forgot to add: WolfSSL v4.0.0, CryptoAuthLib 20190304, Renesas RTOS RI600v4

Kit

Share

  • From: Bozeman
  • Registered: 2014-05-09
  • Posts: 777

Re: configuration issue with WolfSSL and ATECC508A

Hi @ktaylor,

No this is a fine place. For best response times and turnaround on questions you can email our support staff directly at support@wolfssl.com and connect with one of our engineers more directly but we do monitor both here and stack overflow as well (Saw your other copy there this morning when I got into work:  https://stackoverflow.com/questions/565 … -atecc508a

I've asked David Garske of wolfSSL to reach out when he has time, he's currently traveling for a trade event but should be back soon. David did all of the ATECC 508/608A work for us and might have an idea on how to resolve the issue you are facing.

While you're waiting for feedback from David would it be possible for you to share a bit about the project and your company? If you do not wish to disclose those details on a public forum please reach out to support@wolfssl.com for sharing project/entity details. If it helps we can setup an intro call and perhaps provide a venue for you to speak with David in person. If that would be helpful let me know and I'll ask one of our business directors to setup an introductory call to go over your current project and introduce you to wolfSSL and our organization.

Warm Regards,

K

Kaleb J. Himes's Website

Share

  • Registered: 2015-10-07
  • Posts: 430

Re: configuration issue with WolfSSL and ATECC508A

Hi Kit,

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

If you'd like to use a different slot for the ephemeral key generation you can override at build time with macro `ATECC_SLOT_ECDHE_PRIV` or at runtime by registering a slot allocator using `atmel_set_slot_allocator`.

You 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. You'll notice calls to `atcab_idle` in our wolfcrypt/port/atmel/atmel.c to resolve this.

Feel free to email us directly at support@wolfssl.com with your user_settings.h and logs. These emails get directed into our ZenDesk system and I'll make sure and grab the incoming ticket.

Thanks,
David Garske, wolfSSL

Share