Хранение и восстановление ключей DPAPI
В свете предстоящих правил GDPR, компания, на которую я работаю, рассматривает возможность модернизации своих алгоритмов шифрования и шифрования значительно большего количества данных, чем раньше. Как назначенный позаботиться об этом, я заменил наше старое шифрование CAST-128 (я говорю, шифрование, но это было больше похоже на хеширование, без соли и каждый раз приводил к одному и тому же зашифрованному тексту) на AES-256 и написал инструменты для перенести данные. Однако ключ шифрования все еще жестко задан в приложении и может быть извлечен в течение нескольких минут с помощью дизассемблера.
Наш продукт представляет собой настольное приложение, которое большинство наших клиентов установили самостоятельно. Большинство из них также размещают свои собственные базы данных. Поскольку у них есть весь продукт локально, обеспечение ключа кажется довольно сложной задачей.
После некоторых исследований я решил пойти по следующему пути. Во время установки для каждого клиента будет сгенерирован случайный 256-битный ключ, который будет использоваться для шифрования его данных с помощью шифрования AES. Затем сам ключ будет зашифрован с помощью DPAPI в пользовательском режиме, где единственным пользователем, который может получить доступ к данным, будет только что созданная учетная запись службы домена с ограниченными правами, которая не сможет фактически войти в систему на компьютере. Зашифрованный ключ будет храниться в ACL-части реестра. Затем модуль шифрования будет выдавать себя за этого пользователя для выполнения его функций.
Проблема в том, что, поскольку ключ будет генерироваться случайным образом во время установки и немедленно шифроваться, даже у нас его не будет. Если клиенты удаляют эту учетную запись, переустанавливают операционную систему сервера или теряют ключ каким-либо другим способом, данные будут не подлежать восстановлению. Итак, после всей этой экспозиции, возникает актуальный вопрос:
Я подумываю о том, чтобы клиенты делали резервную копию реестра, в котором хранится ключ, и предполагали, что даже после переустановки или удаления пользователя, если одна и та же учетная запись пользователя создается с тем же паролем, на том же компьютере она будет создавать то же самое Секреты DPAPI и возможность расшифровки ключа. Тем не менее, я не знаю, так ли это, потому что я не уверен, как эти секреты генерируются в первую очередь. Кто-нибудь может подтвердить, действительно ли это так? Я также открыт для предложений относительно совершенно другого подхода к хранению ключей, если вы можете придумать лучший.
1 ответ
Я не вижу связи с GDPR, но допустим, что это просто контекст.
Требуется больше, чем учетная запись пользователя, его пароль и машина. в шифрование данных с помощью DPAPI добавлено больше энтропии.
См.: https://msdn.microsoft.com/en-us/library/ms995355.aspx.
Небольшой недостаток использования пароля для входа состоит в том, что все приложения, работающие под одним и тем же пользователем, могут получить доступ к любым защищенным данным, о которых они знают. Конечно, поскольку приложения должны хранить свои собственные защищенные данные, получение доступа к данным может быть несколько сложным для других приложений, но, безусловно, не невозможным. Чтобы противодействовать этому, DPAPI позволяет приложению использовать дополнительный секрет при защите данных. Этот дополнительный секрет затем требуется для снятия защиты данных. Технически этот "секрет" следует назвать вторичной энтропией. Это вторично, потому что, хотя оно не укрепляет ключ, используемый для шифрования данных, оно увеличивает сложность одного приложения, работающего под тем же пользователем, для компрометации ключа шифрования другого приложения. Приложения должны внимательно следить за тем, как они используют и хранят эту энтропию. Если он просто сохраняется в незащищенном файле, то злоумышленники могут получить доступ к энтропии и использовать ее для снятия защиты данных приложения. Кроме того, приложение может передать структуру данных, которая будет использоваться DPAPI для запроса пользователя. Эта "структура подсказки" позволяет пользователю указать дополнительный пароль для этих конкретных данных. Мы обсудим эту структуру далее в разделе Использование DPAPI.