ESP32: TLS (безопасность транспортного уровня) и устройства IoT

TLS (transport layer security) - это компонент безопасности в привычном протоколе https, который используется для обеспечения безопасности в Интернете. TLS соединение между устройством и сервером гарантирует, что обмен данными между ними защищен от множества возможных угроз на ненадежном носителе. Соединение TLS обычно включает взаимную аутентификацию взаимодействующих сторон, безопасный обмен ключами, симметричное шифрование и проверку целостности сообщений.

Рис1. TLS соединение между устройством и удаленным сервером

Как рекомендация, весь обмен данными между устройством и удаленным сервером (облаком) должен использовать TLS. Хотя протокол TLS позаботится обо всех элементах, участвующих в безопасной связи, разработчик и производитель устройств должны обратить внимание на несколько моментов при использовании этого протокола.

Сертификаты CA (проверка сервера)

Протокол TLS использует сертификат CA ( certificate authorities) для проверки того, что сервер действительно является тем, за кого он себя выдает. Скажем, ваше устройство должно отправлять данные на aws.amazon.com, сертификат CA гарантирует, что вы действительно общаетесь с aws.amazon.com, а не с кем-то, кто имитирует с помощью подмены DNS этот сервер.

Во время установления сеанса TLS сервер представляет свой сертификат устройству. Одной из частей информации, закодированной в этом сертификате, является доменное имя сервера (aws.amazon.com). Сертификат сервера должен быть подписан доверенным центром сертификации. Корневой сертификат CA (отличный от сертификата сервера), присутствующий на устройстве, помогает проверить эту подпись. Если подпись действительна, то и сертификат сервера действителен и, следовательно, доменное имя, закодированное в сертификате, является действительным. Далее, протокол TLS гарантирует, что это доменное имя в сертификате соответствует имени домена, к которому мы подключились.

Рис. 2. Проверка сертификата сервера во время инициализации TLS

Соединение TLS обычно ожидает, что сохраненный на устройстве сертификат CA будет передан ему в качестве параметра установления сеанса. Например, в ESP-IDF за это отвечает параметр cacert_pem_buf в структуре esp_tls_cfg_t.

>esp_tls_cfg_t cfg = {
  .cacert_pem_buf = server_root_cert_pem_start,
  .cacert_pem_bytes = server_root_cert_pem_end -
               server_root_cert_pem_start,
};
struct esp_tls *tls = esp_tls_conn_http_new (
  "https://aws.amazon.com", &cfg);

В приведенном выше коде server_root_cert_pem_start указывает на начало сертификата CA, встроенного в прошивку устройства.

Если сертификат не будет указан, то и проверка сертификата сервера будет пропущена.

Получение корневого сертификата CA

Если ваш сервер размещен в облачной инфраструктуре и поддерживает https, то у него уже есть сертификат, подписанный каким-то центром сертификации. В этом случае вы можете получить сертификат CA вашего сервера, используя следующую команду:

$ openssl s_client -showcerts -connect {имя хоста}:443

Команда получает список сертификатов. Нижний из полученных сертификатов - это сертификат CA, который должен быть встроен в прошивку устройства.

Самоподписанные сертификаты

Обычно серверные сертификаты подписываются центром сертификации, таким как Verisign. Но у вас также есть возможность использовать свою собственную пару ключ-сертификат для подписи сертификата сервера. Это называется самоподписанный сертификат.

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

• Ответственность за безопасность закрытого ключа будет лежать на вас
• Самоподписанные сертификаты будут работать, пока клиент (в данном случае ваше устройство) находится под вашим контролем, и у вас есть возможность установить свой корневой сертификат в качестве сертификата CA на клиенте. Но, например, большинство веб-браузеров пометят сервер с самоподписанным сертификатом как угрозу безопасности, поскольку в браузерах не установлен ваш сертификат в качестве доверенного сертификата CA.

Обновление сертификатов на устройстве

Если в вашей прошивке предусмотрен сертификат CA, вы обязательно должны иметь возможность его обновления при необходимости. Как правило, вам может потребоваться обновить сертификат CA в следующих случаях:

• при смене облачного провайдера или доменного имени
• если провайдер мигрирует в другой центр сертификации
• если срок действия сертификата CA истекает

То есть, если сертификат CA встроен в прошивку устройства, вы можете обновить сертификаты CA, выполнив OTA обновление прошивки. Новая прошивка должна содержать обновленный сертификат CA, который и будет использоваться в дальнейшем.

Поскольку устройства в полевых условиях могут входить в интернет с различными интервалами, нужно гарантировать, что все устройства смогут обновить встроенное ПО вовремя, до момента полного перехода на новый сертификат. Для этого стоит предусмотреть переходный период, когда устройства смогут работать с любым из сертификатов CA, старым и новым.

В приведенном выше примере API ESP-TLS cacert_pem_buf может указывать на буфер, который содержит несколько сертификатов CA один за другим. Модуль TLS в этом случае попытается проверить сертификат сервера, используя любой из доверенных сертификатов CA из этого буфера.

Проблемы при использовании TLS

1. Требование к памяти

Каждый сеанс TLS требует некоторого количества памяти. У контроллера должно быть достаточно свободной памяти во время работы TLS. Обычно для одного сеанса требуется примерно 5–6 КБ стека и около 33–35 КБ может быть выделено из кучи. Всегда контролируйте достаточность места в куче во время сеанса TLS.

2. Шифронаборы

Во время установления сеанса TLS клиент и сервер согласовывают наилучший возможный набор шифров, который будет использоваться для сеанса. Большинство типовых наборов шифров, поддерживаемых серверами в эти дни, уже включены в IDF. Но может случиться так, что некоторые серверы используют другую комбинацию шифров.

Если ваше соединение TLS прерывается из-за несовпадения шифров, вам, возможно, придется добавить эти конкретные шифры в конфигурации SDK. Это можно сделать следующим образом:

make menuconfig --> Component configuration --> mbedTLS -->

И затем выбрать отсутствующие шифры

Обратите внимание, что включение/ отключение комплектов шифров в конфигурации SDK будет оказывать влияние на статическую и динамическую память.

3. Выявление проблем с сертификатами

Вполне вероятно, что после развертывания сертификата CA для проверки может произойти сбой в процессе TLS handshake. Обычно это случается из-за ошибки в проверке сертификата, например, если был выбран неправильный корневой сертификат CA. Дополнительную информацию о точной причине сбоя можно узнать с помощью следующего кода:

int flags = mbedtls_ssl_get_verify_result(&tls->ssl);
char buf[100] = { 0, };
mbedtls_x509_crt_verify_info(buf, sizeof(buf), " ! ", flags);
printf("Certificate Verification Failure Reason: %s\n", buf);

Производители: ESPRES

Разделы: Приемо-передатчики

Опубликовано: 19.11.2019