Рейтинг:0

Как вы должны управлять ключами, чтобы предотвратить боковое движение?

флаг cn

Допустим, я разрабатываю протокол связи, который будет использоваться многими парами устройств для связи друг с другом (только между парами).

Предполагая, что устройства в паре могут взаимодействовать друг с другом криптографически безопасным способом, используя, например, цифровые подписи, и хотя бы одно из них время от времени подключается к Интернету, как бы вы:

  • выдавать новые ключи (либо между устройствами, либо из централизованного источника)?
  • надежно отступить и поддерживать связь, если что-то произойдет в процессе ключевого вопроса?

Основные требования:

  1. В паре устройств А, Б, Только А и Б могут общаться друг с другом; противник не должен уметь разговаривать с Б или же А наблюдая за общением между ними.
  2. Такой протокол должен иметь открытый исходный код без потери безопасности.
  3. По крайней мере, одна из систем должна управляться человеком, даже если базовый код, который запускает эти системы, непрозрачен для оператора.

Вот проблемы, которые я вижу:

  1. Централизованный контроль над управлением ключами добавляет единую точку отказа; получить доступ к этому сервису, и все это рухнет
  2. Этими системами должны управлять люди, поэтому доступ к ключам может быть возможен.
  3. Если по какой-то причине обнаружена криптографическая проблема, системы становятся непригодными для использования и должны (каким-то образом?) безопасно обновляться с помощью новых ключей, но без основы доверия.
  4. Физическая безопасность системы, управляемой человеком, имеет первостепенное значение.

Как бы вы распорядились ключами в этой ситуации?

poncho avatar
флаг my
Почему стандартное решение, такое как TLS, не решает вашу проблему?
флаг cn
Ах, это отличный момент! `A` и `B` не связаны сетью, они соединены последовательным кабелем (SPI/CAN/RS232 и т.д.)
poncho avatar
флаг my
TLS может работать по последовательному кабелю — вам нужен надежный транспорт (чтобы служить вместо TCP), но это несложно. В качестве альтернативы вы можете использовать DTLS (который не требует надежности, однако реализации не так хорошо проверены)
Eugene Styer avatar
флаг dz
Если вы используете что-то вроде протокола «точка-точка» (PPP) для подключения узлов, вы можете использовать TLS и TCP/IP через PPP.
флаг cn
Обрабатывает ли TLS ротацию ключей/сертификатов и управление ими автоматически?
Maarten Bodewes avatar
флаг in
Нет, и вам необходимо явно включить аутентификацию клиента, поскольку это необязательно. Тем не менее, он четко разделен на долгосрочные и краткосрочные / специфичные для сеанса ключи, и вы можете, например. настроить высокодоступную службу, которая запускает ЦС. Короче говоря, это сводит проблему к правильной реализации PKI.
флаг cn
Итак, я думаю, что вопрос остается в силе; как вы безопасно управляете ключами для такой службы?
Рейтинг:0
флаг sd

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

Современные протоколы консолидации ключей содержат дополнительные объемы информации, которые помогают противодействовать активным атакам противника.

Некоторые из этих величин:

-Временная метка. Отметка времени состоит из даты, времени, минут, секунд и в некоторых случаях десятков или сантиметров секунды и выражает время выполнения действия протокола, которым может быть какая-либо (криптографическая) операция или передача информации. На практике для отметок времени требуется доверенный сервер отметок времени, который обслуживает запросы отметок времени.

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

Некоторые причины для консолидации сеансовых ключей:

  1. Ограничение количества зашифрованного материала, который можно использовать для криптоанализа.
  2. Ограничение последствий разглашения или несанкционированного доступа к криптографическим ключам.
  3. Необходимость хранить множество криптографических ключей в течение длительного времени.
  4. Независимость между сеансами связи и между веб-приложениями/сервисами.

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.