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

Question

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

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

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

Answer 1

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

Answer 2

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

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

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

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

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

Answer 3

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

Answer 4

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

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

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

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

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

Answer 5

Daniel Guillamot, некоторые трюки я перешедшие:

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

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