Как изменить ключ aes-256 после шифрования? - PullRequest
7 голосов
/ 24 января 2012

У меня есть веб-сайт, на котором пользователи представляют свои личные данные, и я думаю о шифровании этих данных с использованием aes-256, и их пароль используется в качестве ключа для этого шифрования, а затем я сохраняю зашифрованные данные в базе данных mysql....

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

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

Ответы [ 4 ]

14 голосов
/ 24 января 2012

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

Создание секретного ключа для шифрования данных пользователя; Назовите это «ключ шифрования контента». Получить ключ от пароля пользователя; Назовите это «ключ шифрования ключа». Зашифруйте «ключ шифрования содержимого», используя «ключ шифрования ключа». Сохраните зашифрованный ключ вместе с солью и количеством итераций, использованных для получения ключа.

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

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

Не просто хэшируйте пароль, даже если вы используете соль, даже если вы используете еще не сломанный алгоритм. Вам нужно повторить операцию хеширования тысячи раз. Есть библиотеки для этого (правильно) на большинстве платформ. Используйте алгоритм получения ключа (PBKDF2, из PKCS # 5) для создания секретного ключа из пароля.

Эта концепция следует за проектом для шифрования S / MIME на основе пароля.

3 голосов
/ 24 января 2012

Во-первых, вы обычно не должны использовать пароль в качестве ключа AES. Может быть, что-то вроде криптографического хэша (не MD5) пароля + соли (в этом случае вы бы хранили соль, но не хэш).

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

2 голосов
/ 24 января 2012

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

Как это работает?

  • Вы шифруете данные D для пользователя U с помощью случайно сгенерированного ключа, K U, D .
  • Вы шифруете ключ K U, D отдельным ключом K1 U, K , сгенерированным из случайной соли, S1 U (которую вы сохраняете запись) и пароль пользователя P1 U (который вы можете или не можете отслеживать). Зашифрованный ключ E1 U .
  • Вы храните S1 U и K1 U, K , готовые к тому времени, когда пользователь захочет получить доступ к своим данным.
  • Когда пользователь U хочет получить доступ к своим данным, он предоставляет вам свой пароль P1 U , и вы ищите S1 U и регенерируете K1 U, K из этих данных и используйте их для расшифровки E1 U , что даст вам K U, D еще раз, с помощью которого вы расшифруете их фактические данные.
  • Вы гарантируете, что можете определить, когда введен правильный пароль, поэтому вы не выкидываете бинарный трюк, если пользователь вводит неправильный пароль.

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

При уровне косвенности вы по-прежнему запрашиваете у пользователя старый пароль (P1 U ) и новый пароль (P2 U ) и подтверждаете его, но у вас есть только расшифровать E1 U , а затем повторно зашифровать его с помощью нового ключа K2 U, K , сгенерированного из новой соли S2 U и нового пароля P2 U . Вам вообще не нужно трогать зашифрованные данные.

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

Это мягкая вариация некоторых идей из " Криптография в базе данных: последняя линия защиты " Кевина Кенана. Ключи Kn U, K являются примерами ключа шифрования ключа KEK. Вы также можете прочитать о ключевых семействах в книге, которые помогут в управлении зашифрованными данными.

0 голосов
/ 24 января 2012

Это глупо.

AES использует 256-битный ключ, поэтому, когда вы говорите, что будете использовать их пароль для ключа, он не будет почти таким же длинным, как требуется размер ключа.

...