Пример защищенного https – соединения с использованием mbed TLS

TLS (Transport Layer Security) – протокол защиты транспортного уровня, который обеспечивает защищенную передачу данных между узлами в сети Интернет (определение из Wikipedia).

Этот криптографический протокол находиться над протоколом TCP в многоуровневой модели сетевого стека, как показано на следующем рисунке.

TLS выглядит на рисунке как некоторый промежуточный слой между прикладным и транспортным уровнями. На транспортном уровне указан именно протокол TCP, поскольку TLS подразумевает установление защищенного соединения. Криптографический протокол, использующий на транспортном уровне протокол UDP называется DTLS (Datagram Transport Layer Security).

Предшественником TLS был протокол SSL (Secure Sockets Layer) – протокол уровня защищенных сокетов. После выхода версии SSL 3.0 протокол был переименован на TLS.
В основе работы протокола TLS лежит шифрование данных. Существуют два вида алгоритмов шифрования данных : симметричные и асимметричные.

Симметричные алгоритмы шифрования.

В симметричных алгоритмах шифрования для кодирования и раскодирования данных используется один и тот же ключ. Примерами симметричных алгоритмов являются алгоритмы серии AES-128/192/256. Цифра после названия указывает на длину ключа в битах. Эти алгоритмы можно использовать, например, для шифрования вашей прошивки для микроконтроллера.

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

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

Таким образом реализуется защита от кражи прошивки и защита от подмены оригинальной прошивки на прошивку от злоумышленника.

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

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

Асимметричные алгоритмы шифрования.

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

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

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

Примером асимметричных алгоритмов шифрования является RSA (аббревиатура от фамилий Rivest, Shamit, Adleman).

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

Для шифрования данных криптосистемы с открытым ключем используют так называемые односторонние функции :

Если известно значение «x» , то вычислить значение «y» достаточно просто. Но если известно значение “y” и зависимость y = f(x) , то вычислить значение «x» практически невозможно за обозримый интервал времени.

В алгоритме RSA для шифрования данных в качестве односторонней функции используется функция возведения в степень по модулю:

На языке C это выглядит следующим образом :

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

Алгоритм шифрования сеансового ключа.

Тут все достаточно просто, описанный алгоритм шифрования данных асимметричным алгоритмом применяется для передачи закрытого ключа симметричного алгоритма (например AES-128) , так называемого сеансового ключа.

Процедура передачи сеансового ключа выполняется каждый раз при установлении соединения, дальше данные шифруются переданным закрытым ключем и расшифровываются тем же сеансовым ключем.

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

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

После закрытия соединения сеансовый ключ больше не используется, а при открытии нового соединения создается уже новый сеансовый ключ.

Цифровая подпись.

Цифровая подпись является аналогом подписи человека ,сделанной от руки. Она обеспечивает аутентификацию автора сообщения. Кроме того цифровая подпись обеспечивает подтверждение целостности данных сообщения .

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

Допустим сторона А хочет передать стороне В подписанное сообщение. Она берет это сообщение и создает с помощью своего закрытого ключа цифровую подпись (по сути просто шифрует сообщение). Дальше сторона А передает стороне В свое сообщение в исходном виде вместе с цифровой подписью. Сторона В принимает подписанное сообщение и с помощью открытого ключа, полученного от А ранее, расшифровывает цифровую подпись и получает из нее исходное сообщение. Дальше путем сравнения принятого и расшифрованного сообщения сторона В может удостовериться в целостности и аутентичности принятого сообщения.

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

Но поскольку длина сообщения может быть достаточно большой, то на практике чаще всего подписываются не сами данные сообщения, а хеш — сумма (алгоритмы SHA-1, SHA-2), вычисленная по этим данным. Далее сравнивается вычисленная по данным сообщения и полученная из цифровой подписи хеш- сумма.

Сертификат открытого ключа.

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

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

Рассмотрим более распространенный вариант с сертификатом для сервера. Допустим вы владеете неким ресурсом (web-сервером) и хотите получить сертификат для безопасного обмена данными с использованием https протокола.

