Как более детально работать с ATECCx08?

dudanov · 21.Ноябрь.2022 05:00:54

Сомневаюсь, что поможет. Стандартный stretch openvpn уже имеет ключ --engine, но не может загружать движок ateccx08, так как собирается с другой (не вашей) версией openssl. К тому же не умеет парсить дополнительный параметр для движка в опции key (не распознает начало строки engine: как параметр, а пытается обращаться к файлу).

# ldd `which openvpn` | grep ssl
        libssl.so.1.0.2 => /usr/lib/arm-linux-gnueabihf/libssl.so.1.0.2 (0xb6c0e000)

# ldd `which openssl` | grep ssl
        libssl.so.1.1 => /usr/lib/arm-linux-gnueabihf/libssl.so.1.1 (0xb6e17000)

И репозиторий testing для bullseye разве совместим со stretch?

UPD: прочитал о переходе на bullseye в testing. Завтра попробую.

dudanov · 22.Ноябрь.2022 10:43:55

Перешел на bullseye testing. Ситуация следующая в отличие от stretch stable:

Теперь используемая библиотека libssl едина для openssl и openvpn, движок работы с чипом ateccx08 инициализируется успешно.

# ldd `which openssl` | grep ssl
        libssl.so.1.1 => /usr/lib/arm-linux-gnueabihf/libssl.so.1.1 (0xb6e60000)

# ldd `which openvpn` | grep ssl
        libssl.so.1.1 => /usr/lib/arm-linux-gnueabihf/libssl.so.1.1 (0xb6dd5000)

# openvpn --show-engines
OpenSSL Crypto Engines

Dynamic engine loading support [dynamic]
Microchip ATECCx08 Engine [ateccx08]

В openssl вывод доступных движков следующий и содержит ошибку неразрешимого символа EVP_PKEY_get_base_id (UPD: с этим разобрался, это не ошибка, а средство распознавания, что движок несовместим с openssl-1.1.x и написан для openssl-3.x. Если бы данная функция была доступна, то была бы ошибка):

# openssl engine
(dynamic) Dynamic engine loading support
(ateccx08) Microchip ATECCx08 Engine
3069833232:error:2506406A:DSO support routines:dlfcn_bind_func:could not bind to the requested symbol name:../crypto/dso/dso_dlfcn.c:188:symname(EVP_PKEY_get_base_id): /usr/lib/arm-linux-gnueabihf/engines-1.1/ateccx08.so: undefined symbol: EVP_PKEY_get_base_id
3069833232:error:2506C06A:DSO support routines:DSO_bind_func:could not bind to the requested symbol name:../crypto/dso/dso_lib.c:186:

Остается проблема с непропатченым openvpn. Не распознает ключ --key, начинающийся с engine:, как параметры движка.

# openvpn --config /etc/openvpn/tm.conf --ca /etc/openvpn/tm/ca.crt --cert /etc/openvpn/tm/device.crt --engine ateccx08 --key engine:ateccx08:ATECCx08:00:02:C0:00
2022-11-22 14:49:42 WARNING: cannot stat file 'engine:ateccx08:ATECCx08:00:02:C0:00': No such file or directory (errno=2)
Options error: --key fails with 'engine:ateccx08:ATECCx08:00:02:C0:00': No such file or directory (errno=2)
Options error: Please correct these errors.
Use --help for more information.

То есть проблема актуальна и для bullseye testing, @EvgenyBoger.

EvgenyBoger · 23.Ноябрь.2022 09:58:46

Добрый день!

openvpn в bullseye по-идее должен уметь подерживать ключик -engine. Проблема в том, что заставить работать у меня это за час не получилось: там какое-то странное поведение вокруг чтения ключей.

Боюсь, мы сможем этим заняться не раньше, чем через несколько недель.

Если что, наш патч к старому openvpn вот: openvpn-2.4.6: add support openssl engine for private key storage. · wirenboard/contrib@5e45a50 · GitHub . Он довольно тривиальный, может и к новому подойти.

