Роль Keychain в обеспечении качества продукта

Тестировщики, впервые столкнувшиеся с Keychain, часто не знают, как он используется в тестировании приложений под iOS и в безопасности данных пользователей. Алиса Мордвинова, QA-специалист IT Test, объясняет, как Keychain может повлиять на результаты тестирования и безопасность продукта в целом.

Keychain API в iOS

Keychain (Связка ключей) — это специализированная зашифрованная база данных, которая применяется для хранения метаданных и небольших объемов конфиденциальной пользовательской информации на компьютерах Mac (при наличии разрешений) и устройствах с iOS. Keychain также используется для обеспечения дополнительной защиты при входе в приложения / веб-сайты.

Данные «живут» в хранилище для временных файлов во время перезапуска и удаления приложения, то есть после переустановки приложения все токены, пароли и прочие данные не удаляются сразу. Именно поэтому, даже установив приложение заново, в него зачастую можно войти без необходимости повторной авторизации. Данные можно очистить, если того требует бизнес-логика, например, если необходимо сбросить логин пользователя при удалении приложения: для этого можно использовать добавление уникального uuid к хранимым в Keychain ключам, который будет храниться в UserDefaults и очищаться при удалении приложения.

Keychain API Services являются частью фреймворка Security, поэтому разберем его подробнее.

Как работает Security

Security использует структуру безопасности для защиты информации, установления доверия и управления доступом к программному обеспечению. В целом, службы безопасности отвечают следующим задачам:

▪️ установление личности пользователя (аутентификация), а затем выборочное предоставление доступа к ресурсам (авторизация);

▪️ защита данных как на диске, так и при передаче по сети.

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

Схема показывает приложение, расположенное над платформой безопасности.

Нужно всегда использовать API самого высокого уровня, который соответствует вашим потребностям, так как более низкий уровень не обеспечит должной безопасности. Только если вашему приложению требуется доступ более низкого уровня к функциям протокола безопасности, то можно напрямую использовать безопасный транспортный API, однако для его настройки требуются отдельные действия. Платформа безопасности не всегда является лучшим вариантом: для обеспечения безопасного сетевого взаимодействия лучше начинать с рассмотрения системы загрузки URL-адресов платформы Foundation, которая основана на платформе безопасности.

Тестирование приложений со знанием работы Keychain

Где со всем этим может столкнуться тестировщик? Расскажу на примере из практики. У нас было два тестировщика и два девайса с одним Apple ID. В приложении авторизация не производилась. В ходе тестирования было обнаружено, что при добавлении/удалении товаров на одном девайсе, они появляются и на другом, на котором не производилось никаких действий. Мне тогда объяснили это так: «Keychain синхронизирует значения через uuid, который используется для anonymous + синхронизации девайсов Apple». Не зная про Keychain, я отправилась изучать документацию Apple.

Как оказалось, в Keychain вместе с данными пользователя (Touch ID, Face ID, электронная почта, номер телефона и другая информация, которую мы вносили когда создавали/входили в Apple ID) сохранились временные файлы. Так я выяснила, что встроенная в Keychain функция SecSharedCredentials API предоставляет возможности для хранения и запроса общих учетных данных на основе пароля.

Пользователи часто сохраняют свое имя пользователя и пароль в связке ключей iCloud при входе на веб-сайты в Safari или в приложения. То есть с общими веб-учетными данными приложение может получить доступ к учетным данным, сохраненным для веб-сайта, вместо того, чтобы требовать от пользователя повторного ввода имени пользователя и пароля.

Apple ID, что логично, имеет идентификатор, которым является учетная запись для доступа ко всем сервисам Apple, и она обеспечивает слаженное взаимодействие всех устройств пользователя. И всё это, в том числе двухфакторная аутентификация, сделано для защиты от фишинга — вида интернет-мошенничества, целью которого является получение доступа к конфиденциальным данным пользователей, — логинам и паролям. И если у вас проскочила мысль «Да кому нужны мои данные», то это может быть кто угодно — конкурент, желающий получить прибыль, коллега, жаждущий преуспеть, или даже члены семьи, которые, возможно, просто хотят узнать ваш виш-лист.

Сертификаты, ключи и службы доверия для передачи данных

Сертификаты, ключи и доверенные службы API представляет собой набор функций и структур данных, которые используются для проведения безопасных и аутентифицированных транзакций данных. В частности, этот API используется для управления и использования следующих объектов.

▪️ Сертификаты и удостоверения, где сертификат — это набор данных, идентифицирующий владельца с защитой от несанкционированного доступа. Когда мы используем сертификат для распространения открытого ключа, получатель может быть уверен в его подлинности. Также можно упаковать сертификат вместе с соответствующим закрытым ключом в идентифицирующий объект, который должен держаться в секрете.

