«Зв'язка ключів» - це менеджер імен облікових записів і паролів, а також даних кредитних карт, за допомогою якого значення, введені один раз на одному з пристроїв, можуть бути збережені на іншому засобами iCloud. З її допомогою можна позбутися від необхідності вводити один і той же для авторизації на сайтах або оплати товарів і послуг через Safari на iPhone, iPad і комп'ютерах Mac. Довіряти свої дані хмарного сервісу від Apple чи ні - індивідуальна справа кожного. Проте, необхідно усвідомлювати, що всі вони зберігаються на серверах компанії в зашифрованому вигляді і не можуть бути переглянуті працівниками компанії.
Так як же налаштувати і використовувати функцію «Зв'язка ключів» на iPhone і iPad на iOS 7?
1. Зайти в додаток «Налаштування» операційної системи iOS 7:
2. Перейти в розділ iCloud:
3. Зайти в меню «Зв'язка ключів»:
4. Пересунути перемикач включення функції в активне положення (може знадобитися введення пароля від аккаунта Apple ID):
5. Придумати, ввести і про необхідність повторного введення коду безпеки iCloud для обмеження доступу до функції «Зв'язка ключів»:
6. Вибрати свою країну проживання, ввести номер свого телефону і підтвердити дані натисканням кнопки «Далі»:
7. Тепер під час введення даних облікових записів або кредитних карт на сторінках мережі інтернет в Safari, користувачеві буде запропонована можливість їх збереження для подальшого доступу до них з інших пристроїв:
Таким чином, налаштувавши функцію «Зв'язка ключів» на всіх своїх пристроях, можна позбутися від необхідності раз за разом вводити дані своїх облікових записів на численних сервісах, ввівши їх лише один раз на одному з пристроїв, прив'язаних до одного Apple ID.
«Зв'язка ключів iCloud» - технологія зберігання і синхронізації конфіденційних даних на iPhone, iPad, iPod Touch і комп'ютерах Mac. У розряд, що зберігається потрапляють такі позиції: логіни і паролі для новинних і розважальних ресурсів, соціальних мереж; додані кредитні карти для оплати, ключі для авторизації в захищених точках Wi-Fi.
З недавніх пір розробники з Apple передають між різними пристроямиі дані з сторонніх додатків - «Календарів», «Контактів», «Пошти» і повідомлень «iMassage». Головна ідея «Зв'язки ключів iCloud» - надати користувачам послуги захищеного (256-бітове шифрування AES) менеджера паролів, що працює з будь-якими даними і який дозволяє не запам'ятовувати інформацію, а погоджуватися на автоматичне заповнення доступних текстових форм для авторизації або оплати.
Як налаштувати і користуватися?
Технологія - зв'язка ключів iCloud - доступна на операційній системі iOS? починаючи з версії 7.0.3 і на MacOS з Mavericks 10.9, і відкрита практично у всіх регіонах світу (докладніше про обмеження розробники пишуть в спеціальному розділі на офіційному сайті Apple). Якщо умови сходяться, залишилося пройти по пунктам початкового налаштування:
- На iPad, iPhone і iPod Touch відкрити «Налаштування» і перейти до редагування поточного профілю iCloud;
- У нижній частині доступного менюзнайти пункт «Зв'язка ключів», а потім перевести повзунок в активне положення;
-
- На комп'ютерах Mac процедура ще простіше - зайти в « Системні налаштування iCloud »і проставити галочку навпроти однойменного пункту;
-
- Якщо система попросить авторизуватися - доведеться ввести дані від поточного аккаунта Apple ID;
- Якщо в профілі активна двухфакторная авторизація, то доведеться підтвердити дії на сусідньому, доданим до профілю, гаджет (необхідно ввести 6-значний код і дозволити роботу над настройками iCloud).
Якщо з повторенням описаних дій не виникло проблем, і з'явилося бажання випробувати систему зберігання і синхронізації даних, то залишається розібратися в деталях.
- Заглянути в «Налаштування», спуститися нижче по меню до пункту «Паролі та облікові записи»;
- Відкрився розділ дозволить переглянути поточні облікові записи, додані в систему (iCloud, можливо, Gmail або ж якась електронна поштавітчизняного виробництва). У верхній частині з'явиться нове меню - «Паролі сайтів і програм». Тут і записані дані для швидкої авторизації, що використовуються в технології «Зв'язка паролів iCloud»;
- Тому якщо з'явилося бажання випробувати систему, необхідно потрапити всередину, а потім - натиснути на плюсик у верхній частині меню. Після чого, на екрані відобразиться невелика форма для подальшої взаємодії. Важливо ввести адресу веб-сайту (підійде і Головна сторінка, Необов'язково сильно заглиблюватися і додавати посилання на розділ з особистим кабінетом, Система в усьому розбереться без зайвої допомоги), а потім логін і пароль;
- Після збереження дані відобразяться в меню «Паролі сайтів і програм», і стануть активні для використання при авторизації. Яким чином? Елементарно! Необхідно перейти на сторінку сайту, доданого в зв'язку і звернутися до текстовій формі для входу. Далі залишається натиснути на вільне місцедля введення, і на екрані з'явиться сенсорна клавіатура, а разом з нею - спеціальний пункт, який називається «Використовувати ...». При бажанні можна звернутися безпосередньо до кнопки, що зображає ключ, якщо даних для входу - кілька, і потрібно вибрати якийсь певний варіант;
- Подібним же чином працює і оплата - дані від вже використовуваних карток прикріплюються автоматично і дозволяють здійснювати безпечні платежі в будь-який момент часу.
І ще - функція спокійно працює з усіма сторонніми додатками. Той же браузер від Google Chrome, Викликає «Зв'язку ключів» і спокійно бере необхідні дані. Подібним же чином легко авторизуватися в App Store, ITunes і в сервісах iCloud.
Питання та відповіді
Як прискорити процес введення даних?
Поставити галочку в «Налаштуваннях» в розділі «Паролі та облікові записи» навпроти пункту «Заповнити форму». Якщо система зустріне вже знайомий ресурс, то відразу ж спробує заповнити поле "логін і пароль». На смартфонах, починаючи з версії 5S, доведеться прикласти палець до сканера відбитка Touch ID, до 5S - ввести код перевірки. На iPhone X все спрацює миттєво - особа сканується автоматично.
Чи безпечна «Зв'язка ключів»?
Як підказують розробники з Apple пробитися через 256-бітове шифрування практично неможливо, адже дані для шифрування генеруються для кожного пристрою окремо, відповідно до обраних настройками і введеними паролями. Детальніше про протоколах захисту можна прочитати на.
Якщо відключити «Зв'язку ключів iCloud», що відбудеться?
Система запропонує два варіанти дій - видалити збережені дані або ж заархівувати для подальшого використання, якщо технологія знову знадобиться.
Як налаштувати автоматичне заповнення даних про банківську карту в Safari?
Порядок дій проста:
Як багато людей сьогодні довіряють комп'ютерам і смартфонам? Практично всі в них зберігають фотографії, відомості про місцезнаходження, нерідко дані і коди з кредитних карт і незліченна кількість паролів.
Останні є основним механізмом захисту в інтернеті, за ними зберігається доступ до всього того, що користувач напевно хотів би приховати, а значить, вони повинні бути просунутими і трудноподбіраемимі. Кількість таких паролів накопичується, перевалює за сотню, і ось ніхто вже не в силах згадати їх.
Для захисту і надійного зберігання всієї цієї інформації компанією Apple був придуманий інструмент під назвою Keychain ( "Зв'язка ключів").
ключів "?
За своєю суттю це менеджер паролів, розроблений компанією Apple спеціально для своєї операційної системи. Даний інструмент був представлений разом з релізом Mac OS 8-й ітерації, що вийшла в 1998 році. Після дана утиліта була частиною кожного релізу Apple, в тому числі OS X і iOS (з 2013 року іменується як "Зв'язка ключів iCloud").
Вона на Mac здатна зберігати дані різного характеру, наприклад: паролі від веб-сайтів, FTP-серверів, SSH-акаунтів, загальних мереж, бездротових мережПрихованих заміток, загального програмного забезпеченняі обладнання, а також для сертифікатів і зашифрованих образів диска.
Історія продукту
Спочатку схожий механізм використовувався в додатку PowerTalk, яке представляло собою поштовий клієнтвід Apple. Додаток було створено ще в ранніх 90-х, а Keychain допомагала контролювати всі призначені для користувача дані з різних поштових служб, до яких міг підключити PowerTalk.
У зв'язку з використанням шифрування паролі було важко запам'ятати і відновити. Тому був необхідний механізм, який дозволяв би вводити користувачеві лише один пароль (майстер-пароль), що відкриває доступ до всіх поштових послуг (у кожної з яких свої вхідні дані і паролі).
Дана ідея, незважаючи на свою очевидність і корисність, практично померла в той момент, коли в Apple вирішили припинити підтримку PowerTalk. Але з поверненням Стіва Джобса дана функція повернулася в і працювала не тільки в одній програмі, а й в системі цілком.
Сховище і доступ
В операційних системах Mac 10-го покоління і старше все Keychain-файли зберігаються в спеціальній директорії системи, також ці дані можна знайти в спеціальному додатку, яке розташоване в папці "Програми".
«Зв'язка ключів» є безкоштовне і вільне ПЗ ( вихідний кодутиліти є у вільному доступі), яке поширюється по публічної ліцензії компанії Apple.
Keychain-файл зберігає в собі масу інформації, з неї зашифрованістю є лише замітки і паролі, все інше (назви, посилання) доступно всім.
Блокування та розблокування
За замовчуванням, Keychain-файл захищений тим же паролем, що і тому функція стає доступна відразу після входу під своїм логіном і паролем. При необхідності його для цієї функції можна встановити окремо.
Також для більшої безпеки можна встановити інтервал блокування, наприклад, в 15 хвилин. У такому випадку, якщо комп'ютер не використовувався протягом 15 хвилин, при спробі скористатися "Зв'язкою ключів" він зажадає пароль.
"Зв'язка ключів
Даний продукт компанія Apple анонсувала через 15 років після появи оригінальної "Зв'язки ключів". У 2013 році на конференції WWDC разом з iOS 7 версії і OS X Mavericks була представлена технологія, що дозволяє синхронізувати всі засекречені дані користувача і надійно зберегти їх.
Дана опція є певним онлайн-сховищем, в якому знаходяться всі призначені для користувача дані, в число яких входять: паролі від веб-сторінок, паролі від бездротових мереж, інформація про облікові записи і платіжні дані кредитних карт (за винятком кодів безпеки - CVV).
Всі ці дані зашифровані за стандартом AES 256-bit і доступні лише конкретного користувача і тільки в і додатків, адаптованих для роботи з цією програмою (вони відправляють запит в Safari, браузер перевіряє відповідність посилань і пропонує додатком пароль, раніше збережений в системі).
Також в можливості сервісу входить складання довгих, складних і безпечних паролів для сайтів, на яких реєструється користувач.
"Зв'язка ключів
Почати працювати з «Зв'язкою ключів iCloud» зовсім неважко, але в першу чергу потрібно переконатися, що на гаджеті (смартфоні або планшеті) встановлена iOS 7.0.3 і новіше, а на комп'ютері - OS X 10.9 і новіше.
Налаштування «Зв'язки ключів iCloud» (інструкція для Mac):
- Для початку необхідно запустити "Налаштування" (або з меню Apple, яке криється за іконкою яблука у верхньому лівому кутку, або з Dock).
- Вибрати підміню iCloud.
- Ввести пароль для розблокування комп'ютера.
- Ввести дані Apple ID.
Як додати в «Зв'язку ключів» кредитну карту (інструкція для Mac):
- Необхідно запустити програму Safari.
- Потім зайти в налаштування цієї програми.
- В налаштуваннях вибрати підміню Autofill (автозаповнення).
- Поруч з підпунктом "Кредитні карти" знайти кнопку "Редагувати".
- Натиснути на кнопку "Додати" і ввести дані кредитної картки.
Як налаштувати «Зв'язку ключів iCloud» (інструкція для iOS):
- Вибрати підміню iCloud.
- Потім підпункт "Зв'язка ключів".
- Перемістити тумблер "Зв'язка ключів iCloud" в положення ON (Увімкн.). Відповідно для виключення потрібно провести зворотну дію, перемкнути тумблер в положення OFF (Вимк.).
- Після цього буде запропоновано придумати новий пароль або ввести існуючий (код безпеки «Зв'язки ключів iCloud» для активації), а також прикріпити сторонні гаджети для підтвердження.
- Необхідно запустити "Налаштування" з екрану "Додому".
- Вибрати підміню Safari.
- Потім підпункт Password & AutoFill (Паролі та автозаповнення).
- Ввести код-пароль.
- Вибрати підміню Saved Credit Cards (Збережені кредитні карти).
- Додати кредитну карту (ввести потрібну інформацію і натиснути "Готово").
Синхронізація паролів
Синхронізація даних в зв'язці ключів не є необхідною опцією. Більш того, синхронізувати дані можна минаючи iCloud (тільки на комп'ютерах Mac).
Щоб уникнути синхронізації даних з хмарою і їх подальшого там зберігання, під час активації "Зв'язки ключів" потрібно пропустити етап зі створенням перевірочного шестизначного коду. В цьому випадку всі дані будуть зберігатися лише на фізичному носії, локально.
Також можлива синхронізація даних за допомогою файлів, що зберігаються в / Library / Keychains /. Зазвичай подібне використовується в корпоративних мережах і при наявності декількох загальних комп'ютерів Mac. На жаль, синхронізація нерідко пропадає при зміні пароля в системі на одному з пристроїв (в тому числі Windows).
Доступ до "зв'язка ключів"
Перед тим як отримати всю інформацію, що зберігається в хмарі, слід підтвердити «Зв'язку ключів iCloud». Це можна робити за допомогою SMS або другого пристрою.
У першому випадку користувач отримає випадково згенерований код-пароль для підтвердження особи або повноцінної активації функції "Зв'язка ключів iCloud". Підтвердити за допомогою іншого пристрою можна в тому випадку, якщо у користувача є гаджет, на якому вже працює дана функція.
код безпеки
Це спеціальний шифр, який складається з 6 цифр, або з ускладненою буквено-числовий комбінації, який необхідний для того, щоб отримати доступ до паролів і картам, що зберігаються в "зв'язці ключів", а також в разі втрати доступу до неї.
Можливі проблеми
Ніщо не ідеально, навіть «Зв'язка ключів iCloud». Ні, мова йде не про дірки в безпеці або втраті даних, але існує чимало проблем, пов'язаних з підключенням даної функції і поверненням доступу після поновлення, скидання і налаштування нового пристрою. Список найпоширеніших питань і проблем представлений нижче.
«Зв'язку ключів iCloud» не вдалося налаштувати в зв'язку з відсутністю СМС-коду? Якщо з якоїсь причини СМС-повідомлення з кодом-паролем не спадає, необхідно:
- Перевірити з'єднання з мережею.
- Переконатися в тому, що телефон здатний отримувати СМС ( тарифний плані встановлена СІМ-карта підтримують цю можливість).
- Перевірити, чи той номер вказаний для отримання СМС-коду. Для цього в настройках "Зв'язки ключів" знайти підпункт "Додатково" і вказати вірний номер в пункті "Номер для перевірки".
«Зв'язка ключів iCloud" не синхронізує дані між пристроями. В цьому випадку майже завжди допомагає повне відключення і включення функції. Зробити це необхідно на всіх пристроях. Після повторного включення все вони отримають найбільш актуальні дані з сервера і продовжать працювати в звичайному режимі.
Не виходить знайти паролі, збережені в «Зв'язку ключів iCloud»? Дані про них і кредитних картах, збережених в хмарі, можна знайти в такий спосіб:
- Перейти в "Налаштування" з екрану "Додому".
- Вибрати підміню Safari.
- Потім підпункт Passwords (Паролі).
- Система зажадає ввести пароль або скористатися Touch ID (дактилоскопічний сенсором) для підтвердження особи.
- Після перевірки можна вибрати будь-який сайт і подивитися пароль до нього.
Safari не зберігаються дані в «Зв'язку ключів» і не пропонує підстановку паролів. Дану проблему можна вирішити, активувавши тумблер "Імена і паролі" в підміню "Заповнити форму" в налаштуваннях Safari.
Підтримувані пристрої
«Зв'язка ключів iCloud» підтримується на всіх актуальних пристроях Apple. В їх число входять всі комп'ютери, які працюють на базі операційної системи macOSпокоління Mavericks і новіше (майже всі ПК 2007 року випуску і більш сучасні).
Також дана функція працює на ряді мобільних пристроїв(Всіх, на які можна встановити мобільну операційну системуверсії 7.0.3). В їх число входять: iPhone з 4-го покоління і більш сучасні, iPad з 2-го покоління і більш сучасні, з 5-го покоління і більш сучасні.
Безпечне зберігання паролів і їх синхронізація між пристроями - завдання непросте. Близько року тому Apple представила світу iCloud Keychain, своє централізованого сховища паролів в OS X і iOS. Давай спробуємо розібратися, де і як зберігаються паролі користувачів, які потенційні ризики це несе і чи має Apple технічнуможливість отримати доступ до розшифрованих даних, що зберігаються на її серверах. Компанія стверджує, що такий доступ неможливий, але, щоб це підтвердити або спростувати, необхідно розібратися, як працює iCloud Keychain.
iCloud 101
Насправді iCloud - це не один сервіс, це загальне маркетингове назву для цілого ряду хмарних сервісів від Apple. Це і синхронізація налаштувань, документів і фотографій, і Find My Phone для пошуку втрачених або викрадених пристроїв, і iCloud Backup для резервного копіюванняв хмару, і тепер ось iCloud Keychain для безпечної синхронізації паролів і номерів кредитних карт між пристроями на базі iOS і OS X.
Кожна служба iCloud розташована на власному домені третього рівня, такому як pXX-keyvalueservice.icloud.com, де XX - номер групи серверів, що відповідають за обробку запитів поточного користувача; для різних Apple ID цей номер може бути різним; більш нові облікові записи зазвичай мають більше значення цього лічильника.
Код безпеки iCloud
Перш ніж занурюватися в аналіз iCloud Keychain, звернемо увагу на те, яким чином ця служба конфигурируется. При включенні iCloud Keychain користувачеві пропонується придумати і ввести код безпеки iCloud (iCloud Security Code, далі - iCSC). За замовчуванням форма введення дозволяє використовувати чотиризначний цифровий код, але, перейшовши за посиланням « Додаткові параметри», Все ж можна використовувати більш складний код або зовсім дозволити змогу генерувати стійкий випадковий код.
Тепер ми знаємо, що дані в iCloud Keychain захищені за допомогою iCSC. Ну що ж, спробуємо розібратися, як саме цей захист реалізована!
Перехоплення трафіку або man-in-the-middle
Першим кроком при аналізі мережевих сервісів часто є отримання доступу до мережевого трафіку між клієнтом і сервером. У випадку з iCloud для нас є дві новини: погана і хороша. Погана полягає в тому, що весь (ну або принаймні переважна його частина) трафік захищений TLS / SSL, тобто він зашифрований і звичайної пасивної атакою «прочитати» його не вдасться. Хороша ж новина полягає в тому, що Apple зробила всім бажаючим поісследовать iCloud подарунок і не використовує фіксацію сертифіката (certificate pinning), що дозволяє досить просто організувати атаку «людина посередині» (man-in-the-middle) і розшифровувати перехоплений трафік. Для цього достатньо:
- Помістити піддослідна iOS-пристрій в одну Wi-Fi-мережу з комп'ютером, що здійснює перехоплення.
- Встановити на комп'ютері перехоплює проксі-сервер (такий як Burp, Charles Proxy або будь-який аналогічний).
- Імпортувати на iOS-пристрій TLS / SSL-сертифікат встановленого проксі-сервера (подробиці в довідці конкретного проксі).
- В налаштуваннях Wi-Fi-мережі на iOS-пристрої (Настройки → Wi-Fi → Ім'я мережі → HTTP Проксі) вказати IP-адресу перехоплює комп'ютера в Wi-Fi-мережі і порт, на якому слухає проксі-сервер.
Якщо все зроблено правильно, то весь трафік між пристроєм і iCloud'ом буде як на долоні. І з перехоплення цього трафіку буде чітко видно, що iCloud Keychain побудований на базі двох сервісів iCloud: com.apple.Dataclass.KeyValue і com.apple.Dataclass.KeychainSync - і при первинному, і при повторному включених на інших пристроях iOSобмінюється даними з цими сервісами.
Перший сервіс не новий і був в числі перших можливостей iCloud; він широко використовується додатками для синхронізації налаштувань. Другий же є новим і розроблений, очевидно, спеціально для iCloud Keychain (хоча його функціонал теоретично дозволяє використовувати його і для інших цілей). Розглянемо ці сервіси докладніше.
com.apple.Dataclass.KeyValue
Як було зазначено вище, це один з сервісів, які використовуються iCloud Keychain. Багато існуючі програми використовують його для синхронізації невеликих обсягів даних (настройки, закладки тощо). Кожна зберігається цією службою запис асоціюється з ідентифікатором додатки (Bundle ID) і ім'ям сховища (store). Відповідно, для отримання збережених даних від сервісу також необхідно надати ці ідентифікатори. В рамках iCloud Keychain даний сервіс використовується для синхронізації записів Keychain в зашифрованому вигляді. Досить докладно цей процес описаний в документі iOS Security в розділах Keychain syncing і How keychain syncing works.
Синхронізація Keychain
Коли користувач вперше включає iCloud Keychain, пристрій створює «коло довіри» (circle of trust) і ключі синхронізації (syncing identity, складається з відкритого і закритого ключів) для поточного пристрою. Відкритий ключ цієї пари поміщається в «коло довіри», і цей «коло» двічі підписується: спершу закритим ключем синхронізації пристрою, а потім асиметричним ключем (заснованим на еліптичній криптографії), отриманим з пароля користувача на iCloud. Також в «колі» зберігаються параметри для обчислення ключа з пароля, такі як сіль і кількість ітерацій.
Підписаний «коло» зберігається в Key / Value-сховище. Він не може бути прочитаний без знання пароля користувача iCloud і не може бути змінений без знання закритого ключа одного з пристроїв, доданих в «коло».
Коли користувач включає iCloud Keychain на іншому пристрої, цей пристрій звертається до Key / Value-сховища в iCloud і зауважує, що у користувача вже є «коло довіри» і що новий пристрій в нього не входить. Пристрій генерує ключі синхронізації і квитанцію для запиту членства в «колі». Квитанція містить відкритий ключ синхронізації пристрою і підписана ключем, отриманим з пароля користувача iCloud з використанням параметрів генерації ключа, отриманих з Key / Value-сховища. Підписана квитанція потім поміщається в Key / Value-сховище.
Перший пристрій бачить нову квитанцію і показує користувачеві повідомлення про те, що новий пристрій запитує додавання в «коло довіри». Користувач вводить пароль iCloud, і підпис квитанції перевіряється на коректність. Це доводить, що користувач, генерувати запит на додавання пристрою, ввів вірний пароль при створенні квитанції.
Після того як користувач підтвердить додавання пристрою до «колу», перший пристрій додає відкритий ключ синхронізації нового пристрою в «коло» і знову двічі підписує його за допомогою свого закритого ключа синхронізації і за допомогою ключа, отриманого з пароля iCloud-користувача. Новий «коло» зберігається в iCloud, і новий пристрій аналогічним чином підписує його.
Як працює синхронізація Keychain
Тепер в «колі довіри» два пристрої, і кожне з них знає відкриті ключі синхронізації інших пристроїв. Вони починають обмінюватися записами Keychain через Key / Value-сховище iCloud. У разі якщо одна і та ж запис присутній на обох пристроях, то пріоритет буде відданий має більш пізній час модифікації. Якщо час модифікації записи в iCloud і на пристрої збігаються, то запису не синхронізується. Кожна синхронізуються запис зашифрована спеціально для цільового пристрою; вона не може бути розшифрована іншими пристроями або Apple. Крім того, запис не зберігається в iCloud постійно - вона перезаписується новими синхронізуються записами.
Цей процес повторюється для кожного нового пристрою, який додається в «коло довіри». Наприклад, якщо до «колу» додається третій пристрій, то запит підтвердження буде показаний на двох інших пристроях. Користувач може підтвердити додавання на будь-якому з них. У міру додавання нових пристроїв кожен пристрій з «кола» синхронізується з новими, щоб переконатися, що набір записів на всіх пристроях однаковий.
Необхідно зауважити, що синхронізується не весь Keychain. Деякі записи прив'язані до пристрою (наприклад, облікові записи VPN) і не повинні залишати пристрій. Синхронізуються тільки записи, що мають атрибут kSecAttrSynchronizable. Apple встановила цей атрибут для призначених для користувача даних Safari (включаючи імена користувачів, паролі та номери кредитних карт) і для паролів Wi-Fi.
Крім того, за замовчуванням записи сторонніх додатків теж не синхронізовані. Для їх синхронізації розробники повинні явним чином встановити атрибут kSecAttrSynchronizable при додаванні запису в Keychain.
iCloud Keychain оперує двома сховищами:
- com.apple.security.cloudkeychainproxy3
- com.apple.sbd3
Перше сховище імовірно використовується для підтримки списку довірених пристроїв (пристроїв в «колі довіри», між якими дозволена синхронізація паролів), для додавання нових пристроїв в цей список і для синхронізації записів між пристроями (відповідно до механізму, описаним вище).
Друге ж сховище призначене для резервного копіювання та відновлення записів Keychain на нові пристрої (наприклад, коли в «колі довіри» немає інших пристроїв) і містить зашифровані записи Keychain і супутню інформацію.
Таким чином, записи Keychain зберігаються в звичайному Key / Value-сховище (com.apple.securebackup.record). Ці записи зашифровані за допомогою набору ключів, що зберігається там же (BackupKeybag). Але цей набір ключів захищений паролем. Звідки береться цей пароль? Що це за служба депонування паролів Apple? Далі постараємося розібратися.
apple.Dataclass.KeychainSync
Це новий сервіс, виник він відносно недавно: вперше його підтримка з'явилася в бета-версіях iOS 7, потім вона була відсутня в iOS 7.0-7.0.2 і була знову додана в iOS 7.0.3, що вийшла одночасно з релізом OS X Mavericks. Це і є згадана вище служба депонування паролів (адреса служби - pXX-escrowproxy.icloud.com).
Служба призначена для безпечного зберігання призначених для користувача секретів і дозволяє користувачеві після успішної аутентифікації відновити ці секрети. Для успішної аутентифікації необхідно наступне:
- токен аутентифікації iCloud, що отримується в обмін на Apple ID і пароль при первинній аутентифікації в iCloud ( стандартний спосібаутентифікації для більшості сервісів iCloud);
- код безпеки iCloud (iCSC);
- шестизначний цифровий код, який передається серверами Apple на номер стільникового телефону, Асоційований з користувачем.
В теорії все виглядає добре, але, щоб визначити, чи збігається теорія з практикою, нам буде потрібно провести аудит програми-клієнта служби депонування. В ОС iOS і OS X ця програма носить назву com.apple.lakitu. Опис процесу її реверсінга і аудиту виходить за рамки статті, тому відразу переходимо до результатів.
доступні команди
Аудит com.apple.lakitu дозволяє визначити список команд, що реалізуються службою депонування. На відповідному скріншоті представлені команди і їх опис. Особливо хотілося б зупинитися на останній команді - з її допомогою можливо змінити номер телефону, асоційований з поточної обліковим записом. Наявність цієї команди робить многофакторную аутентифікацію, яка використовується при відновленні iCloud Keychain (пароль Apple ID + iCSC + пристрій), помітно менш надійною, тому що дозволяє виключити один з чинників. Цікаво й те, що призначений для користувача інтерфейс iOS не дозволяє виконати цю команду - в ньому просто немає такої опції (принаймні я її не знайшов).
Особливість даної команди, що відрізняє її від всіх інших, в тому, що вона вимагає аутентифікації з паролем Apple ID і не буде працювати, якщо для аутентифікації використовується токен iCloud (інші команди працюють при аутентифікації по токені). Це служить додатковим захистом даної команди і показує, що проектувальники системи зробили кроки для підвищення її безпеки. Проте не до кінця ясно, навіщо ця команда взагалі присутня в системі.
Відновлення депонованих даних
Для отримання депонованих даних виконується наступний протокол:
- Клієнт запитує список депонованих записів (/ get_records).
- Клієнт запитує асоційований телефонний номер, на який сервером буде направлений код підтвердження (/ get_sms_targets).
- Клієнт ініціює генерацію і доставку коду підтвердження (/ generate_sms_challenge).
- Після того як користувач ввів iCSC і код підтвердження з SMS, клієнт ініціює спробу аутентифікації з використанням протоколу SRP-6a (/ srp_init).
- Після отримання відповіді від сервера клієнт робить обчислення, запропоновані протоколом SRP-6a, і запитує депоновані дані (/ recover).
- У разі якщо клієнт успішно аутентифицироваться, сервер повертає депоновані дані, попередньо зашифрувавши їх на ключі, виробленому в процесі роботи протоколу SRP-6a (якщо протокол відпрацював успішно, то і сервер, і клієнт вирахували цей загальний ключ).
Важливо відзначити, що номер телефону, отриманий на кроці 2, використовується виключно для потреб користувальницького інтерфейсу, тобто щоб показати користувачеві номер, на який буде відправлений код підтвердження, і на кроці 3 покупець не передає серверу номер, на який слід відправляти код підтвердження.
Secure Remote Password
На кроці 4 клієнт починає виконання протоколу SRP-6a. Протокол SRP (Secure Remote Password) - це протокол парольної аутентифікації, захищений від прослуховування і man-in-the-middle атак. Таким чином, наприклад, при використанні цього протоколу неможливо перехопити хеш пароля і потім намагатися відновити його, просто тому, що ніякої хеш не передається.
Apple використовує найбільш досконалий варіант протоколу, SRP-6a. Цей варіант наказує розривати з'єднання при невдалій аутентифікації. Крім того, Apple дозволяє лише десять невдалих спроб аутентифікації для даного сервісу, після чого всі наступні спроби блокуються.
Детальний опис протоколу SRP і його математичних основ виходить за рамки статті, але для повноти викладу нижче представлений окремий випадок, який використовується службою com.apple.Dataclass.KeychainSync.
Як хеш-функції H використовується SHA-256, а в якості групи (N, g) - 2048-бітна група з RFC 5054 «Using the Secure Remote Password (SRP) Protocol for TLS Authentication». Протокол виконується наступним чином:
- Пристрій генерує випадкове значення a, обчислює A = g ^ a mod N, де N і g - параметри 2048-бітної групи з RFC 5054, і відправляє на сервер повідомлення, що містить ідентифікатор користувача ID, обчислене значення A і код підтвердження з SMS. В якості ідентифікатора користувача використовується значення DsID - унікальний числовий ідентифікатор користувача.
- Отримавши повідомлення, сервер генерує випадкове значення b і обчислює B = k * v + g ^ b mod N, де k - множник, визначений в SRP-6a як k = H (N, g), v = g ^ H (Salt, iCSC) mod N - верифікатор пароля, що зберігається на сервері (аналог хешу пароля), Salt - випадкова сіль, згенерувала при створенні облікового запису. Сервер відправляє клієнту повідомлення, що містить B і Salt.
- Шляхом нескладних математичних перетворень клієнт і сервер обчислюють загальний сесійний ключ K. На цьому перша частина протоколу - вироблення ключа - завершена, і тепер клієнт і сервер повинні переконатися, що вони отримали одне і те ж значення K.
- Клієнт обчислює M = H (H (N) XOR H (g) | H (ID) | Salt | A | B | K), доказ того, що він знає K, і відправляє на сервер M і код підтвердження з SMS. Сервер також обчислює M і порівнює отримане від клієнта і обчислене значення; якщо вони не збігаються, то сервер припиняє виконання протоколу і розриває з'єднання.
- Сервер доводить клієнту знання K шляхом обчислення і відправки H (A, M, K). Тепер обидва учасники протоколу не тільки виробили загальний ключ, але і переконалися, що цей ключ однаковий у обох учасників. У випадку зі службою депонування сервер також повертає випадковий вектор ініціалізації IV і депонированную запис, зашифровану на загальному ключі K з використанням алгоритму AES в режимі CBC.
Використання SRP для додаткового захисту призначених для користувача даних, на мій погляд, істотно покращує безпеку системи від зовнішніх атак хоча б тому, що дозволяє ефективно протистояти спробам перебору iCSC: за одне підключення до сервісу можна спробувати тільки один пароль. Після кількох невдалих спроб обліковий запис (в рамках роботи зі службою депонування) переводиться в стан soft lock і тимчасово блокується, а після десяти невдалих спроб обліковий запис блокується остаточно і подальша робота зі службою депонування можлива тільки після скидання iCSC для облікового запису.
У той же час використання SRP ніяк не захищає від внутрішніх загроз. Депонований пароль зберігається на серверах Apple, відповідно, можна припустити, що Apple може при необхідності отримати до нього доступ. У такому випадку, якщо Ви не був захищений (наприклад, зашифрований) до депонування, це може привести до повної компрометації записів Keychain, збережених в iCloud, так як депонований пароль дозволить розшифрувати ключі шифрування, а вони - записи Keychain (зверни увагу на com. apple.Dataclass.KeyValue).
Однак в документі «iOS Security» Apple стверджує, що для зберігання депонованих записів використовуються спеціалізовані апаратні модулі безпеки (Hardware Security Module, HSM) і що доступ до депонованих даними неможливий.
Безпека депонування
iCloud надає захищену інфраструктуру для депонування Keychain, що забезпечує відновлення Keychain тільки авторизованими користувачами і пристроями. Кластери HSM захищають депоновані записи. Кожен кластер має власний ключ шифрування, що використовується для захисту записів.
Для відновлення Keychain користувач повинен аутентифицироваться, використовуючи ім'я користувача та пароль iCloud, і відповісти на надіслане SMS. Коли це виконано, користувач повинен ввести код безпеки iCloud (iCSC). Кластер HSM перевіряє коректність iCSC, використовуючи протокол SRP; при цьому iCSC не передається на сервери Apple. Кожен вузол кластера, незалежно від інших, перевіряє, чи не перевищив користувач максимально допустиму кількість спроб отримання даних. Якщо на більшій частині вузлів перевірка завершується успішно, то кластер розшифровує депонированную запис і повертає її користувачеві.
Далі пристрій використовує iCSC, щоб розшифрувати депонированную запис і отримати пароль, використаний для шифрування записів Keychain. За допомогою цього пароля Keychain, отримана з Key / Value-сховища, розшифровується і відновлюється на пристрій. Допускається лише десять спроб аутентифікації і отримання депонованих даних. Після кількох невдалих спроб запис блокується, і користувач повинен звернутися в службу підтримки для розблокування. Після десятої невдалої спроби кластер HSM знищує депонированную запис. Це забезпечує захист від брутфорс-атак, спрямованих на отримання запису.
На жаль, перевірити, чи використовуються HSM насправді, не представляється можливим. Якщо все дійсно так і HSM не дозволяють прочитати зберігаються в них дані, то можна стверджувати, що дані iCloud Keychain захищені і від внутрішніх загроз. Але, повторюся, на жаль, довести або спростувати використання HSM і неможливість читання даних з них не можна.
Залишається ще один спосіб захисту даних від внутрішньої загрози - захист депонуються даних на пристрої перед передачею на сервери Apple. з опису Appleслід (і реверсінг це підтверджує), що такий захист застосовується - депонований пароль попередньо зашифрована за допомогою iCSC. Очевидно, що в цьому випадку рівень безпеки (від внутрішньої загрози) безпосередньо залежить від складності iCSC і четирехсімвольний iCSC, який використовується за замовчуванням, не забезпечує достатнього захисту.
Отже, ми з'ясували, як працюють окремі елементи системи, і тепер саме час подивитися на систему цілком.
Putting it all Together
На схемі представлена робота iCloud Keychain в частині депонування і відновлення записів Keychain. Система працює наступним чином:
- Пристрій генерує набір випадкових ключів (в термінології Apple - keybag) для шифрування записів Keychain.
- Пристрій зашифровує записи Keychain (мають встановлений атрибут kSecAttrSynchronizable) за допомогою набору ключів, згенерованого на попередньому кроці, і зберігає зашифровані записи в Key / Value-сховище com.apple.sbd3 (ключ com.apple.securebackup.record).
- Пристрій генерує випадковий пароль, що складається з шести груп по чотири символи (ентропія такого пароля - близько 124 біт), зашифровує набір ключів, згенерований на кроці 1, за допомогою цього пароля і зберігає зашифрований набір ключів в Key / Value-сховище com.apple. sbd3 (ключ BackupKeybag).
- Пристрій зашифровує випадковий пароль, згенерований на попередньому кроці, за допомогою ключа, отриманого з коду безпеки iCloud користувача, і депонує зашифрований пароль службі com.apple.Dataclass.KeychainSync.
Під час налаштування iCloud Keychain користувач може застосовувати складний або випадковий iCSC замість пропонованого за замовчуванням чотиризначного коду. У разі використання складного коду механізм роботи системи депонування не змінюється; відмінність лише в тому, що ключ для шифрування випадкового пароля буде вирахувано не з чотиризначного iCSC, а з більш складного, введеного користувачем.
При випадковому коді підсистема депонування пароля не використовується взагалі. При цьому випадковий пароль, згенерований системою, і є iCSC, і завдання користувача його запам'ятати і безпечно зберігати. Записи Keychain все так же зашифровуються і зберігаються в Key / Value-сховище com.apple.sbd3, але служба com.apple.Dataclass.KeychainSync не використовується.
висновки
Можна сміливо стверджувати, що з технічної точки зору (тобто social engineering не розглядаємо) і по відношенню до зовнішніх загроз (тобто не Apple) безпеку служби депонування iCloud Keychain знаходиться на достатньому рівні: завдяки використанню протоколу SRP навіть при компрометації пароля iCloud зловмисник не зможе отримати доступ до записів Keychain, так як для цього додатково знадобиться код безпеки iCloud, а перебір цього коду надзвичайно ускладнений.
У той же час, використовуючи інший механізм iCloud Keychain - синхронізацію паролів, зловмисник, скомпрометував пароль iCloud і має нетривалий фізичний доступ до одного з пристроїв користувача, може повністю скомпрометувати і iCloud Keychain: для цього досить додати пристрій зловмисника в «коло довіри» пристроїв користувача , а для цього достатньо знати пароль iCloud і мати короткочасний доступ до пристрою користувача, щоб підтвердити запит на додавання нового пристрою до «колу».
Якщо ж розглядати захист від внутрішніх загроз (тобто Apple або хто-небудь з доступом до серверів Apple), то в цьому випадку безпеку служби депонування виглядає не так райдужно. Твердження Apple про використання HSM і неможливості читання даних з них не мають беззаперечних доказів, а криптографічний захистдепонуються даних зав'язана на код безпеки iCloud, при настройках за умовчанням є вкрай слабкою і дозволяє будь-кому, хто в змозі отримати з серверів (або з HSM) Apple депоновані записи, практично моментально відновити чотиризначний код безпеки iCloud.
У разі використання складного алфавітно-цифрового коду ця атака стає складніше, так як зростає кількість можливих паролів. Якщо ж iCloud Keychain налаштований використовувати випадковий код, то служба депонування взагалі не залучається, що фактично робить цей вектор атаки неможливим.
Максимальний рівень безпеки (не рахуючи повного відключення iCloud Keychain, звичайно) забезпечується при використанні випадкового коду - і не стільки тому, що такий код складніше підібрати, скільки тому, що при цьому не задіяна підсистема депонування паролів, а отже, зменшується і attack surface. Але зручність цього варіанту, звичайно, залишає бажати кращого.
Всім привіт, шановні читачі. Сьогодні я розповім вам що таке горезвісна зв'язка ключів iCloud, як її активувати і як користуватися. Для початку дам визначення, що таке зв'язка ключів iCloud.
Зв'язка ключів в iCloud - хмарний сервісвід компанії Apple, який називається iCloud Keychain. Служить для зберігання особистих даних користувачів в зашифрованому вигляді. Особистими даними можуть вважатися логіни і паролі, а також коди безпеки від кредитних карт + сертифікати, які ви використовуєте в сервісах Apple.
Цілком закономірно виникає питання - наскільки безпечно для збереження даних використовувати даний сервіс. Як стверджує компанія, всі дані зберігається в зашифрованому вигляді і отримати до них доступ може тільки власник даних, співробітники компанії Apple не мають доступу до ваших даних.
Активувати цей режим ви можете безпосередньо з вашого Apple пристрої, наприклад iPad або iPhone. Я буду показувати на прикладі iPad, але різниці між активацією режиму на iPhone або iPad - немає.
Активація
Дотримуйтесь кроків описаним нижче для того щоб успішно активувати необхідний сервіс:
В подальшому ви зможете синхронізувати інформацію з даної служби з іншими пристроями: як на базі операційної системи iOS, а також Mac OS.
Налаштування
Тепер давайте налаштує автоматичне збереження важливих даних в сервісі iCloud Keychain введених в браузері Safari:
- Насамперед вам потрібно перейти в налаштування пристрою і вибрати розділ Safari, а далі перейти в пункт - паролі;
- У відкритому полі вам потрібно поставити галочку в розділі "Імена і паролі".
Після виконання вищеописаної операції, все вами паролі, логіни та інші дані вводяться в браузері Safari будуть зберігатися, за Вашим запитом, в хмарний сервіс iCloud Keychain.
Деякі поради по роботі з даної описуваної функцією:
- Якщо не вдається налаштувати або активувати зв'язки, вам потрібно оновити операційну систему до актуальної версії, а також перевірити підключення до інтернету;
- Ви можете переглядати всі збережені паролі, для цього вам потрібно: перейти в настройки, далі в розділ Safari, Паролі, збережені паролі;
- Дана служба може не виконувати збереження паролів на деяких веб-сайтів, тому що такі сайти, з метою безпеки, забороняють зберігати будь-які дані;
- Рекомендую вам використовувати цей інструмент - зв'язка ключів - тільки на мобільному Apple пристрої без джейлбрейка. Оскільки використання даної функції з джейлбрейком може бути небезпечно.