В центре выдачи сертификатов выдается сертификат, который помимо открытого ключа содержит информацию о владельце сертификата, срок его действия, URI(Universal Resource Identifier) — универсальный идентификатор ресурса и другую информацию.

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

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

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

Таким образом сертификат гарантирует подлинность открытого ключа запрашиваемого ресурса.

Поскольку подписать все сертификаты одним центром выдачи сертификатов (или удостоверяющим центром (УЦ)) не представляется возможным, то на практике используется так называемая цепочка доверия.

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

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

Сертификат X.509.

Для сертификата публичного ключа необходим стандарт, который будет описывать формат данных сертификата, процедуру распределения открытых ключей, формат списка аннулированных сертификатов, алгоритм проверки подписи. Таким стандартом является стандарт X.509 .

В стандарте X.509 также описаны расширения файлов сертификатов и форматы этих файлов :

• .CER – сертификат или цепь сертификатов, закодированных в формате CER
• .DER – сертификат , закодированный в формате DER
• .PEM – сертификат, закодированный в формате DER, использующий кодировку Base64 и заключенный между строками «—— BEGIN CERTIFICATE ——» и «—— END CERTIFICATE ——»
• .P7B, .P7C – PKCS#7 содержит несколько сертификатов или CRL(список аннулированных сертификатов)
• .P12 – PKCS#12 содержит блок, содержащий одновременно и закрытый ключ, и сертификат в зашифрованном виде.
• .PFX – PFX предшественник PKCS#12, также содержит блок закрытого ключа и сертификата

PKI.

Инфраструктура открытых ключей (PKI (Public Key Infrastructure)) имеет иерархическую структуру, как показано на следующем рисунке :

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

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

Для регистрации пользователей обычно используется регистрационный центр (РЦ).
УЦ доверяет РЦ проверку информации о субъекте. РЦ проверяет правильность информации и подписывает с помощью своего ключа. Далее РЦ передает информацию УЦ, который проверяет ключ РЦ и выписывает сертификат.

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

Протокол HTTPS.

Протокол HTTPS принципиально не отличается от протокола HTTP. Основным отличием HTTPS от HTTP является поддержка шифрования передаваемых данных с помощью SSL или TLS. В отличии от HTTP, который по-умолчанию использует TCP -порт номер 80, HTTPS по-умолчанию прослушивает TCP -порт номер 443 .

При установлении соединения с сервером клиент использует так называемый Handshake protocol (протокол рукопожатия). Во время установления соединения клиент передает серверу поддерживаемые алгоритмы шифрования, сервер выбирает из них самые криптостойкие и договаривается с клиентом использовать именно этот набор алгоритмов.
Также сервер передает клиенту свой сертификат, клиент проверяет подлинность сертификата сервера и на основании результатов проверки принимает решение о продолжении или прекращении соединения.

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

SSL/TLS Handshake протокол схематически описан на следующем рисунке.

1. Клиент отправляет серверу сообщение ClientHello , в котором указывает версию протокола SSL/TLS, набор поддерживаемых алгоритмов шифрования и методов компрессии данных.
2. Сервер отвечает клиенту сообщением ServerHello, в котором подтверждает использование общих с клиентом криптографических алгоритмов, отправляет идентификатор сессии и сертификат сервера с открытым ключем.
3. Клиент проверяет сертификат сервера.
4. Клиент генерирует сессионный ключ (AES), шифрует его открытым ключем сервера и отправляет серверу.
5. Финишное сообщение шифруется сессионным ключем и отправляется серверу.
6. Финишное сообщение от сервера шифруется сессионным ключем и отправляется клиенту.

Весь последующий обмен данными между клиентом и сервером шифруется с помощью сессионного ключа.

Mbed TLS.

Библиотека mbedTLS ранее была известна под названием PolarSSL, пока компания ARM не приобрела ее для использования в своем IoT (Internet of things) проекте под названием ARM mbed.

Библиотека mbedTLS распространяется под лицензией Apache 2, которая в отличии от GPL лицензии позволяет не выкладывать в открытый доступ исходники ваших проектов, разработанные с использованием mbed TLS, что позволяет законно использовать ее в закрытых прошивках.

