Изменить ключ шифрования без раскрытия открытого текста

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

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

T( Eo(m) ) = En( Do(Eo(m) ))

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


encryption cryptography public-key-encryption public-key
person Mikey Top    schedule 18.12.2011    source источник
comment
Может быть лучше на crypto.stackexchange.com, но я не уверен, насколько велико там сообщество.   -  person Damien_The_Unbeliever    schedule 18.12.2011

Ответы (2)


arrow_upward
2
arrow_downward

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

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

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

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

person David Schwartz    schedule 18.12.2011
comment
Спасибо, Дэвид. Ни один клиент не имеет полного доступа к базе данных, поэтому, если закрытый ключ будет скомпрометирован, ущерб будет ограничен, и все записи могут быть немедленно повторно зашифрованы. - person Mikey Top; 18.12.2011
comment
Проблема в том, что у человека, который скомпрометировал ключ, вероятно, уже есть зашифрованные данные. Вы должны навсегда защитить ключ или любые данные, которые были когда-либо защищенный этим ключом, скомпрометирован. - person David Schwartz; 18.12.2011
comment
Я рассматриваю это как проблему управления рисками — вероятность компрометации закрытого ключа и полного взлома базы данных или получения резервной копии ниже, чем у каждого по отдельности. (В любом случае резервные копии шифруются отдельным ключом, что дает второй уровень шифрования) - person Mikey Top; 18.12.2011
comment
Я согласен. Поэтому вам не нужно повторно шифровать данные. Если злоумышленник не может получить и ключ, и зашифрованные данные, вы в безопасности, независимо от того, выполняете ли вы повторное шифрование. Если злоумышленник может получить и ключ, и зашифрованные данные, вы облажались независимо от того, будете ли вы повторно шифровать или нет. - person David Schwartz; 18.12.2011
comment
Если бы закрытый ключ был скомпрометирован и ответа не последовало, у них было бы неограниченное время, чтобы придумать, как взломать базу данных. С моей установкой оба должны быть взломаны одновременно. - person Mikey Top; 18.12.2011
comment
Их вообще не нужно было бы нарушать одновременно. Они могут взломать базу данных, а затем получить ключ через несколько недель, месяцев или лет. Если вы не можете полагаться на то, что зашифрованные данные никогда не утекут (в таком случае, зачем повторно шифровать?), вы должны защищать ключи до тех пор, пока любые данные, которые они когда-либо зашифровывали, нуждаются в защите. Повторное шифрование только увеличивает вашу уязвимость, так как теперь есть два ключа, которые вы должны защищать для защиты тех же данных, а раньше был один. (Другими словами, если у вас нет оснований полагать, что ключ был скомпрометирован, повторное шифрование — плохая идея.) - person David Schwartz; 18.12.2011
comment
Если на то пошло, если вы можете быть уверены, что зашифрованные данные никогда не просочятся наружу, зачем вообще шифровать? Если у кого-то нет данных, не имеет значения, что у него есть ключ. @DavidSchwartz прав, если есть подозрения в ЛИБО утечке ключа или данных, необходимо изменить оба, а также определить, как они просочились, и закрыть дыру, чтобы это не повторилось. - person wadesworld; 18.12.2011
comment
Они могут взломать базу данных, а затем получить ключ через несколько недель, месяцев или лет. Если мы обнаружим нарушение, мы немедленно удалим все действующие копии закрытого ключа. Если ключ скомпрометирован, мы немедленно перешифруем всю базу данных. Речь идет об относительном риске. - person Mikey Top; 18.12.2011
comment
@MikeyTop Верно, если ключ скомпрометирован. Но мы говорили не об экстренном реагировании, мы говорили о смене ключа. Когда срок действия ключа просто истекает или его заменяют, повторное шифрование — плохая идея. Теперь есть два ключа, которые могут скомпрометировать данные, раньше был только один. - person David Schwartz; 19.12.2011
comment
Просто снова наткнулся на мой старый пост и решил добавить немного больше для поисковой системы. По-видимому, это известно как гомоморфное повторное шифрование и является активной областью исследований. Судя по моему ограниченному чтению, на данный момент нет жизнеспособных реализаций. - person Mikey Top; 05.05.2012

arrow_upward
0
arrow_downward

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

person crazyscot    schedule 18.12.2011