Надежно хранящая дополнительная энтропия, в то время как Используя DPAPI
Таким образом, я пытаюсь сохранить симметричный ключ с помощью DPAPI. Все хорошо и великое, но что сделать с энтропией? Этот вопрос, на который отвечают, здесь действительно не обеспечивает достаточно понимания. Это походит на скользкий путь - что я мог использовать хранилище машины для хранения энтропии, но затем что препятствует тому, чтобы кто-то достиг это также?Примечание: Я храню текущий ключ с помощью Пользовательского Объема.
Таким образом, мой вопрос - что лучший способ состоит в том, чтобы сохранить энтропию с помощью DPAPI?
2 ответа
Все, что вы храните локально, может быть взломано. Но есть шаги, которые можно предпринять, чтобы усложнить задачу. Существует документ Обработка паролей , который вы можете просмотреть. Вы считаете свой ключ энтропии паролем, специфичным для вашего приложения.
Я буду называть вашу энтропию вашим ключом , поскольку это функционально дополнительный ключ.
Чего вы не хотите, так это хранить ключ локально в незашифрованном формате. Вместо этого вы хотите либо зашифровать свой ключ, либо получить его из другого, неочевидного источника. Конечно, если вы шифруете ключ, вам необходимо сохранить ключ, использованный для его шифрования, но часто этого одного уровня косвенного обращения достаточно, чтобы отпугнуть большинство противников.
Это было бы преимуществом получения вашего ключа. Вы можете получить его как хэш некоторой другой части постоянных данных (это должно быть что-то, что не меняется с изменениями вашего приложения). Одна из уловок при получении хэша состоит в том, чтобы объединить хэш с некоторым другим постоянным значением (например, GUID или большим случайным числом), чтобы кто-то другой не мог просто объединить известный алгоритм хеширования и получить ваш ключ. Это гораздо лучшая альтернатива созданию собственного алгоритма хеширования (чего никогда не следует делать, если у вас нет докторской степени по математике).
В какой-то момент вам понадобится какой-то ключ, жестко закодированный в вашем приложении. Этот ключ либо объединяется с некоторыми другими данными в хэше для создания вашего ключа энтропии, либо используется для расшифровки ключа энтропии.Фактически вы можете изменить ключ с новой версией вашего приложения, если вы сохраните старый ключ для расшифровки существующего ключа. Затем вы можете повторно зашифровать его с помощью нового ключа или метода.
Если вам нужна максимальная безопасность, вы можете сохранить ключ Entropy вне компьютера. Для этого потребуется подключение к Интернету и сертификат SSL, но тогда их ключ никогда не сохраняется где-либо локально, чтобы его можно было обнаружить. Для этого вы можете настроить более надежную систему ответа на запрос, чтобы аутентификация запроса каждый раз была разной, а ключ доставлялся через шифрование SSL, поэтому его нельзя было перехватить. Как только ключ использован, его выбрасывают. Конечно, такого рода неудачи преследуют цель многих сценариев, в которых вы используете DPAPI для локального безопасного хранилища.
Что бы вы ни делали, помните, что это будет скомпрометировано - это всегда происходит, когда кто-то имеет полный доступ к локальной машине и данным, хранящимся на ней. Решение состоит в том, чтобы продолжать выпускать обновления, которые изменяют метод настолько, что старая трещина больше не работает. Это сделает распространение крэка менее ценным, так как будет сложно найти его для правильной версии.
Во-первых, позвольте мне ответить на исходный вопрос публикации. Это сводится к тому, что энтропия должна храниться под управлением пользователя и / или приложения, если она будет использоваться для постоянного хранения. Я полагаю, вы могли бы использовать ключ, хранящийся в приложении, для шифрования информации в постоянном хранилище, но опять же вредоносное приложение сможет получить доступ к этому ключу шифрования. Итак, я не думаю, что есть средства защиты от сценария, который вы упоминаете в комментариях. Однако, учитывая то, что вы сказали, является предполагаемым использованием энтропии, я не чувствую, что это помогает в решении вашей проблемы.
Похоже, настоящая проблема заключается в установлении безопасного канала связи между вашим клиентским приложением и сервером. В вашем дизайне вы обмениваетесь ключами, которые будут использоваться для шифрования связи. Я думаю, что попытка использовать собственный код для решения этой проблемы приведет к дополнительным уязвимостям безопасности.
Учитывая все это, я бы предложил создать службу WCF (Windows Communication Foundation), которая будет использоваться для получения конфиденциальной информации. Очевидно, его можно использовать для получения всей информации, но наименьшее количество изменений будет заключаться в ограничении службы конфиденциальной информацией.
С помощью WCF вы можете настроить и клиент, и сервер на использование безопасного канала. WCF имеет множество вариантов для установления безопасного канала связи с сервером.
<wsHttpBinding>
<binding>
<security mode="Transport">
<transport clientCredentialType="Windows" />
</security>
</binding>
</wsHttpBinding>
Если у вас есть защищенный канал, многие другие проблемы становятся проще, например, доступ к данным CC.Если эти данные отправляются по защищенному каналу, это становится проблемой авторизации, а не безопасности канала.
См. Как создать безопасный сеанс для получения дополнительной информации.