▪️ Политики и трастовые услуги. При получении сертификата, прежде чем использовать встроенный открытый ключ, нужно понять, можно ли доверять этому сертификату, провести оценку доверия в соответствии с набором критериев или политикой доверия.

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

Зачем используются ключи и можно ли обойтись без них

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

Отличный сервис для хранения паролей – API keychain. Он предоставляет приложению механизм для хранения небольших объемов пользовательских данных в зашифрованной базе данных keychain. Когда через приложение мы сохраняем надежный пароль в этой базе, пользователь освобождается от сложной задачи.

Keychain не ограничивается паролями. Можно также хранить другие данные, которые важны для пользователя, например, информацию о кредитной карте или даже короткие заметки. Кроме того, keychain позволяет хранить криптографические ключи и сертификаты, управляемые с помощью служб сертификатов, ключей и разрешений. Они обеспечивают защищенную коммуникацию и устанавливают доверительные отношения с другими пользователями и устройствами.

Как работает функция App Transport Security (ATS)

На платформах Apple функция сетевой безопасности «App Transport Security» (ATS) повышает конфиденциальность и целостность данных для всех приложений и их расширений. Для этого требуется, чтобы сетевые подключения, созданные вашим приложением, были защищены протоколом безопасности транспортного уровня (TLS) с использованием надежных сертификатов и шифров. ATS блокирует соединения, не отвечающие минимальным требованиям безопасности.

ATS работает по умолчанию для приложений, связанных с SDK iOS 9.0 или macOS 10,11 или более поздней версией (с другими версиями ATS отключается независимо от того, в какой OS работает приложение). В тех случаях, когда нужно подключиться к серверу, который не является полностью безопасным, или нет возможности его перенастроить для обеспечения большей безопасности, можно добавить исключения, снизив некоторые требования ATS.

Система применяет ATS, когда используется стандартная система загрузки URL. Экземпляры URLSession автоматически согласовывают наиболее безопасное соединение, доступное с сервером. То есть нужно использовать безопасные URL-адреса, например, те, которые начинаются с https. В противном случае ATS отказывает в соединении.

Нужно убедиться, что сетевой сервер соответствует минимальным требованиям, ведь подключающийся клиент проверяет этот сертификат, чтобы выполнить оценку доверия сервера. Соответственно, сертификат должен:

▪️ иметь неповрежденную цифровую подпись, показывающую, что сертификат не был подделан;

▪️ не быть просроченным;

▪️ иметь имя, совпадающее с DNS-именем сервера;

▪️ быть подписанным другим действительным сертификатом, который, в свою очередь, подписан другим, и так далее до доверенного сертификата привязки*, выданным центром сертификации (ЦС).

*Сертификат должен быть частью клиентской операционной системы, как указано в списках доступных доверенных корневых сертификатов в iOS, или быть установленным пользователем или системным администратором.

Если все так, как указано выше, то ATS предоставляет расширенные проверки безопасности:

▪️ сертификат сервера должен быть подписан ключом Rivest-Shamir-Adleman (RSA) длиной не менее 2048 бит или ключом криптографии на основе эллиптических кривых (ECC) длиной не менее 256 бит;

▪️ сертификат должен использовать Secure Hash Algorithm 2 (SHA-2) — алгоритм безопасного хеширования 2 с длиной дайджеста, иногда называемой отпечатком пальца, не менее 256 бит (SHA-256 или больше);

▪️ соединение должно использовать протокол Transport Layer Security (TLS) версии 1.2 или более поздней;

▪️ обмен данными должен осуществляться с использованием симметричного шифра AES-128 или AES-256;

▪️ канал должен поддерживать совершенную прямую секретность (PFS) посредством обмена ключами на основе эфемерных ключей Диффи-Хеллмана на эллиптических кривых (ECDHE).

Если нужно настроить исключения, то у Apple есть инструкция (см. инструкцию).

Как получить политики для установления доверия

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

Чтобы настроить работу именно так, как удобно вам, можно перейти со стандартной предопределенной политики — базовой X509 или SSL — на собственную политику. Делается это с помощью сертификата, ключа и API служб доверия.

Еще раз про важность Keychain

Таким образом, мы выяснили, что Keychain — это обязательная часть в работе приложений: без него данные не будут в безопасности, к приложению не будет доверия, и это принесет большие проблемы разработчикам. В этой статье мы рассказали, почему инженерам по обеспечению качества при тестировании iOS важно понимать, как Apple ID и uuid взаимодействуют с приложением, а также то, для чего необходимо иметь разнообразные сложные данные для входа и как это воспринимает обычный пользователь.