Аппаратная безопасность DDS - SGX, часть 3:усиленные службы DDS

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

Во второй части этой серии статей я рассказал, как создать защищенную конечную точку с помощью RTI Connext DDS Micro + Security, SCONE и Intel SGX. Хотя это интересно, мы еще не исследовали практическое решение со встроенным SGX. В части 1 я намекнул, что DDS + SGX, скорее всего, появится в серверной комнате, а не в качестве более традиционной конечной точки промышленного Интернета вещей (IIoT). В этом выпуске мы рассмотрим более практичные решения для приложения DDS с усилением SGX через призму служб DDS.

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

Рисунок 1:Поверхность атаки в средах DDS

Если вы следили за этой серией, вы можете вспомнить, что в части 1 я представил архитектуру, в которой пакеты, защищенные DDS, могут приходить по проводам и передаваться в защищенное SGX пространство до того, как защита DDS будет снята. Попав внутрь приложения, SGX защищает данные, и защита DDS может быть снята. Поскольку ЦП может видеть данные в виде обычного текста, нет необходимости в экзотических операциях с зашифрованными данными. Это дает явное преимущество перед другими методами защиты, такими как гомоморфное шифрование.

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

Чтобы проиллюстрировать это, давайте посмотрим на RTI Routing Service. Спецификация DDS Security Object Management Group® (OMG®) требует, чтобы код приложения Routing Service работал с данными в открытом виде, даже если это происходило на мгновение. Кроме того, служба маршрутизации владеет всеми эфемерными ключами от каждой конечной точки, с которой она осуществляла обмен данными. Некоторые архитектуры требуют, чтобы служба маршрутизации находилась на краю сети, что увеличивает риск атаки. По сути, это важная цель для злоумышленника.

Рисунок 2:Служба маршрутизации RTI обеспечивает защищенное пространство для приложений, работающих в средах SGX

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

Чтобы продолжить идею, теперь мы можем хранить любые данные на диске в защищенном виде.

Рисунок 3. Служба маршрутизации DDS и RTI защищена в средах SCONE

Например, мы можем хранить сообщения DDS для авторизованного воспроизведения. SCONE поддерживает собственный (и прозрачный) TLS-обмен данными с другими авторизованными контейнерами SCONE, такими как SQLite.

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

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

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

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

В своем следующем блоге я исследую стоимость безопасности в средах DDS-SGX.