Итак, если передавать команде security требуемые параметры один за другим, то можно получить свойства интересующего вас пароля (см. рис. 8.3):

Как было показано ранее, команда — g запросит команду security отобразить пароль, ассоциированный с указанным элементом (при наличии такого пароля). Следовательно, после ввода этой команды в окно терминала вам будет предложено ввести пароль к вашей учетной записи перед продолжением работы. Аналогичным образом мы указывали пароль к учетной записи, чтобы отобразить пароль на рис. 8.3.

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

• App X — к области связки ключей приложения App X.

• App Y — к области связки ключей приложения App Y.

• Приложения App X и App Y обладают доступом к общему разделяемому участку связки ключей (с применением групп доступа, если программист соответствующим образом сконфигурирует разрешения для этого приложения).

• App X не может считывать информацию из связки ключей приложения App Y, а приложение App Y не может считывать аналогичные данные приложения App X.

Операционная система iOS просматривает разрешения приложения, чтобы определить требуемый тип доступа. Разрешения для конкретной программы кодируются в профиле инициализации, который использовался при подписывании приложения. Допустим, мы создали новый профиль инициализации под названием KeychainTest_Dev.mobileprovision. Этот профиль был размещен на Рабочем столе. С помощью следующей команды можно извлечь разрешения, соответствующие данному профилю, вот так:

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

Вывод этой команды будет выглядеть примерно следующим образом в зависимости от вашего профиля:

Самый важный раздел, который нас здесь интересует, называется keychain-access-groups. Здесь указываются группы доступа к нашим элементам из связки ключей. Это групповой идентификатор для всех приложений, разработанных одним и тем же программистом. Здесь F3FU372W5M — это мой командный идентификатор с портала разработки для iOS. Идущий далее астериск показывает, в какие группы доступа я могу позже поместить те элементы, которые требуется хранить в защищенном режиме. В данном случае астериск означает любую группу. Поэтому по умолчанию это приложение получает доступ к элементам связок ключей любого приложения, которое разработано членами вышеупомянутой команды. Не волнуйтесь, если пока не совсем улавливаете суть. В этой главе вы подробно изучите тему безопасности в iOS, в частности, к концу главы будете знать все необходимое об использовании связок ключей в iOS.

Совершенно необходимо добавить к вашему приложению фреймворк Security (Безопасность), перед тем как переходить к изучению разделов этой главы. Большинство приемов, описанных в данной главе, работает со службами связки ключей в iOS, а для этого необходимо наличие фреймворка Security. В iOS SDK 7 появилась концепция модулей. Поэтому если вы просто импортируете обобщающий заголовок фреймворка безопасности в ваш проект, LLVM сам свяжет ваше приложение с нужным модулем безопасности — делать это вручную не придется. Вам всего лишь понадобится гарантировать, что в настройках сборки активизирована функция Enable Modules (Использовать модули), а также импортировать в проект следующий заголовок: