Лучший способ скрыть ключ API в исходном коде

Мне нужны некоторые идеи о том, как защитить частный ключ API в приложении, особенно в приложении ac # .NET.

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

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

Любые идеи о том, как я могу это сделать, будут с благодарностью.

Подвести итоги:

• У вас есть ключ API, выданный вам поставщиком, чтобы вы могли использовать его API, и вы обязаны не допустить, чтобы этот ключ был известен кому-либо еще
• Вы делаете вызовы API этого поставщика (для которого требуется ключ API) в коде вашего приложения
• Вы развертываете приложение в системах, где клиенты имеют доступ к двоичным файлам и, таким образом, могут потенциально декомпилировать / деобфускировать код или перехватывать трафик

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

В конечном счете, если двоичные файлы находятся вне вашего контроля, все в них находится вне вашего контроля. Аналогично, если кто-то может перехватить трафик, он может получить ключ API ( возможно, даже если вы используете SSL ).

Я вижу два основных способа сделать это, оба из которых не включают ваш закрытый ключ API в ваше развернутое приложение:

Получите уникальный ключ API для каждого развертывания

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

Это на самом деле довольно часто встречается, например, с продуктами, которые используют Google Maps API. Создатель программного обеспечения имеет свой собственный ключ, который он использует при разработке / запуске своей копии, но он не включает его в программное обеспечение и вместо этого требует, чтобы вы, как пользователь, устанавливающий указанное программное обеспечение, обратились в Google и получили свой собственный API ключ. Программное обеспечение просто имеет параметр конфигурации для установки ключа API Карт Google для использования.

На самом деле, многие поставщики, которые выдают ключи API по контракту, требуют, чтобы вы поступали таким образом, так что в любом случае вы можете даже оказаться на неверном пути, и это может быть единственным решением, которое вам разрешено использовать в соответствии с Условиями обслуживания поставщика и / или любые юридические контракты, которые вы можете иметь с ними.

Использовать прокси

Настройте прокси-API, где ваше приложение вызывает ваш API (на ваших серверах), и, в свою очередь, ваш API вызывает API поставщика с помощью ключа.

Вам может потребоваться дополнительная защита вашего API, например, что-то, чтобы гарантировать, что только ваше приложение использует его. Это может быть сделано:

• не делая ничего особенного, кроме вашего приложения, его можно использовать
• Белые списки IP
• Существующий механизм лицензирования / авторизации для ваших серверов.
• Ваша собственная система ключей API, где вы можете выдавать ключи своим клиентам

Здесь нужно помнить, что вам может быть запрещено это делать. У вашего поставщика могут быть Условия обслуживания или юридические контракты, которые мешают вам создать «службу агрегирования» или прокси-сервер, поэтому вам необходимо проверить это.

Обращение с неправильным поведением

Даже если ваш ключ не скомпрометирован, если один из ваших клиентов делает что-то, что заставляет поставщика заблокировать ваш ключ, внезапно ВСЕ ваши клиенты отключаются, и ваше единственное исправление - это обновить всех остальных.

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

Логистика этого для чего-либо кроме горстки клиентов быстро станет несостоятельной.

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

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

Так что не встраивайте это. «Единственный выигрышный ход - не играть».

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