Безопасно ли использовать закрытый ключ для декодирования сообщения сервера на стороне клиента?

Question

Обычно эта история выглядит так: «Клиент шифрует с помощью ключа publi c - сервер расшифровывает с помощью очень надежно хранимого закрытого ключа».

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

Я знаю, что это все еще небезопасно, но, по крайней мере, простая атака «человек посередине» или бинарный анализ декомпиляции не будет кричать: «Здесь ключи сервисного API, приходите и возьмите их!». Его цель состоит в том, чтобы кому-то было труднее получить эти ключи ключи.

Как вы думаете, это будет хорошей идеей? Есть ли у вас другие альтернативы?

Answer 1

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

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

Конечные точки могут использовать некоторую аутентификацию, такую ​​как токены носителя JWT (см. https://www.jsonwebtoken.io/), чтобы убедиться, что они используются только приложением, но для этого требуется информация на стороне сервера о том, кто зарегистрирован в приложении.

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