Просто использовать протокол HTTPS для обеспечения безопасности обновления ПО недостаточно для полной гарантии, что данное обновление не было искажено. Здесь может помочь The Update Framework.

Обновление ПО — один из наиболее важных способов защиты пользователей и организаций. Но как безопасно обновлять ПО? Для решения этой проблемы предназначается The Update Framework (TUF).

На прошлой неделе на конференции DockerCon 17 в Остине (шт. Техас), доцент Нью-Йоркского университета Джастин Каппос подробно рассказал, как работает TUF и что еще будет предпринято для дальнейшего совершенствования защищенного обновления.

Просто использовать протоколы HTTPS и Transport Layer Security (TLS) для обеспечения безопасной загрузки недостаточно, поскольку неоднократно публично сообщалось о репозиториях, в которых ПО было фальсифицировано, сказал он. «Если в вашем браузере присутствует изображение зеленого замка HTTPS, это означает, что ваш браузер установил безопасное соединение с сервером, — продолжил Каппос. — Это ничего не говорит о том, имеется ли на сервере надежное обновление или знает ли сервер, что такое корректное обновление, и не был ли взломан сам сервер». По его словам, если атакующий проник в репозиторий ПО, все пользователи, которые пытаются загрузить обновления из этого репозитория, потенциально могут подвергнуться взлому, даже если для защиты транспорта данных используется HTTPS.

«Восемь лет назад мы с коллегами начали работу над проектом с целью попытаться сделать механизм обновления ПО устойчивым к взлому инфраструктуры, — рассказал Каппос. — Хакеры могут проникнуть в какие-то части вашей инфраструктуры. Цель TUF в том, чтобы даже если это произошло, безопасность системы в целом не была нарушена».

Главное в дизайне TUF то, что он может поддерживать множество типов моделей развертывания и вычислительных сред без необходимости нарушать и заменять существующую инфраструктуру. Дизайн TUF отвечает нескольким базовым принципам. Первый из них — разделение полномочий. Каппос сказал, что тем участникам процесса, которым доверяется выполнение одного набора действий, не доверяется выполнение всех функций. Кроме того, дизайн TUF интегрирует модель доверия с множеством подписей, которая требует двух или более цифровых ключей для подтверждения доверия и аутентичности. «Таким образом, если взломан один ключ, а требуется два ключа, риск для клиентов невелик», — заявил он.

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

Хотя TUF представляет устойчивую модель для защиты целостности обновлений, у нее есть свои ограничения. Расширенная цепочка поставок ПО является той областью, которую TUF не поможет защитить, заявил Каппос. Иными словами, если вредоносный код вставлен в чужой компонент, который затем включается в проект или репозиторий ПО, TUF не поможет.

Чтобы помочь решить проблему целостности распределенной цепочки поставок ПО, выдвинута связанная с TUF инициатива под названием in-toto, которая использует сходную модель для проверки аутентичности. Каппос сказал, что in-toto обещает представить более широкую модель защиты ПО, которая гарантирует, что все включенное в проект ПО проверено.

«Трудно обезопасить распространение ПО», — заключил Каппос.

Версия для печати