Обеспечение связи [подлинность, конфиденциальность и целостность] с мобильным приложением?

Question

Приложение Android / Iphone будет получать доступ к данным приложения с сервера. [Django-Python]

Как я могу защитить связь с мобильным приложением?

Ожидание : Достаточно безопасно для конфиденциальной информации, такой как пароли, не должно быть прямого способа расшифровки, кроме перебора.

Мои требования :

• Аутентификация [Только приложение авторизовано]
• Целостность [Между сообщениями не должно быть никаких изменений]
• Конфиденциальность [Сообщение не должно читаться при прослушивании]

Мои усилия :

• SSL аутентифицирует только Сервер, а не клиента.
• Я не могу использовать симметричное шифрование [Обеспечивает только конфиденциальность]
• Цифровая подпись невозможна [Lacks Privacy]
• PGP выполняет все 3 требования.

Проблема :

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

Итак, как я могу / должен двигаться дальше в этом направлении? Как отрасль справляется с этим?

Должен ли я реализовать случайный подход:

• Использовать простой SSL и скрестить пальцы? , так как аутентификация невозможна, если ключи украдены? (При этом возможна только аутентификация сервера)

Обновление:

Заключение состояло в том, чтобы использовать AES, так как, если я смогу сохранить ключ в безопасности, я так же хорош, как SSL. Кроме того, я могу постоянно менять ключ для большей безопасности. Внесите свой вклад, если вы думаете, что есть лучший способ, прочитайте весь пост перед публикацией.

Answer 1

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

Вот подход высокого уровня. Создайте самозаверяющий SSL-сертификат сервера и разверните его на своем веб-сервере. Если вы используете Android, вы можете использовать для этой цели keytool, включенный в Android SDK; если вы используете другую платформу приложений, такую ​​как iOS, для них также существуют аналогичные инструменты. Затем создайте самозаверяющий клиент и разверните его в своем приложении в пользовательском хранилище ключей, включенном в ваше приложение, в качестве ресурса (keytool также сгенерирует это). Настройте сервер так, чтобы он требовал SSL-аутентификацию на стороне клиента и принимал только сгенерированный вами сертификат клиента. Настройте клиент для использования этого сертификата на стороне клиента, чтобы идентифицировать себя и принять только один сертификат на стороне сервера, который вы установили на своем сервере для этой его части.

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

Шаг за шагом это гораздо более длинный ответ, чем здесь оправдано. Я бы посоветовал сделать это поэтапно, так как в Интернете есть ресурсы о том, как работать с самозаверяющим SSL-сертификатом в Android и iOS, как на стороне сервера, так и на стороне клиента. В моей книге Application Security для платформы Android , опубликованной О'Рейли, есть полный обзор.

Answer 2

SSL имеет двухстороннюю аутентификацию, как уже упоминалось другими комментаторами. Но я не думаю, что вы даже должны пытаться аутентифицировать клиента, иначе приложение. Вы аутентифицируете только пользователя (владельца ресурса в терминах Oauth), а не агента или клиента.

Это факт, что мобильные приложения не могут хранить никаких секретов. Поэтому никогда не ставьте сертификаты / пароли на устройстве. Типичным плохим примером может быть сохранение имени пользователя и пароля в некотором системном хранилище ключей, например, в IOS связке ключей. Если пользователь приложения не устанавливает пароль на телефоне, все хранилище ключей сохраняется в виде простого текста, и любой может сбросить всю информацию. Вставить сертификат в приложение практически одинаково плохо, так как в отличие от сервера мобильный телефон не заблокирован в компьютерной комнате. Люди их теряют.

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

Oauth 2.0 Неявный поток предназначен для решения этой проблемы. Тем не менее, это далеко не идеально. И есть некоторые фундаментальные проблемы со спецификацией Oauth 2.0. В частности, реализация этого потока требует, чтобы приложение использовало UIWebView (встроенный браузер), что само по себе может быть небезопасным и плохим для пользователя. Так что это в значительной степени устраняет все потоки на основе перенаправления Единственное известное приложение, которое использует поток перенаправления OAuth 2, - это Facebook, и оно сделано плохо.

Поток OAuth 2.0 Resource Owner является одним из вариантов. Благодаря такому потоку уровень безопасности всей вашей системы может быть таким же высоким, как у решения B2C - например, на основе решения для интернет-банкинга на основе браузера. Это означает, что любой пользователь с паролем имени пользователя сможет получить доступ к ресурсам на сервере - такой же уровень безопасности для решения на основе браузера.

Тем не менее, вы все равно должны быть осторожны, как упоминалось ранее, у спецификации OAuth 2 есть некоторые фундаментальные проблемы - в этом случае вы не можете следовать ее спецификации для реализации логики обновления токена - которая обычно включает использование никогда истекает токен обновления, который можно рассматривать как реализацию Google OAuth 2. Этот токен сам становится секретом - побеждает цель использования OAuth.

Одним из обходных путей является автоматическое обновление токена на основе последнего действия.

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

Вот почему банки платят миллионы за решение для мобильного банкинга, и все же они терпят неудачу (http://hothardware.com/News/Mobile-Banking-Apps-for-iOS-Vulnerable-to-Man-in-the-Middle-Attacks/) ; -)

Answer 3

Используйте аутентификацию клиента с SSL или просто наложите свою собственную аутентификацию клиента (имя пользователя / пароль, токен и т. Д.) Поверх SSL-аутентификации сервера.

(Редактировать: перемещение комментария сюда, поскольку он не подходит для комментария)

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