Віддалене надання ключів від Google буде обов’язковим в Android 13: що це означає для вас

Ключова атестація Android є основою багатьох надійних служб на наших смартфонах, зокрема SafetyNet, Digital Car Key та API ідентифікаційних даних. Він став частиною Android з Android 8 Oreo і покладався на кореневий ключ, встановлений на пристрої на заводі. Надання цих ключів вимагало максимальної секретності з боку виробника, і якщо ключ стався витік, це означало б, що ключ потрібно буде відкликати. Це призведе до того, що споживач не зможе скористатися будь-якою з цих надійних служб, що було б прикро, якщо колись виникне вразливе місце, яке може виявити його. Remote Key Provisioning, який буде введено обов’язково Android 13, має на меті вирішити цю проблему.

Компоненти, що складають поточний ланцюжок довіри на Android

Перш ніж пояснювати, як працює нова система, важливо надати контекст того, як старий (і все ще на місці для багатьох пристроїв) система працює. Багато телефонів сьогодні використовують апаратну атестацію ключа, яку ви можете знати як цвях у труну для будь-якого обходу SafetyNet. Є кілька понять, які важливо зрозуміти для поточного стану атестації ключів.

Саме поєднання цих концепцій гарантує, що розробник може бути впевненим у тому, що пристрій не було підроблено, і може обробляти конфіденційну інформацію в TEE.

Надійне середовище виконання

Довірене середовище виконання (TEE) — це безпечна область на SoC, яка використовується для обробки критичних даних. TEE є обов’язковим на пристроях з Android 8 Oreo і новіших версій, тобто будь-який останній смартфон має його. Все, що не входить до TEE, вважається "ненадійним" і може переглядати лише зашифрований вміст. Наприклад, вміст, захищений DRM, шифрується за допомогою ключів, до яких може отримати доступ лише програмне забезпечення, що працює на TEE. Головний процесор може бачити лише потік зашифрованого вмісту, тоді як вміст може бути розшифрований TEE і потім відображений користувачеві.

ARM Trustzone

Trusty — безпечна операційна система, яка забезпечує TEE на Android, а на системах ARM використовує Trustzone ARM. Trusty виконується на тому ж процесорі, що й основна операційна система, і має доступ до повної потужності пристрою, але повністю ізольований від решти телефону. Trusty складається з наступного:

• Невелике ядро ​​ОС, похідне від Маленьке ядро
• Драйвер ядра Linux для передачі даних між безпечним середовищем і Android
• Бібліотека простору користувача Android для зв’язку з довіреними програмами (тобто безпечними завданнями/службами) через драйвер ядра

Перевага, яку вона має перед пропрієтарними системами TEE, полягає в тому, що ці системи TEE можуть бути дорогими, а також створювати нестабільність в екосистемі Android. Google безкоштовно надає Trusty партнерам-виробникам обладнання та має відкритий код. Android підтримує інші системи TEE, але Google найбільше наполягає на Trusty.

Сейф

Пристрої StrongBox — це повністю окремі, спеціально створені та сертифіковані захищені ЦП. Вони можуть включати вбудовані елементи безпеки (eSE) або блок безпечної обробки (SPU) на SoC. Google каже, що StrongBox наразі «наполегливо рекомендується» поставляти з пристроями, з якими запускаються Android 12 (згідно з документом визначення сумісності), оскільки це, ймовірно, стане обов’язковою умовою в майбутніх версіях Android. По суті, це більш сувора реалізація апаратного сховища ключів і може бути реалізована разом із TrustZone. Прикладом реалізації StrongBox є чіп Titan M у смартфонах Pixel. Небагато телефонів використовують StrongBox, а більшість використовує Trustzone ARM.

Ключник Т.А

Довірена програма Keymaster Trusted Application (TA) — це захищений майстер ключів, який керує та виконує всі операції зі сховищем ключів. Він може працювати, наприклад, у TrustZone ARM.

Як змінюється атестація ключів з Android 12 і Android 13

