Надежное хранение и поиск по номеру социального страхования

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

Я провел много исследований и думаю, что придумал разумный план - но, как и все, что связано с крипто / безопасностью, здесь очень много сложностей, и очень легко ошибиться. Мой примерный план таков:

1. При первом запуске приложения сгенерируйте большую случайную соль и 128-битный ключ AES с помощью RijndaelManaged
2. Запишите их оба в текстовый файл для аварийного восстановления. Этот файл будет храниться в автономном режиме в безопасном физическом месте. Приложение проверит наличие файла и выдаст предупреждение, если оно все еще там.
3. Храните соль и ключ в надежном месте. Это та часть, на которую у меня нет хорошего ответа. Я планировал использовать DPAPI - но я не знаю, насколько он безопасен в конце дня. Будет ли лучше просто оставить его открытым текстом и ограничить доступ файловой системы к каталогу, в котором он хранится?
4. При записи записи в базу данных хешируйте SSN вместе с большим значением соли, указанным выше, чтобы создать поле, которое доступен для поиска (но не подлежит восстановлению без получения всех возможных номеров SSN), и AES шифрует необработанное значение SSN с помощью нового IV (хранящегося рядом), чтобы создать поле, которое можно извлечь (с ключом / iv), но нельзя найти (потому что шифрование одного и того же SSN дважды должно привести к разным выводам).
5. При поиске просто хешируйте искомое значение с той же солью и найдите его в БД.
6. При извлечении расшифруйте значение из БД, используя ключ AES / iv

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

То, что у нас не сработает:

• «Не делай ничего из этого» не вариант. Это должно быть сделано, и если мы этого не сделаем, они а) разозлятся на нас и б) просто передадут все числа в текстовом документе по электронной почте.

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

Спасибо за чтение и за любые советы.

Обновление № 1: из комментариев я понял, что не имеет смысла хранить закрытый IV для поля поиска SSN. Я обновил план, чтобы правильно сгенерировать новый IV для каждой записи и сохранить его вместе с зашифрованным значением.

Обновление № 2: Я удаляю аппаратные средства из своего списка вещей, которые мы не можем сделать. Я провел небольшое исследование, и кажется, что этот материал более доступен, чем я думал. Добавляет ли использование одного из этих маркеров безопасности USB значительную безопасность для хранения ключей?