Защита закрытого ключа - PullRequest
2 голосов
/ 19 июня 2011

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

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

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

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

Какие у меня варианты?

Ответы [ 3 ]

3 голосов
/ 19 июня 2011

Теперь, поскольку мой сервер будет отправлять много таких сообщений ...

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

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

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

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

2 голосов
/ 19 июня 2011

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

Лучшим подходом может быть: Как я могу предотвратить обычные взломы, такие как атака «человек посередине», от нарушения безопасности?

Я бы сказал:

  1. Передача сообщений через SSL (если вы используете протокол HTTP / HTTPS).
  2. Обфусцируйте код, обеспечивающий кодированиеФункциональность декодирования.Это затруднит расшифровку вашего хэша, если кто-то получит ключ.Если вы не кодируете ключ и / или сообщение на сервере, а декодируете на клиенте - это может быть чем-то, на что стоит обратить внимание в зависимости от ваших требований
  3. В сети, где передаются сообщения, используйтесетевой инструмент для мониторинга трафика (например, фырканье).Обнаружение вторжения может сказать вам, когда кто-то что-то замышляет.

Просто начало ...

0 голосов
/ 13 февраля 2017

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

...