Якщо ключ відкритий на смартфоні Android, Google зобов’язаний анулювати його. Це створює проблему для будь-якого пристрою, який має ключ, введений на заводі – будь-який вид витоку, який відкриває ключ, означатиме, що користувачі не зможуть отримати доступ до певного захищеного вмісту. Це може включати навіть скасування доступу до таких сервісів, як Google Pay, на що покладаються багато людей. Це прикро для споживачів, оскільки без ремонту телефону виробником ви не зможете полагодити його самостійно.

Увійдіть у Remote Key Provisioning. Починаючи з Android 12, Google замінює заводську підготовку закритого ключа комбінацією вилучення відкритого ключа на заводі та надання сертифіката по повітрю з нетривалим терміном дії сертифікати. Ця схема буде потрібна в Android 13, і вона має кілька переваг. Перш за все, це позбавляє виробників комплектного обладнання та виробників продукції необхідності керувати секретністю ключів на заводі. По-друге, це дозволяє відновлювати пристрої, якщо їх ключі скомпрометовані, що означає, що споживачі не втратять доступ до захищених послуг назавжди. Тепер замість використання сертифіката, обчисленого за допомогою ключа, який є на пристрої та може бути витік через a уразливості, тимчасовий сертифікат запитується від Google щоразу, коли служба потребує атестації використовується.

Що стосується того, як це працює, то все досить просто. Унікальна статична пара ключів генерується кожним пристроєм, а загальнодоступна частина цієї пари ключів витягується OEM на своєму заводі та надсилається на сервери Google. Там вони слугуватимуть основою довіри для подальшого надання. Закритий ключ ніколи не залишає безпечне середовище, в якому він створений.

Коли пристрій вперше використовується для підключення до Інтернету, він генерує запит на підписання сертифіката для ключі, які він згенерував, підписуючи його закритим ключем, який відповідає відкритому ключу, зібраному в фабрика. Внутрішні сервери Google перевірять автентичність запиту, а потім підпишуть відкриті ключі, повертаючи ланцюжки сертифікатів. Потім сховище ключів на пристрої зберігатиме ці ланцюжки сертифікатів, призначаючи їх додаткам щоразу, коли запитується атестація. Це може бути що завгодно: від Google Pay до Pokemon Go.

Саме цей ланцюжок запитів сертифікатів відбуватиметься регулярно після закінчення терміну дії сертифікатів або вичерпання поточного запасу ключів. Кожна програма отримує інший ключ атестації, а самі ключі регулярно змінюються, що забезпечує конфіденційність. Крім того, внутрішні сервери Google сегментовані таким чином, що сервер, який перевіряє відкритий ключ пристрою, не бачить вкладених ключів атестації. Це означає, що Google не може зв’язати ключі атестації з конкретним пристроєм, який їх запитував.

Кінцеві користувачі не помітять жодних змін, хоча, згідно з Google, розробникам потрібно звернути увагу на наступне.

• Структура ланцюжка сертифікатів
  • Через характер нашої нової інфраструктури онлайн-надання довжина ланцюжка довша, ніж раніше, і може змінюватися.
• Корінь довіри
  • Корінь довіри з часом буде оновлено з поточного ключа RSA на ключ ECDSA.
• Застаріла атестація RSA
  • Усі ключі, згенеровані та засвідчені KeyMint, будуть підписані ключем ECDSA та відповідним ланцюжком сертифікатів. Раніше асиметричні ключі підписувалися за відповідним їм алгоритмом.
• Короткострокові сертифікати та ключі атестації
  • Сертифікати, надані для пристроїв, зазвичай будуть дійсні протягом двох місяців, після чого закінчиться термін їх дії та буде замінено.

Ми зв’язалися з Google і запитали, чи має це відношення до Widevine DRM і як деякі користувачі Pixel повідомили про зниження рівня DRM із заблокованим завантажувачем. Ми також запитали, чи можна зараз поширювати це як оновлення OTA серед користувачів через служби Google Play. Ми обов’язково оновимо цю статтю, якщо отримаємо відповідь. Незрозуміло, на які компоненти поточного ланцюжка довіри це вплине або яким чином.

---

Джерело: Google