Библиотека содержит различные алгоритмы шифрования, написана она на языке С и имеет модульную структуру. Модули библиотеки реализованы независимо друг от друга , что позволяет выполнить гибкую конфигурацию библиотеки mbed TLS.

Для конфигурирования используется конфигурационный заголовочный файл mbedtls_config.h . Если вы ранее использовали FreeRTOS, FatFs или LwIP , то способ настройки mbed TLS для вас не будет новым. Но будьте готовы к тому , что сможете с легкостью потеряться в опциях mbed TLS, которых там уж очень много.

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

Как я уже упоминал, mbed TLS входит в состав фреймворка ARM mbed, предназначенного для компиляции под микроконтроллеры ARM. ARM mbed построен на основе RTOS mbed OS, использует для написания программ язык C++. Системный уровень ARM mbed тщательно скрыт от пользователя (я имею ввиду несколько прослоек кода), предоставляя некую абстракцию для доступа к аппаратным ресурсам (на подобии Arduino).

Поэтому изучать пример TLS – клиента для ARM mbed есть смысл, если вы планируете использовать для работы только этот фреймворк.

Также библиотека mbed TLS входит в состав пакета STM32CubeMX, предназначенного для автоматической генерации проектов и кода инициализации периферии микроконтроллеров STM32.

Пакет STM32CubeMX содержит множество примеров кода, в том числе пример TLS – клиента. На основе этого примера я решил строить свой пример для создания безопасного соединения между платой NUCLEO_F429ZI и Raspberry Pi 3.

Пример клиента от STMicroelectronics предназначен для запуска на отладочных платах STM324x9I_EVAL и в качестве сервера использует утилиту ssl_server.exe , которая поставляется вместе с примерами. В качестве сертификата открытого ключа используется тестовый сертификат из библиотеки mbed TLS.

Перенести логику работы клиента на плату NUCLEO_F429ZI не составило для меня большого труда, пример сразу заработал с сервером ssl_server.exe .

Сложности начались при попытке установить соединение с сервером Apache на плате Raspberry Pi 3 с использованием собственного самоподписанного сертификата.
Причем для решения большинства возникших проблем понадобилось всего-лишь правильно настроить mbed TLS в файле mbedtls_config.h.

Итак, настало время поделиться опытом настройки защищенного соединения между HTTPS – сервером и клиентом, построенным на основе библиотеки mbed TLS.

Настройка HTTPS – сервера на Raspberry Pi 3.

Я работаю со своей платой Raspberry Pi 3 удаленно, используя утилиту Putty для соединение по SSH .

Те же действия можно производить непосредственно в окне терминала Raspbian .
Итак сначала необходимо установить HTTP – сервер Apache .
Для этого используем команды :


pi@raspberrypi:~ $ sudo apt-get update
pi@raspberrypi:~ $ sudo apt-get install -y apache2


Проверить работоспособность сервера можно, введя в адресной строке интернет-браузера IP — адрес вашей платы Raspberry Pi. По-умолчанию будет загружена HTML -страничка index.html, которая находиться по пути /var/www/html .

Вы также можете настроить сервер для работы сайта под WordPress на RPi3 , используя вот эту инструкцию Build a LAMP server with WordPress.

По-умолчанию плата RPi3 использует для назначение IP адреса протокол DHCP , это означает , что после каждой перезагрузки IP – адрес Rpi3 может быть разным. Для работы нашего тестового сервера это крайне неудобно, поэтому следующим шагом мы назначим статический IP -адрес для RPi3.

Вам необходимо знать адрес шлюза , если он неизвестен, то для его определения можно воспользоваться командой :


pi@raspberrypi:~ $ netstat -r -n


Вот пример вывода команды netstat :

Далее открываем конфигурационный файл dhcpcd.conf :


pi@raspberrypi:~ $ sudo vim /etc/dhcpcd.conf


В конфигурационном файле необходимо запретить назначение IP — адреса по DHCP и установить статический адрес интерфейса и адрес шлюза . Я использую WLAN интерфейс для связи с RPi3. Вот содержимое моего конфигурационного файла :


