Изменить ключ шифрования без раскрытия открытого текста - PullRequest
4 голосов
/ 18 декабря 2011

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

Я предполагаю, что мне нужен ассоциативный шифр, что-то вроде этого:

T( E<sub>o</sub>(m) ) = E<sub>n</sub>( D<sub>o</sub>(E<sub>o</sub>(m) ))

где Eo (m) - зашифрованный текст, Eo / Do - старая пара ключей pub / priv, En - новый ключ pub, m текст сообщения и T - функция магического повторного шифрования. Изменить: T рассчитывается на стороне клиента и затем отправляется на сервер для использования.

Ответы [ 2 ]

1 голос
/ 18 декабря 2011

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

Я бы предложил просто сохранить кольцо ключей.Добавьте новый ключ в кольцо и отметьте его как активный.Марка старого ключа истекла.Закодируйте клиент так, чтобы, если он находит какие-либо данные, зашифрованные с помощью ключа с истекшим сроком действия, он повторно шифрует его с помощью активного ключа.(Или нет. То, что необходимо, зависит от деталей ваших требований к реализации.)

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

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

0 голосов
/ 18 декабря 2011

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...