Хранение сертификата безопасности DDS

Question

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

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

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

Есть ли безопасный способ защиты личных ключей в файловой системе?

О документах permissions_ca и Governance/Permissions, если они обновляются злоумышленником (который создаст свой собственный CA и подпишет новые документы Governance/Permissions), может ли приложение иметь больше разрешений? Это означает, что эти документы должны быть защищены в файловой системе?

Answer 1

Большинство ваших вопросов не относятся к безопасности DDS, а касаются общих механизмов инфраструктуры открытых ключей (PKI), которые используются DDS Security.

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

Да, это правильно. Встроенные плагины, определенные в спецификации безопасности DDS, используют PKI. Сертификат открытого ключа обычно не содержит никакой конфиденциальной информации.

Однако в файловой системе Ubuntu как я могу защитить закрытый ключ?

Использование "традиционных" разрешений Unix для разрешения доступа к нему только владельцу файла является обычной практикой. Например, SSH в Ubuntu по умолчанию хранит закрытые ключи таким образом, в ~/.ssh, Кроме того, спецификация допускает шифрование закрытого ключа с использованием ключевой фразы. Это тоже обычная практика.

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

О документах permissions_ca и Governance/Permissions, если они обновляются злоумышленником (который создаст свой собственный CA и подпишет новые документы Governance/Permissions), может ли приложение иметь больше разрешений?

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

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

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