Насколько безопасны SSL-сертификаты клиентов в мобильном приложении?

Я хотел бы иметь безопасную связь между моим Android / iOS-приложением и моей интернет-доступной бэкэнд-службой, поэтому я изучаю HTTPS / SSL.

Если я создаю самозаверяющие сертификаты, то поставьте сертификат клиента в приложение и заставьте серверную службу требовать сертификат клиента, действительно ли это безопасно ?

Вот почему я спрашиваю. Похоже, что клиентский сертификат можно «взломать», опросив .apk. Сертификат клиента – это просто строковая константа, не так ли? Это означает, что любой пользователь может использовать сертификат клиента для доступа к моему бэкенду. Является ли эквивалент .apk (и iOS) достаточно непрозрачным, чтобы предотвратить обнаружение сертификата клиента ?

Solutions Collecting From Web of "Насколько безопасны SSL-сертификаты клиентов в мобильном приложении?"

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

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

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

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

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

Теперь, имея дело с сертификатами, у вас будет целый ряд других проблем. Вероятно, вы захотите подписать каждый клиентский сертификат своим самозаверяющим сертификатом CA. Управление сертификатом CA может быть проблематичным, в зависимости от вашего варианта использования. Собираетесь ли вы генерировать эти сертификаты клиентов «на лету» или вручную? Смысл, это приложение, которое может загрузить миллион человек, и вам нужна автоматическая система для их создания? Или это частное / внутреннее приложение, которое вы лично будете обрабатывать для создания сертификатов?

Как правило, клиентские SSL-сертификаты хранятся в хранилищах ключей (BKS, отформатированных в случае Android), и хранилище ключей включено в качестве ресурса в вашем APK. Хранилища шифруются и защищены паролем. Таким образом, этот клиентский сертификат не может быть легко извлечен из APK, поскольку он хранится в зашифрованном виде.

Теперь … что вы делаете с паролем? Вот суть дела, и у вас есть две альтернативы.

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

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

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

Даниэль Гилламот, некоторые трюки, которые я придумал:

  • Разделите серверный ключ. Сделать кодовую фразу для SSL-ключа будет результатом строки в приложении XOR, созданной с использованием строки из webservice.
  • Создайте строку в приложении, вызывая некоторые приложения-функции, а не жестко закодированную строку.
  • Запретить отслеживать приложение во время его запуска, чтобы избежать того, чтобы кто-то собирал последнюю кодовую фразу, когда он вызывает дешифровку закрытого ключа. Ссылка: http://books.google.no/books?id=2D50GNA1ULsC&lpg=PA294&ots=YPQQ7DLjBD&dq=The%20example%20just%20shown%20demonstrates%20how%20calls%20to%20ptrace%20can%20be%20hijacked&hl=no&pg=PA293# v = OnePage & д & е = ложь

Мне бы хотелось услышать больше, если у кого-нибудь есть другие идеи.

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