Прошу ещё описать задачу с точки зрения бизнеса: зачем вам это надо, сколько контроллеров купили и сколько планируете и т.п. Можно в личку здесь или на boger@wirenboard.com . От этого зависит приоритет у разработчиков.

dudanov · 23.Ноябрь.2022 11:58:04

Добрый день, @EvgenyBoger

Да, openvpn “из коробки” не умеет читать параметр --key в части передачи параметра движку. Самым лучшим выходом было бы создание темы для общения с основным разработчиком openvpn для определения более корректного, с его точки зрения, способа передачи параметров криптодвижкам openssl. А потом последующая реализация и включение в основную ветку проекта.

Описание задачи тривиально: удаленный сбор данных с ЛАСУ промышленного оборудования, используя OpenVPN. Если есть возможность сокрытия приватных ключей с помощью крипточипа, то почему бы не использовать. В настоящее время приобрели для тестов 2 контроллера WB7. При удачном тестировании хотим предлагать решение нашим Заказчикам в составе ЛАСУ нашего оборудования.

По срокам не критично. Торопиться не нужно. Главное правильно подойти к решению и тщательно продумать. Один вариант решения предложил выше. Передача параметров криптодвижкам SSL нужна в любом случае. Рано или поздно к разработчикам OpenVPN обратятся с этим. И если это будете Вы, то это было бы еще одним вкладом в свободное ПО.

EvgenyBoger · 23.Ноябрь.2022 13:19:04

так вот по-моему умеет, там есть это в коде. Но что-то там работает не так, как нужно. Думаю, разберёмся.

dudanov · 23.Ноябрь.2022 14:02:51

Надо посмотреть. Возможно в новой версии OpenVPN добавили, но в старой не видел, да и документацию читал по опциям, не было ничего подобного. Посмотрю, может проблема то решена уже. Отпишусь в этом же сообщении обновлением.

UPD: Да, новый openvpn поддерживает передачу параметров движкам SSL. Разобрался сейчас в связке кода всех 3-х проектов: cryptoauth-openssl-engine, openssl, openvpn. Вообщем, openvpn нужно либо ключом key передавать имя файла с содержимым MAC чипа вида: ATECCx08:00:02:C0:00, либо использовать inline параметр key в конфигурационном файле профиля клиента openvpn:

<key>
ATECCx08:00:02:C0:00
</key>

Сначала openvpn пытается интерпретировать данные, как приватный ключ в PEM-формате, и только после неудачи предпринимает попытку передачи в криптографический движок, указанный в параметре engine, делая соответствующие записи в журнал или стандарный вывод ошибок. Это поведение не описано в официальной документации и вполне в будущем может изменится (а возможно и обретет статус официального).

Но не все так просто. Возникает ошибка при работе движка cryptoauth-openssl-engine с кодом 0xF4 (что определено в коде как ATCA_EXECUTION_ERROR), по всей видимости чип возвращает ошибку выполнения команды.

Причина может быть в некотором различии использования в openssl и openvpn. Первая, которая успешно работает с чипом, инициализирует движок вызовом ENGINE_by_id, затем вызывает требуемый функционал и сразу освобождает ресурсы с помощью ENGINE_free. openvpn так же инициализирует, но не освобождает ресурсы до выхода из процесса, вызывая требуемые функции уже между ENGINE_init и ENGINE_finish. Последние определены и используются в библиотеке движка крипточипа, но вот вопрос: корректна ли их реализация?.. @EvgenyBoger

Часть конфига:

ca /etc/openvpn/tm/ca.crt
cert /etc/openvpn/tm/device.crt
engine ateccx08
<key>
ATECCx08:00:02:C0:00
</key>

Вывод:

