Детерминированное c шифрование с использованием AWS KMS

Question

Мне нужно создать службу идентификации, которая использует предоставленный клиентом ключ для шифрования конфиденциальных значений идентификатора для хранения в RDS, но также должна позволить нам позже просмотреть запись с использованием идентификатора в виде открытого текста. Для этого мы хотели бы использовать простой алгоритм шифрования детерминированного c, но похоже, что API-интерфейс KMS не позволяет указывать IV, поэтому вы никогда не сможете получить одинаковый открытый текст для шифрования с одинаковым значением дважды.

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

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

Я предполагаю, что это довольно распространенное требование для таких вещей, как SSN и так далее, как люди решают за это?

Спасибо в заранее.

Answer 1

если я правильно понимаю ваш сценарий использования, ваш поток выглядит следующим образом:

1. Клиент предоставляет ключ K, и вы используете этот ключ для шифрования секретного S, который хранится в RDS с помощью связанный идентификатор.
2. Учитывая несекретный ключ K, вы хотите иметь возможность искать и расшифровывать его.

Если клиент повторно использует ключ, это на самом деле не все так сложно выполнить sh.

1. Создать ключ KMS для клиента.

2. Используйте этот ключ KMS для шифрования ключа клиента. IV и ключ, указанный клиентом, и сохраните их в Amazon Secrets Manager - предпочтительно в некотором роде, определенном пользователем. Структура Json, подобная этой:

   {"iv": "somerandomivvalue", "key": "somerandomkey"}

   позволит вам легко разобрать значения. ASM также позволяет беспрепятственно выполнять поворот ключа - что очень удобно.

3. Если вы параноик, вы можете взять криптографию c га sh имени клиента ( или что-то в этом роде).

4. RDS теперь хранит идентификатор нумерации c клиента, небезопасные значения и значение пространства имен (или некоторый метод получения местоположения) в ASM.

5. Само собой разумеется, что вам необходимо ограничить доступ к хранилищу диспетчера секретов.

Чтобы использовать решение:

1. Клиент выдает запрос на считывание защищенного значения.
2. Служба обращается к ASM и расшифровывает секрет для клиента.
3. Служба извлекает IV и ключ
4. Служба инициализируется Схема шифрования с IV и ключом и расшифровывает данные клиента.

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

Другие, вероятно, найдут криптографически лучшие решения, но это следует сделать для первой попытки.

Answer 2

В итоге мы решили продолжить использовать KMS для предоставленного клиентом ключа шифрования / дешифрования столбца чувствительного идентификатора, но также включили расширение PostgreSQL pgcrypt для обеспечения безопасных хэшей для поиска. Поэтому в дополнение к нашему зашифрованному столбцу мы добавили столбец id_ha sh и оперируем таблицей примерно так:

`INSERT INTO employee VALUES ..., id_ha sh = ENCODE (HMA C ('SENSITIVE_ID + SECRET_SALT', 'SECRET_PASSPHRASE', 'sha256'), 'hex');

ВЫБРАТЬ ИЗ сотрудника, ГДЕ Division_id = ??? AND id_ha sh = ENCODE (HMA C ('SENSITIVE_ID + SECRET_SALT', 'SECRET_PASSPHRASE', 'sha256'), 'hex'); `

Мы могли бы выполнить хеширование на стороне клиента, но поскольку алгоритм является ключом к последующим поискам, нам понравилась простота того, что БД выполняет хеширование для нас.

Надеюсь, это пригодится всем, кто ищет решение.

Answer 3

найдите запись позже, используя открытый текст ID

Тогда вы теряете немного безопасности. Возможно, вы могли бы хранить ha sh (например, sha-256) идентификатора вдоль зашифрованных данных, что упростило бы поиск записи, но не возвращало бы значение

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

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

да, кажется, KMS предоставляет свой собственный IV для шифрованного текста, обеспечивающего хорошую практику безопасности