Мы можем использовать команду security в окне терминала для выборки ровно той же информации. Если ввести в окне терминала следующую команду:
security find-generic-password — help
то получится примерно такой вывод:
Usage: find-generic-password [-a account] [-s service]
[options…] [-g] [keychain…]
— a Match «account» string
— c Match «creator» (four-character code)
— C Match «type» (four-character code)
— D Match «kind» string
— G Match «value» string (generic attribute)
— j Match «comment» string
— l Match «label» string
— s Match «service» string
— g Display the password for the item found
— w Display only the password on stdout
If no keychains are specified to search, the default search list is used.
Find a generic password item.
Итак, если передавать команде security требуемые параметры один за другим, то можно получить свойства интересующего вас пароля (см. рис. 8.3):
security find-generic-password
— a «AirPort»
— s «com.apple.network.wlan.ssid.206-NET»
— D «AirPort network password»
— l «206-NET»
— g login.keychain
Как было показано ранее, команда — 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. Этот профиль был размещен на Рабочем столе. С помощью следующей команды можно извлечь разрешения, соответствующие данному профилю, вот так:
cd ~/Desktop
Эта команда выведет вас на Рабочий стол. Уже здесь нужно выполнить следующую команду, чтобы считать разрешения из профиля инициализации:
security cms — D -i KeychainTest_Dev.mobileprovision | grep — A12 «Entitlements»
Показанная здесь команда security декодирует весь профиль инициализации, после чего команда grep просмотрит раздел Entitlements (Разрешения) в профиле и считает 12 строк текста от начала этого раздела. Если в вашем разделе с разрешениями содержится больше или меньше текста, то нужно соответствующим образом изменить аргумент — A12.
Вывод этой команды будет выглядеть примерно следующим образом в зависимости от вашего профиля:
<key>Entitlements</key>
<dict>
<key>application-identifier</key>
<string>F3FU372W5M.com.pixolity.ios.cookbook.KeychainTest</string>
<key>com.apple.developer.default-data-protection</key>
<string>NSFileProtectionComplete</string>
<key>get-task-allow</key>
<true/>
<key>keychain-access-groups</key>
<array>
<string>F3FU372W5M.*</string>
</array>
</dict>
Самый важный раздел, который нас здесь интересует, называется keychain-access-groups. Здесь указываются группы доступа к нашим элементам из связки ключей. Это групповой идентификатор для всех приложений, разработанных одним и тем же программистом. Здесь F3FU372W5M — это мой командный идентификатор с портала разработки для iOS. Идущий далее астериск показывает, в какие группы доступа я могу позже поместить те элементы, которые требуется хранить в защищенном режиме. В данном случае астериск означает любую группу. Поэтому по умолчанию это приложение получает доступ к элементам связок ключей любого приложения, которое разработано членами вышеупомянутой команды. Не волнуйтесь, если пока не совсем улавливаете суть. В этой главе вы подробно изучите тему безопасности в iOS, в частности, к концу главы будете знать все необходимое об использовании связок ключей в iOS.
Совершенно необходимо добавить к вашему приложению фреймворк Security (Безопасность), перед тем как переходить к изучению разделов этой главы. Большинство приемов, описанных в данной главе, работает со службами связки ключей в iOS, а для этого необходимо наличие фреймворка Security. В iOS SDK 7 появилась концепция модулей. Поэтому если вы просто импортируете обобщающий заголовок фреймворка безопасности в ваш проект, LLVM сам свяжет ваше приложение с нужным модулем безопасности — делать это вручную не придется. Вам всего лишь понадобится гарантировать, что в настройках сборки активизирована функция Enable Modules (Использовать модули), а также импортировать в проект следующий заголовок:
#import <Security/Security.h>
В Xcode 5 также появилась поддержка «возможностей» (Capabilities). Это новая вкладка, расположенная рядом с вкладкой Build Settings (Настройки сборки). Здесь вы можете с легкостью добавлять разрешения к вашему приложению и даже активизировать связку ключей без особых хлопот. Тем не менее, работая таким образом, вы теряете доступ практически ко всем деталям и не можете создавать собственные профили инициализации. В вашем распоряжении будут только джокерные профили инициализации, которыми мы обычно не пользуемся, реализуя в приложениях пуш-уведомления и другие возможности. Рекомендую хотя бы познакомиться с этой новой вкладкой. Просто щелкните на файле с вашим проектом в Xcode, посмотрите на правую часть экрана и выберите Capabilities (Возможности). Затем можно будет отключить компоненты iCloud и Keychain Access.
8.1. Обеспечение безопасности и защиты в приложениях
Требуется сохранять значения в связке ключей и обеспечить в приложении безопасное хранение данных.
Создайте в приложении профиль инициализации, в котором активизирована защита файлов.
Профили инициализации, уже упоминавшиеся ранее (см. раздел 8.0), содержат разрешения. Разрешения указывают системе iOS, как ваше приложение использует возможности безопасности, предоставляемые операционной системой. В эмуляторе iOS используется код без подписи (отсутствует этап, называемый code signing), следовательно, такие концепции будут лишены смысла. Но при отладке приложения или отправке его в App Store вы должны будете гарантировать, что приложение подписано корректным профилем инициализации одновременно для схем Debug (Отладка) и Release (Выпуск).
Я продемонстрирую все шаги, необходимые для создания действительного профиля реализации при разработке, а также опишу профили Ad Hoc и App Store. Выполните следующие шаги, чтобы создать валидный профиль инициализации для целей разработки (с поддержкой отладки). Он будет использоваться с приложениями, над которыми мы будем работать в данной главе. Начнем с создания ID приложения.
Предполагается, что вы уже создали для себя валидные сертификаты на разработку и распространение приложения.
1. Перейдите в iOS Dev Center и войдите в систему под своими именем и паролем.
2. Найдите раздел iOS Development Program (Программа разработки для iOS) и выберите Certificates, Identifiers & Profiles (Сертификаты, идентификаторы и профили).
3. Найдите в левой части экрана область App IDs (Идентификаторы приложений) и нажмите кнопку +, чтобы создать новый такой идентификатор.
4. В области Name (Имя) введите имя Security App. На самом деле здесь можно указать любое имя, но, чтобы избежать путаницы в этой главе, лучше воспользоваться данным именем, которое я буду применять в примерах.
