Відео: БАГ НА НЕВИДИМОСТЬ В ГРЭННИ! - Granny (Листопад 2024)
Ви вже чули, що компанія Apple оголосила про програму Black Hat на останній програмі. У незвичній зовнішності сам Іван Крстич, керівник служби безпеки та архітектури Apple, зробив це оголошення сам. Але це були лише останні 10 хвилин 50-хвилинної презентації. Протягом перших 40 хвилин Krstic здійснив безпрецедентне глибоке занурення у три компоненти безпеки iOS. І під глибоким, я маю на увазі батисферичний.
У моєму загальному заході було побоювання того, наскільки ретельно ці системи захищають дані користувачів, навіть від самого Apple. Я спробую передати сказане, не надто надто технічно.
Затверджене картографування JIT WebKit
Вибачте, це так називається. JIT означає Just In Time і посилається на те, як Javascript-код складений саме вчасно для його виконання. "Це необхідно для високопродуктивного JavaScript", - пояснив Крстік. "Але політика підписання коду повинна бути розслабленою. Компілятор JIT випускає новий, непідписаний код. Зловмисник, який керував атакою запису будь-де, може дозволити виконання довільного коду."
Для невеликого тла області пам’яті можна позначити дозволами для читання, запису та виконання. Ця відмінність, запроваджена століттями тому, приглушила атаки, які виконували код у областях, присвячених даним. Якщо коротко, рішення Apple включає в себе техніку, що забезпечує складений JavaScript в області пам’яті, що дозволяє лише виконувати. Процеси не можуть читати, що там, або записувати нові дані. Існує трохи більше, ніж це, але ця зміна, характерна для iOS 10, знищує цілу низку можливих атак.
Безпечний процесор анклаву
Програми на пристрої Apple запускаються в центральному процесорі, який називається Process Processor, або AP. Сучасні пристрої Apple мають цілком окремий процесор під назвою процесор захищеного анклаву або SEP. "SEP захищений сильним криптографічним головним ключем від пароля користувача", - сказав Крістік. "Офлайн-атака неможлива. Вона уникає поверхні атаки AP, навіть коли AP є компрометованим. Він арбітрує весь доступ користувача та управляє власною зашифрованою пам'яттю. При першій ініціалізації він використовує справжній генератор випадкових чисел для створення унікального ключ пристрою в процесорі. Це не експортується, і він зберігається в незмінному захищеному ПЗУ. "
Krstic продовжив пояснювати, як пристрій використовує чотири типи внутрішніх ключів безпеки з різними характеристиками. Тип A існує лише тоді, коли пристрій розблоковано. Тип B - це завжди присутній відкритий ключ, а також приватний ключ, який існує під час розблокування пристрою. Тип C з'являється вперше, коли пристрій розблокується після завантаження. А тип D завжди доступний.
Презентація перейшла до низки серйозно складних діаграм. Один пройшов процес завантаження та розблокування пристрою, показавши, як створювався та зберігався кожен тип ключа. Кожен файл на вашому пристрої має свій унікальний ключ шифрування; ще одна діаграма показала складний танець, який дозволяє SEP аутентифікувати та розшифрувати цей файл, зберігаючи основні ключі безпеки всередині себе. Інший пояснив складний процес, завдяки якому ви можете вибрати "Оновити пізніше". І ще один пройшов процес, який дозволяє розблокувати за допомогою ідентифікатора touch, не зберігаючи головний ключ видимим.
Основний висновок цієї частини розмови полягає в тому, що Apple по-справжньому продумав те, що потрібно для повного управління шифруванням всередині процесора захищеного енклаву, не змушуючи користувача взагалі створювати багато проблем. Якщо ви хочете побачити ці схеми для себе, перегляньте повну презентацію Krstic.
Синхронізація секретів
Надзвичайно зручно, що ви можете синхронізувати свої дані між кількома пристроями Apple. HomeKit дозволяє керувати пристроями IoT, AutoUnlock дозволяє розблокувати ваш Mac, коли ваш Apple Watch знаходиться поруч, ваші фотографії синхронізуються через iCloud тощо. Але безпека синхронізації є проблемою.
"Традиційні підходи не є гарними", - сказав Крістіч. "Один із способів - зробити так, щоб користувач вводив на всіх пристроях сильний" ключ висувного шкарпетки "; втрачав його, а доступ до секретів втрачається. Інший спосіб - загортати дані у похідний ключ, який залишає дані, які піддаються впливу постачальник рахунків. "
"У нас тут був ряд цілей", - продовжив Крістік. "Секрети повинні бути доступними для всіх пристроїв, захищених сильною криптовалютою. Користувачі можуть відновлювати секрети, навіть якщо вони втрачають усі підключені пристрої. Дані Apple не піддається впливу, і немає можливості нападу грубої сили".
Аутентифікація в базовій системі iCloud Keychain проста. У кожного пристрою є своя клавішна пара, і для того, щоб додати новий пристрій до кола синхронізації, потрібно затвердити його з одного із наявних пристроїв. Apple не бере участь; вона не має привілеїв. Якщо користувач втрачає доступ до всіх пристроїв, його можна відновити за допомогою ключа безпеки iCloud та пароля iCloud.
Krstic дуже докладно пояснив, як Apple керує цією системою, не залишаючи відкритою ні найменшої можливості, що кожен, включаючи когось із Apple, може отримати доступ до даних із зворотного боку. Система включає в себе так звані картки адміністрування, створені під час введення в експлуатацію нового парку криптовалют. "Картки адміністраторів створюються під час безпечної церемонії, коли флот введений в експлуатацію, і зберігаються в окремих фізичних сейфах під вартою трьох різних організацій в Apple, у захисних пакетах, захищених від несанкціонованих дій", - сказав Крістік.
Така ситуація триває лише до того, як флот фактично буде введений в експлуатацію. У той час, сказав Крістік, "Ми ставимо картки адміністратора за допомогою нової однобічної хеш-функції". Витягнувши чітко використаний блендер з-під подіуму, він продовжив: "Так, поїздка через блендер". Після того, як флот криптосерверів активний, він не може бути оновлений чи змінений жодним чином, навіть Apple, оскільки адміністраторські картки були знищені. Якщо трапляється, що оновлення дійсно потрібно, Apple повинна створити новий флот і надіслати оновлення програмного забезпечення, яке змушує пристрої користувачів підключатися до нового флоту.
"Чому ми це робимо", - сказав Крістік. "Чому ми робимо цей останній крок, який є надзвичайно незвичним? Ми намагаємося розробити системи безпеки для забезпечення довіри. Коли дані залишають пристрій, ставки ще більше. Нам потрібно підтримувати цю довіру. Якщо ми будемо володіти ці адміністраторські картки, є ймовірність, що це неправда. Ось наскільки ми серйозно ставимося до нашої місії щодо даних користувачів ".
На запитання "Ти це зробив через запити ФБР на інформацію?" Крістік відповів: "Я інженер. Я можу відповідати лише на питання, чому я сьогодні представився". Гаразд, досить справедливо. Але я вважаю, що запитувач мав рацію. Створення автономної системи, яку ви навіть не можете змінити - це досить хороший спосіб уберегти когось іншого від небажаних змін.
Я сподіваюся, що я переказав рівень деталізації в розмові Крістіка, не змушуючи ваших очей засклитись. Судячи з балаканини, коли група розійшлася, справжні вибухи рівня безпеки в кімнаті були дуже вражені.
