Защита секретных ключей API в толстом клиентском приложении

Question

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

Является ли запутывание сборки хорошим способом защиты этих ключей?

Answer 1

Скорее всего, нет.

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

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

Answer 2

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

Если вы просто хотите, чтобы это было несколько сложнее увидеть, вы могли бы запустить простой шифр для открытого текста (например, ROT-13 или что-то в этом роде), чтобы он, по крайней мере, не сохранялся в открытом виде в самом коде.Но это, конечно, не остановит ни одного решительного хакера от доступа к вашему ключу.Более надежный метод шифрования не поможет, потому что вам все равно нужно будет сохранить ключ для ЭТОГО в коде, а его ничто не защищает.

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

Я поиграл с идеей сделать это для своих приложений, но так и не реализовал ее.

Answer 3

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

Однако, чего именно вы пытаетесь достичь?

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

Answer 4

Здесь опаздывают на игру...

Подход к хранению ключей в сборке / assembly config принципиально небезопасен.Не существует надежного способа сохранить его, поскольку определенный пользователь будет иметь доступ.Мне все равно, используете ли вы лучший / самый дорогой продукт для обфускации на планете.Меня не волнует, используете ли вы PDAPI для защиты данных (хотя так лучше).Меня не волнует, используете ли вы локальное хранилище ключей, защищенное операционной системой (это еще лучше).Ни один из них не идеален, поскольку все они страдают от одной и той же основной проблемы:пользователь имеет доступ к ключам, и они находятся там, не меняясь в течение нескольких дней, недель, возможно, даже месяцев и лет.

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

Если вас беспокоит производительность, вы можете использовать Диффи-Хеллмана поверх асимметричной PKI для создания общего секретного симметричного ключа для использования с шифром, таким как AES."общий" в данном случае означает общий доступ между клиентом и сервером, а не всеми клиентами /пользователями.Там нет жестко закодированного / запеченного ключа.Где угодно.

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

Вычисленные совместно используемые секретные симметричные ключи сами по себе сохраняются только в памяти, в SecureString.Их трудно извлечь, и даже если вы это сделаете, они хороши только на очень короткое время и только для связи между этим конкретным клиентом (т.Е. этим сеансом).Другими словами, даже если кто-то взломает их локальные ключи, они хороши только для вмешательства в локальную коммуникацию.Они не могут использовать эти знания для воздействия на других пользователей, в отличие от встроенного ключа, общего для всех пользователей через code / config.

Более того, сами ключи целиком никогда не передаются по сети.Клиент Alice и сервер Bob вычисляют их независимо.Информация, которую они передают для того, чтобы сделать это, теоретически может быть перехвачена третьей стороной Charlie, что позволит ему самостоятельно вычислить общий секретный ключ.Вот почему вы используете эту (значительно более дорогостоящую) асимметричную PKI для защиты генерации ключей между Алисой и Бобом.

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

Но подождите:мы еще не в безопасности.Мы только помешали читать сообщения.

Обратите внимание, что по-прежнему необходимо использовать механизм дайджеста сообщений, чтобы предотвратить манипуляции "человек посередине".Хотя никто не может прочитать передаваемые данные, без MD ничто не мешает им изменить их.Таким образом, вы хэшируете сообщение перед шифрованием, а затем отправляете хэш вместе с сообщением.Затем сервер повторно хэширует полезную нагрузку после расшифровки и проверяет, соответствует ли она хэшу, который был частью сообщения.Если сообщение было изменено при передаче, они этого не сделают, и все сообщение будет отброшено / проигнорировано.

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

Что должно быть очевидным, так это то, что сделать это правильно непросто.Таким образом, используйте PKI, если только вы АБСОЛЮТНО не можете этого сделать.

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

Итак, в заключение, если это действительно вызывает беспокойство, вместо того, чтобы пытаться найти безопасное хранилище ключей API, не делайте этого.Вместо этого измените, как ваше приложение использует этот API (естественно, при условии, что вы контролируете обе стороны).Используйте PKI или используйте симметричный гибрид с общим доступом к PKI, если PKI будет слишком медленной (что в наши дни РЕДКО является проблемой).Тогда у вас не будет сохранено ничего, что представляет угрозу безопасности.