Надежное хранение дополнительной энтропии при использовании DPAPI - PullRequest
8 голосов
/ 06 апреля 2010

Итак, я пытаюсь сохранить симметричный ключ с помощью DPAPI.Все хорошо, но что делать с энтропией?Ответ на вопрос здесь действительно не дает достаточного понимания.Это похоже на скользкий уклон - я мог бы использовать машинный магазин для хранения энтропии, но что же мешает кому-то это сделать?Примечание. Я храню текущий ключ с помощью пользовательской области.

Поэтому мой вопрос - как лучше всего хранить энтропию с помощью DPAPI?

Ответы [ 2 ]

6 голосов
/ 10 апреля 2010

Все, что вы храните локально, может быть взломано. Но есть шаги, которые вы можете предпринять, чтобы сделать это более сложным. На Обработка паролей есть документ, который вы можете рассмотреть. Вы считаете свой Entropy Key паролем, специфичным для вашего приложения.

Я буду называть вашу энтропию вашей клавишей , поскольку это функциональная дополнительная клавиша.

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

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

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

Если вы хотите обеспечить максимальную безопасность, вы можете хранить ключ энтропии на компьютере. Для этого потребуется подключение к Интернету и сертификат SSL, но тогда их ключ никогда не будет сохранен где-либо локально, чтобы быть обнаруженным. Для этого вы можете настроить более надежную систему ответа на вызовы, чтобы аутентификация запроса каждый раз отличалась, а ключ доставлялся через шифрование SSL, поэтому его нельзя было перехватить. Как только ключ используется, он сбрасывается. Конечно, этот вид поражает цель многих сценариев, в которых вы используете DPAPI для локального безопасного хранения.

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

0 голосов
/ 15 апреля 2010

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

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

Учитывая все это, я бы предложил создать службу WCF (Windows Communication Foundation), которая используется для получения конфиденциальной информации. Очевидно, что его можно использовать для получения всей информации, но наименьшее количество изменений будет заключаться в ограничении службы конфиденциальной информацией.

С помощью WCF вы можете настроить как клиент, так и сервер для использования безопасного канала. WCF имеет множество вариантов для установки безопасного канала связи с сервером.

<wsHttpBinding>
    <binding>
        <security mode="Transport">
            <transport clientCredentialType="Windows" />
        </security>
    </binding>
</wsHttpBinding>

Если у вас есть защищенный канал, многие другие проблемы проще, например, доступ к данным CC. Если эти данные отправляются по безопасному каналу, вместо обеспечения безопасности канала возникает проблема авторизации.

См. Как: создать безопасный сеанс для получения дополнительной информации.

...