проблема конфигурации с WolfSSL и ATECC508A - PullRequest
Новая
       49

проблема конфигурации с WolfSSL и ATECC508A

1 голос
/ 13 июня 2019

Мы используем ATECC508A для поддержки WolfSSL на Renesas RX600 CPU (извините - спецификация клиента).Мы пытаемся сделать TLS 1.3 на устройстве IoT.Программный режим ECC с использованием WolfSSL - работает нормально.ATECC аппаратно поддерживаемый режим - завершается с ошибкой -248 (0xF4 в cryptoauthlib).Отследил программу в отладчике до шага Pre-Master Secret рукопожатия TLS 1.3, где он не может выполнить чтение из слота чипа ATECC.Мы используем конфигурацию обеспечения по умолчанию MicroChip для ATECC508A.Похоже, что Pre-Master Secret рассчитывается внутренне с использованием закрытых ключей и возвращается при зашифрованном чтении из ATECC slot3.Однако в конфигурации ATECC по умолчанию для слота 3 установлен режим «Никогда не читать».Поэтому неудивительно, что это ошибки.

Но при этом используется конфигурация по умолчанию для слотов ATECC508A, настройка по умолчанию из библиотеки cryptoauthib и неизменный код в WolfSSL (кроме добавленных отладок),Я что-то здесь упускаю?

Версии: WOlfSSL 4.0.0, CryptoAuthLib 20190304 Renesas RTOS RI600v4

Есть какие-либо предложения относительно других вещей, на которые следует обратить внимание?Я могу предоставить user_settings.h, все журналы, которые вы могли бы хотеть, и т. Д. Заранее спасибо за любые идеи.

Ответы [ 2 ]

1 голос
/ 19 июня 2019

Оказывается, что внутренне WolfSSL вызывает atcab_ecdh_enc (), которая намеревается сделать зашифрованное чтение из (slot + 1). Конфигурация по умолчанию для слота 3 набора микросхем ATECC устанавливает это значение как никогда не считываемое. WolfSSL предлагает конфигурацию, отличную от стандарта MicroChip, за которую (хм, дешево) такие компании, как моя, не хотят доплачивать. Таким образом, он работает с конфигурацией ATECC, как указано в WolfSSL, но не работает с конфигурацией default .

Наше исправление заключалось в том, чтобы вместо этого вызывать atcab_ecdh (), что исключает зашифрованное чтение и передает секретный ключ перед главным мастером обратно непосредственно из временного регистра. Кажется, это работает правильно (хотя я все еще тестирую) MicroChip FAE уверяет меня, что это не угроза безопасности.

Спасибо за ответ.

Кит Тейлор

0 голосов
/ 14 июня 2019

Оригинальный ответ выложен здесь: https://www.wolfssl.com/forums/topic1396-configuration-issue-with-wolfssl-and-atecc508a.html

Начать цитату

При вызове для генерации общего секрета ECC используется зашифрованный канал. [который] требует парного ключа шифрования. Примеры wolfSSL по умолчанию используйте atmel_get_enc_key_default, который равен 0xFF. [Кто-то должен переопределите эту функцию с помощью [их] собственной реализации и ключа. Это может быть сделано во время сборки, используя ATECC_GET_ENC_KEY.

Если [один] хотел бы использовать другой слот для генерации эфемерного ключа [пользователь] может переопределить во время сборки с помощью макроса ATECC_SLOT_ECDHE_PRIV или во время выполнения путем регистрации распределителя слотов с помощью atmel_set_slot_allocator. [Пользователь] может проверить, является ли его ключ шифрования замена atcab_ecdh_enc на atcab_ecdh в atmel_ecc_create_pms.

Также у чипов ATECC есть сторожевой таймер, который появится, если чип не будет положить в свободное состояние, когда закончите. [Пользователь] заметит звонки на atcab_idle в [] wolfcrypt / port / atmel / atmel.c, чтобы решить эту проблему.

Не стесняйтесь, пишите [службе поддержки wolfSSL] прямо на support@wolfssl.com с [] user_settings.h и журналами. Эти письма направляются [] на [wolfSSL] ZenDesk система и [один из наших инженеров] удостоверится и заберут входящий билет.

Спасибо

[D.G.], WolfSSL

Конец цитаты

...