Шифрование в “индустриальных” протоколах и анализ трафика

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

(Речь здесь идёт только о шифровании, обеспечение целостности и аутентификацию – оставим за рамками заметки. И там же, за рамками, очевидный момент: тезис “внутренней сети” – весьма и весьма спорный.)

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

Авторизованный узел, реализующий автоматический мониторинг, должен знать используемые ключи. Или уметь эффективно вычислять эти ключи. Тогда мониторинг можно реализовать пассивно, без необходимости как-то вмешиваться в канал связи и в передачу пакетов. Ключи, используемые в некоторой сессии, могут быть определены на основе метаинформации, к которой относятся номера пакетов, адреса самих устройств, метки времени; вариантов – очень много. Ключи могут вычисляться на основе некоторого мастер-ключа, известного мониторингу. Опять же, это далеко не единственная схема: возможно применение общей для системы псевдослучайной функции с секретом, которая позволяет узлу, знающему секрет, быстро подобрать ключ; можно даже просто использовать статические ключи на устройствах или внедрить сервер ключей. (Заметьте, что узел, реализующий мониторинг трафика, обычно не испытывает недостатка в вычислительных ресурсах.)

При этом, с точки зрения защиты передаваемой информации, решение с шифрованием окажется заведомо не хуже, чем полностью открытый протокол. А внедрить именно мониторинг – особенной проблемы не составляет, если только сразу проектировать протокол с учётом этого требования. Другое дело, что в случае с шифрованным протоколом, у чисто внешнего решения, предназначенного для “защиты”, возникнут проблемы: это решение должно уметь работать с ключами, как-то получать их, и так далее. Это существенно увеличивает затраты на разработку, по сравнению с “мониторингом” открытого протокола, где можно быстро и просто приспособить имеющиеся в “офисной линейке” решения (с сомнительной степенью полезности).

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

Адрес записки: https://dxdt.ru/2017/08/15/8396/

Похожие записки:



Далее - мнения и дискуссии

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

1 комментарий от читателей

  • 1. 17th August 2017, 02:24 // Читатель Z.T. написал:

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

Написать комментарий

Ваш комментарий:

Введите ключевое слово "1RR9R" латиницей СПРАВА НАЛЕВО (<--) без кавычек: (это необходимо для защиты от спама).

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