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

Question

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

Настройка:

В БД есть таблица с двумя полями

php_key - stores a symmetrically encrypted symmetric key that is used for OTHER tables
php_key_hash - stores a hmac of the symmetric key

другие таблицы (как упоминалось в другом посте):

last_name - symmetrically encrypted value encrypted with key after being unencrypted from php_key
last_name_hash - hmac of last_name

Вход / Безопасная защита ключа:

1) Пользователь входит в систему - (несвязанный) пользователь / пароль просто сохраняется в БД (пароль - это hmac)

2) После входа в систему пользователю предоставляется экран, на котором ему необходимо ввести другой пароль - этот пароль будет доступен всемсотрудники компании (всего 5 сотрудников, которые легко запомнить).Позволяет вызвать этот ключ 1.

3) Этот пароль имеет hmac и сравнивается с php_key_hash в БД.

Если произойдет сбой, я могу просто указать здесь пользователя.

4) Если он совпадает, потянуть вниз php_key, расшифровать его, используя тот же пароль, сохранить в переменной сеанса.

В этот момент ключ хранится в памяти на сервере и будет уничтожен при выходе пользователя из системы.Позволяет назвать этот ключ 2.

После этого происходит нормальное дешифрование полей, как в другом посте

Это кажется мне действительно безопасным, потому что

1)ключ2 хранится на сервере, отличном от веб-сервера

2) ключ2 сам по себе зашифрован - он никогда не хранится в виде обычного текста

3) ключ1 не находится ни в каком месте кода или файласистема или в БД - это известно только в головах сотрудников

4) Вы должны войти на сайт в основном дважды (один с вашим логином, снова с ключом 1)

5)Использование переменных сеанса означает, что ключ 2 хранится только в памяти и только на сервере и уничтожается после окончания сеанса

6) Я могу просто повторно ввести ключ key1 в любое время, если нам потребуется изменить фразу-пароль -например, если сотрудник уходит или мы думаем, что он скомпрометирован

Потенциальные проблемы AKA Мои вопросы (наконец)

Во-первых, я ни в коем случае не эксперт по безопасности, поэтому почемуЯ просто хотел быНикто из тех, кто лучше меня по безопасности:)

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

2) Сохранение симметричного ключа (key2) в переменной сеанса - потенциальные проблемы с людьми, работающими в оперативной памяти?Возможно, было бы лучше просто сохранить key1 в переменной сеанса, а затем каждый раз проходить двойное дешифрование (но, вероятно, медленно)?Я слишком осторожен?

Answer 1

ОК, теперь я понимаю, что вы имеете в виду. Я полагаю, вы имеете в виду:

key1 = PBKDF2(password, salt, many_iterations)
php_key_hash = HMAC(key1, salt)

Когда вы говорите HMAC в качестве пароля, я предполагаю, что вы имеете в виду PBKDF2 со многими итерациями (например, несколько секунд). Во всяком случае, чтобы ответить на ваши 2 вопроса:

1) Сохранение key2 в зашифрованном виде рядом с данными, зашифрованными с помощью key2, в порядке. На самом деле AWS KMS работает таким образом, за исключением того, что они используют разные key2 для каждого шифрования. Если один key2 будет взломан, будут скомпрометированы только его соответствующие данные (не вся база данных). И это делает поворот ключа проще.

2) Если вы храните key1 в ОЗУ вместо key2, это не поможет: если кому-то удастся получить key1 из ОЗУ, вы, вероятно, можете предположить, что у него есть доступ к php_key из базы данных. и сможет расшифровать key2. Если вы хотите предотвратить эту проблему и не хотите иметь ключи в ОЗУ, вам следует рассмотреть HSM (и key2 в обычном режиме никогда не покинет HSM). Без HSM key2 должен был бы быть в ОЗУ в некоторый момент.