nodhcp




interface wlan0
static ip_address=192.168.0.101/24
static routers=192.168.0.1
static domain_name_servers=192.168.0.1


Назначить статический IP – адрес проводному интерфейсу Ethernet можно так :


interface eth0
static ip_address=192.168.0.101/24
static routers=192.168.0.1
static domain_name_servers=192.168.0.1


Статический адрес RPi3 имеет значение 192.168.0.101 , адрес шлюза 192.168.0.1 .
После сохранения изменений в конфигурационном файле dhcpcd.conf необходимо перезагрузить плату :


pi@raspberrypi:~ $ sudo reboot


Теперь к нашему HTTP — серверу можно обращаться по неизменному IP — адресу (192.168.0.101).

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

Создаем каталог для хранения закрытого ключа и сертификата:


pi@raspberrypi:~ $ sudo mkdir /etc/apache2/ssl


Создаем сертификат и закрытый ключ с помощью команды :


pi@raspberrypi:~ $ sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt


В ходе выполнения последней команды вам придется ввести некоторые запрашиваемые параметры .
Самым важным параметром является Common Name (e.g. server FQDN or YOUR name). В это поле нужно ввести домен, ассоциируемый с сертификатом, или открытый IP-адрес (если такого доменного имени нет).

После отработки команды openssl закрытый ключ и сертификат будут помещены в каталог /etc/apache2/ssl.

Теперь необходимо активировать модуль SSL в составе сервера Apache с помощью команды :


pi@raspberrypi:~ $ sudo a2enmod ssl


И перезапустить Apache :


pi@raspberrypi:~ $ sudo service apache2 restart


Следующим шагом будет настройка сервера Apache для использования созданного ключа и сертификата при установлении защищенного соединения.
Открывает файл шаблона конфигурационного файла :


pi@raspberrypi:~ $ sudo vim /etc/apache2/sites-available/default-ssl.conf


В этом файле необходимо прописать пути поиска сертификата и приватного ключа :


SSLCertificateFile /etc/apache2/ssl/apache.crt
SSLCertificateKeyFile /etc/apache2/ssl/apache.key


Теперь нужно включить созданный виртуальный хост для SSL, набрав в командной строке :


pi@raspberrypi:~ $ sudo a2ensite default-ssl.conf


И перезапустить Apache :


pi@raspberrypi:~ $ sudo service apache2 restart


После выполненных действий наш web -сервер должен начать работать по протоколу https.
Для тестирования введите в командной строке интернет-браузера IP -адрес сервера с указанием названия протокола , например https://192.168.0.101 .

При тестировании соединения клиента с сервером по протоколу https есть возможность просматривать логи как со стороны клиента, так и со стороны сервера. Для настройки отладочного логирования на сервере необходимо открыть конфигурационный файл apache2.conf :


pi@raspberrypi:~ $ sudo vim /etc/apache2/apache2.conf


Установим значение переменной LogLevel в debug:


LogLevel debug


Проследим расположения файла логирования:


ErrorLog ${APACHE_LOG_DIR}/error.log


Обычно файл error.log находится в /var/log/apache2/. Значение переменной окружения APACHE_LOG_DIR можно найти в /etc/apache2/envvars .

HTTPS – клиент на плате NUCLEO_F429ZI.

Проект Https – клиента создан с помощью STM32CubeMX и сохранен для среды разработки SW4STM32. Логика работы клиента взята из примера STMicroelectronics для отладочных плат STM324x9I_EVAL и находится в исходном файле ssl_client.c .

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

Https — клиент отправляет серверу GET — запрос на получение текстового файла helloNucleo_f449zi.txt, в котором находиться текст приветствия “Hello, NUCLEO_F449ZI !”.
Такой себе вариант простейшей программы «Hello, world!».
Принятое сообщение будет выведено в окно терминала :