# openvpn --config tm.conf
2022-11-24 08:35:09 OpenVPN 2.5.1 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2021
2022-11-24 08:35:09 library versions: OpenSSL 1.1.1n  15 Mar 2022, LZO 2.10
2022-11-24 08:35:09 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2022-11-24 08:35:09 Initializing OpenSSL support for engine 'ateccx08'
2022-11-24 08:35:09 OpenSSL: error:0909006C:PEM routines:get_name:no start line
2022-11-24 08:35:09 PEM_read_bio failed, now trying engine method to load private key
Command atcab_checkmac is failed with status 0xf4
2022-11-24 08:35:10 OpenSSL: error:26096080:engine routines:ENGINE_load_private_key:failed loading private key
2022-11-24 08:35:10 Engine could not load key file
2022-11-24 08:35:10 Exiting due to fatal error

dudanov · 24.Ноябрь.2022 10:11:13

Есть желание разобраться с этим вопросом до конца.

Как собрать библиотеку cryptoauth-openssl-engine для testing bullseye? Хочу собрать с ключом ECC_DEBUG который выводит дополнительную отладочную информацию.

Наверняка есть система сборки, которая легко соберет готовый deb пакет libateccssl.

UPD: Разобрался. Вывод теперь выглядит так:

# openvpn --config tm.conf
$$eccx08_engine.c:307:bind_helper(): Entered
$$eccx08_eckey_meth.c:1005:eccx08_ec_init(): Entered
$$eccx08_ecdsa_sign.c:416:eccx08_ecdsa_init_meth(): Entered
$$eccx08_eckey_meth.c:1068:eccx08_pkey_meth_init(): Entered
$$eccx08_engine.c:410:bind_helper(): Succeeded
$$eccx08_engine.c:248:eccx08_init(): Entered
2022-11-24 15:04:53 OpenVPN 2.5.1 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2021
2022-11-24 15:04:53 library versions: OpenSSL 1.1.1n  15 Mar 2022, LZO 2.10
2022-11-24 15:04:53 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
$$eccx08_eckey_meth.c:900:eccx08_pmeth_selector(): Entered
$$eccx08_eckey_meth.c:900:eccx08_pmeth_selector(): Entered
2022-11-24 15:04:53 Initializing OpenSSL support for engine 'ateccx08'
2022-11-24 15:04:53 OpenSSL: error:0909006C:PEM routines:get_name:no start line
2022-11-24 15:04:53 PEM_read_bio failed, now trying engine method to load private key
$$eccx08_eckey_meth.c:613:eccx08_load_privkey(): Entered
$$eccx08_auth.c:121:eccx08_cbdata_to_password(): Raw password:
$$eccx08_eckey_meth.c:488:eccx08_load_pubkey_internal(): Entered
$$eccx08_eckey_meth.c:162:eccx08_eckey_new_key(): Entered
$$eccx08_engine.c:79:eccx08_global_lock(): About to lock mutex in global_lock
$$eccx08_eckey_meth.c:521:eccx08_load_pubkey_internal(): Got ATECC
$$eccx08_auth.c:129:eccx08_auth_password(): Entered
$$eccx08_auth.c:130:eccx08_auth_password(): Slot: 41675, password: ▒▒q
Command atcab_checkmac is failed with status 0xf4
$$eccx08_eckey_meth.c:528:eccx08_load_pubkey_internal(): ATECC auth failed
2022-11-24 15:04:53 OpenSSL: error:26096080:engine routines:ENGINE_load_private_key:failed loading private key
2022-11-24 15:04:53 Engine could not load key file
2022-11-24 15:04:53 Exiting due to fatal error

dudanov · 25.Ноябрь.2022 10:15:49

Проблема решена. Создал PR.

Движок при загрузке ключа принимает контекст и пытается интерпертировать его как указатель на строку вида “ячейка:пароль”. Если в случае с openssl такое поведение срабатывает, так как в начале передаваемой структуры указатель на строку из параметра -passin, то openvpn передает более сложную структуру SSL_CTX. Так как в Вашем патче пароль не используется, то обошелся простой проверкой, что передаваемая строка требуемого вида, что в любом случае не помешает.

webconn · 02.Декабрь.2022 06:34:27

PR приняли, спасибо! Обновление выпустим в течение пары рабочих дней, в том числе в stable.