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

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

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

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

Ответ 1

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

разделить серверный ключ. Сделать кодовую фразу для SSL-ключа яв- ляется результатом строковой привязки строки в приложении XOR из веб-службы.
создать строку в приложении, вызвав некоторые приложения-функции, а не жестко закодированную строку.
Запретить отслеживать приложение во время его работы, чтобы избежать того, чтобы кто-то собирал последнюю кодовую фразу при вызове дешифрования закрытого ключа. Ссылка: 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&q&f=false

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

Ответ 5

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