Прежде всего, я бы не назвал себя экспертом по безопасности, но я был в состоянии ответить на этот вопрос. То, что я обнаружил, меня немного удивило: не существует такого понятия, как полностью безопасная система . Ну, я думаю, что полностью безопасная система будет такой, где все серверы выключены :)
Кто-то, работавший со мной в то время, описал проектирование безопасной системы с точки зрения повышения планки для злоумышленников. Таким образом, каждый уровень защиты уменьшает возможность для атаки.
Например, даже если вы можете полностью защитить личный ключ, система не является полностью защищенной. Но правильное использование алгоритмов безопасности и наличие обновлений с исправлениями поднимает планку. Но, да, суперкомпьютер, достаточно мощный и достаточно времени, может сломать шифрование. Я уверен, что все это поняли, поэтому я вернусь к вопросу.
Вопрос ясен, поэтому я сначала попытаюсь рассмотреть каждый из ваших пунктов:
Скажем, ключ защищен моделью безопасности файловой системы; но как насчет (злонамеренных) суперпользователей или платформ, которые не обеспечивают такую точность?
Да, если вы используете что-то вроде хранилища ключей Windows или секретный ключ TLS, зашифрованный паролем, вы можете получить доступ к пользователям, у которых есть пароль (или доступ) к закрытым ключам. Но, я думаю, вы согласитесь, что поднимает планку. ACL файловой системы (если реализованы должным образом) обеспечивают довольно хороший уровень защиты. И вы в состоянии лично проверить и узнать своих суперпользователей.
Или ключ жестко закодирован в двоичные файлы программного обеспечения, но его всегда можно декомпилировать, а как насчет программного обеспечения с открытым исходным кодом или интерпретируемого кода?
Да, я видел жестко закодированные ключи в двоичных файлах. Опять же, это немного поднимает планку. Кто-то, кто атакует эту систему (если это Java), должен понимать, что Java создает байт-код (и т. Д.) И должен понимать, как его декомпилировать, читая его. Если вы используете язык, который пишет непосредственно в машинный код, вы можете увидеть, что это поднимает планку немного выше. Это не идеальное решение для обеспечения безопасности, но может обеспечить некоторый уровень защиты.
Если ключ сгенерирован, такой алгоритм должен быть детерминированным (предположительно), и тогда та же самая проблема относится к семени.
Да, по существу, тогда алгоритм становится информацией о секретном ключе для создания секретного ключа. Так что теперь его нужно защищать.
Итак, я думаю, что вы определили основную проблему с любой политикой безопасности, управления ключами . Наличие ключевой политики управления имеет решающее значение для обеспечения безопасной системы. И это довольно широкая тема .
Итак, вопрос в том, насколько безопасной должна быть ваша система (и, следовательно, закрытый ключ)? Насколько высоко в вашей системе нужно поднимать планку?
Теперь, если вы готовы платить, есть некоторые люди, которые предлагают решения для этого. Мы закончили с использованием HSM (Hardware Security Module) . Это в основном защищенный от несанкционированного доступа сервер, содержащий аппаратный ключ. Этот ключ затем может быть использован для создания других ключей, используемых для шифрования. Идея здесь в том, что (если настроен правильно) ключ никогда не покидает HSM. HSM стоят дорого . Но в некоторых компаниях (скажем, защита данных кредитных карт) стоимость взлома намного выше. Итак, баланс существует.
Многие HSM используют карточки-ключи от обслуживания и администрирования функций. Кворум карточек-ключей (скажем, 5 из 9) необходимо физически поместить на сервер, чтобы сменить ключ. Таким образом, это поднимает планку довольно высоко, допуская нарушение только в случае сговора суперпользователей.
Там могут быть программные решения, которые предоставляют функции, аналогичные HSM, но я не знаю, что они собой представляют.
Я знаю, что это лишь ответит на вопрос, но я надеюсь, что это поможет.