Кроме вывода в USART3 в проект я добавил возможность вывода сообщений через USB CDC.
Для использования порта USB необходимо откомментировать макрос USE_USB_LOG в файле main.h, а макрос USE_USART3_LOG наоборот закомментировать.
Добавить виртуальный СОМ — порт в ОС Windows возможно при помощи установки драйвера виртуального СОМ — порта , загрузить его можно с сайта производителя STMicroelectronics .
Для операционной системы Linux ничего дополнительно устанавливать не нужно, устройство автоматически появиться в системе (/dev/ttyACMx ) при подсоединении платы NUCLEO_F429ZI к USB.

Этим примером можно воспользоваться для разработки своей версии https – клиента.
Корневой сертификат в формате PEM должен быть помещен в массив const char mbedtls_root_certificate[].

Загрузить его можно прямо с вашего сайта, используя интернет — браузер. На следующих картинках показана загрузка корневого сертификата сайта cxemotexnika.org в браузере Chrome :

Таким же образом можно загрузить самоподписанный сертификат, созданный для сервера на RPi3 :

Кроме развертывание сервера Apache на Rpi3 и установления с ним защищенного соединения в моих планах было установить соединение со своим блогом https://cxemotexnika.org , но к сожалению ничего не вышло. Дело в том, что я пользуюсь услугами хостинга, на котором для нескольких сайтов используется один IP – адрес.

В процессе отладки вашей программы может понадобиться вывод отладочной информации от библиотеки mbed TLS. Для этих целей в файл MBEDTLS/mbedtls.c добавлены две функции mbedtls_debug_init() и my_debug().

Для того, чтобы активировать вывод отладочной информации , необходимо установить значение макроса DEBUG_LEVEL от 1 до 5 в файле MBEDTLS/mbedtls.h.
Рассмотрим ключевые конфигурационные опции в файле mbedtls_config.h.
В утилите STM32CubeMX есть возможность установить значения макросов с помощью визуального интерфейса. Но на момент написания данной статьи эта функция недоработанная.

Сконфигурировать библиотеку mbedTLS через графический интерфейс STM32CubeMX не удастся, поскольку многих важных для настройки макросов там просто нет и их все-равно придется задействовать вручную.
Но будьте внимательны , если намерены выполнить автоматическую генерацию кода в STM32CubeMX, после генерации содержимое конфигурационного файла mbedtls_config.h будет перезаписано. Я на всякий случай сделал копию этого файла, переименовав его в mbedtls_config_copy.h

Вот некоторые ключевые опции, задействованные в моей конфигурации :

Макрос	Описание
MBEDTLS_SSL_CIPHERSUITES	Совокупность используемых алгоритмов шифрования. Этот набор также должен поддерживаться сервером. Чтобы узнать поддерживаемый вашим сервером набор алгоритмов, откройте лог работы сервера с каким-либо другим клиентом (например интернет-браузером).
MBEDTLS_MPI_MAX_SIZE	Максимальное количество байт для используемого MPI. Не должно быть меньше размера ключа, которым подписан сертификат. Обратите внимание, что размер ключа указывается в битах, поэтому необходимо поделить его на 8 (2048/8 = 256).
MBEDTLS_RSA_C	Выбор криптосистемы открытого ключа на основе алгоритма RSA.
MBEDTLS_SHA256_C	Выбор криптографических алгоритмов хеширования SHA-224 и SHA-256 .
MBEDTLS_AES_C	Выбрать блок шифрования AES.
MBEDTLS_ECDH_C	Выбрать библиотеку эллиптической кривой Диффи-Хелмана.
MBEDTLS_GCM_C	Включить режим GCM (Gallois/Counter Mode) для AES.
MBEDTLS_SSL_PROTO_TLS1_2	Выбрать поддержку протокола TLS версии 1.2.

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

Защищенное https соединение имеет большое значение в обеспечении безопасности обмена данными. Ваши личные данные, пароли, номера банковских карт будут надежно защищены от посторонних при использовании https.

Защищенное соединение также очень важно при взаимодействии систем интернета вещей (IoT (Internet of Things) ).
Управление различным оборудованием и сбор информации о состоянии объектов в IoT должны быть надежно защищены от вмешательства злоумышленников.

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

Ссылка на исходники:

nucleo_f429zi_https_client

Viewed 301510 times by 37596 viewers