eSSL - SSL сертификаты для встраиваемых систем

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

Немого общей имформации об SSL

Технология SSL позволяет шифровать трафик между двумя устройствами. Вы, наверное знаете, что SSL сертификаты выдаются web-сайтам и приязываются на домены или поддомены. Сертификаты выдаются доверенными центрами сертификации (Certification Authority) и подписываются электронными подписями. Сертификаты подтверждаются в браузерах путем проверки цепочки сертификатов (Certification Path), корневые сертификаты этих центров уже распространяются вместе с дистрибутивами основных браузеров и такая проверка происходит незаметно для пользователя. В случае, если доверенный корневой сертификат не найден браузером, пользователю выдается страничка с предупреждением о том, что соединение с сервером не является безопасным.

Проблема встраиваемых систем в том, что,

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

Как же решать эти проблемы?

eSSL - embedded Secure Socket Layer

Дальше я представлю на Ваш суд результаты моих исследований данного вопроса проверенные опытным путем. Термин eSSL пришел мне в голову в процессе написания этой статьи, так что любые упоминания прошу употреблять вместе со ссылкой на embedders.org.

Итак, освещу немного важные аспекты строения сертификатов, которые позволяют использовать их нужным нам способом. Любой сертификат представляет собой совокупность строковых полей подписанную закрытым ключом (private key). Сертификат также содержит в себе открытый ключ для проверки подлинности данных содержащихся в этих строковых полях. Перечень полей определен в формате Х.509 v3 и описан в документе RFC 5280(это последняя на данный момент редакция документа, до этого действовал RFC 3280). Сертификат содержит поле commomName которое описывает имя субъекта сертификации, обычно оно совпадает с доменом веб-сайта для которого выпущен сертификат, но в стандарте нет никаких запретов на то что будет вписано в эту строку, например, строка "Вася Пупкин" будет так же валидна для этого поля с точки зрения стандарта - это первый аспект. Но веб-браузеры проверяют именно это поле на соответствие с именем сайта который предъявляет сертификат. К счастью для нас в формате X509 v3 определены дополнительные расширения, одно из которых subjectAltName, которое позволяет добавить идентификаторы, связанные с основным именем субъекта сертификации (commomName). Такими идентификаторами могут быть:

• Адрес электронной почты
• DNS
• IP адрес
• и URI

и это второй и, пожалуй, наиболее важный аспект строения сертификатов 3й версии стандарта. Дело в том что таких идентификаторов можно добавить несколько, т.е. можно вписать несколько IP адресов для которых будет валиден выпущенный сертификат. А это и есть то что нам нужно в случае если некое устройство имеет два Ethernet интерфейса для работы в разных под-сетях, да еще и возможность выхода в сеть через различные типы модемов, если соединение будет по PPP, то это будет третий интерфейс со своим IP адресом. Опытным путем мною был установлен один важный момент в назначении альтернативных IP адресов. Браузеры Internet Explorer и FireFox по разному производят проверку альтернативных имен. FireFox сверяет адрес который указан в идентификаторе IP, а IE - сверяет адрес с идентификатором DNS. Поэтому, для осуществления проверки сертификата в обоих браузерах, каждый необходимый IP адрес должен быть указан и как IP и как DNS. О том как это сделать будет рассказано дальше.

Сценарий использования SSL во встраиваемых системах

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

1. Нам потребуется создать самоподписанный корневой сертификат, в этом случае мы станем сами себе центром сертификации.
2. Далее нам нужно создать сертификат для нашего web-интерфейса и подписать его корневым сертификатом, созданным на первом шаге.
3. Этот сертификат мы помещаем в память  нашей встраиваемой системы где его сможет найти встроенный веб-сервер.
4. Всем пользователям веб-интерфейса мы должны выдать наш корневой сертификат, но не приватный ключ.
5. Пользователи веб-интерфейса должны импортировать наш корневой сертификат в свои веб-браузеры на всех компьютерах с которых предполагается вход на веб-интерфейс.

Особо отмечу, что этот сценарий не является безопасным, подобный способ используют производители роутеров, а умные хакеры извлекают ключи из прошивок и складывают в базу данных http://code.google.com/p/littleblackbox/. Этот способ не является и удобным, потому что мы должны передать корневой сертификат конечному пользователю. А от нас еще и потребуется хранить корневой сертификат и приватный ключ к нему в безопасном месте. В идеале обе этих функции обеспечивает один из доверенных центров сертификации, но за это они взымают плату.

Далее я расскажу, как на практике реализовать предложенный сценарий. Все действия будут производиться на компьютере под управлением ОС Linux (Debian) и программы openssl.