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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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