Предоставянето на отдалечен ключ на Google ще бъде управлявано в Android 13, но това е сложна тема. Ето какво ще означава това за вас.
Ключовата атестация на Android е гръбнакът на много надеждни услуги на нашите смартфони, включително SafetyNet, Digital Car Key и API за идентификационни данни. Той беше необходим като част от Android от Android 8 Oreo и разчиташе на root ключ, инсталиран на устройство във фабриката. Осигуряването на тези ключове изисква изключителна секретност от страна на производителя и ако ключът изтече, това би означавало, че ключът трябва да бъде отменен. Това би довело до това, че потребителят не може да използва никоя от тези доверени услуги, което би било жалко, ако някога има уязвимост, която може да го разкрие. Remote Key Provisioning, което ще бъде упълномощено в Android 13, има за цел да разреши този проблем.
Компонентите, съставляващи текущата верига на доверие в Android
Преди да обясните как работи новата система, важно е да предоставите контекст за това как
Това е комбинация от тези концепции, която гарантира, че разработчикът може да се довери, че дадено устройство не е било манипулирано и може да обработва чувствителна информация в TEE.
Доверена среда за изпълнение
Доверена среда за изпълнение (TEE) е защитен регион на SoC, който се използва за обработка на критични данни. TEE е задължителен за устройства, стартирани с Android 8 Oreo и по-нова версия, което означава, че всеки нов смартфон го има. Всичко извън TEE се счита за „ненадеждно“ и може да вижда само криптирано съдържание. Например защитеното с DRM съдържание е криптирано с ключове, които могат да бъдат достъпни само от софтуер, работещ на TEE. Главният процесор може да вижда само поток от криптирано съдържание, докато съдържанието може да бъде декриптирано от TEE и след това показано на потребителя.
ARM Trustzone
Trusty е сигурна операционна система, която предоставя TEE на Android, а на ARM системи използва Trustzone на ARM. Trusty се изпълнява на същия процесор като основната операционна система и има достъп до пълната мощност на устройството, но е напълно изолиран от останалата част от телефона. Trusty се състои от следното:
- Малко OS ядро, получено от Малко ядро
- Драйвер на ядрото на Linux за прехвърляне на данни между защитената среда и Android
- Библиотека с потребителско пространство на Android за комуникация с доверени приложения (т.е. защитени задачи/услуги) чрез драйвера на ядрото
Предимството, което има пред собствените TEE системи е, че тези TEE системи могат да бъдат скъпи и също така да създадат нестабилност в екосистемата на Android. Trusty се предоставя на партньори OEM производители безплатно от Google и е с отворен код. Android поддържа други TEE системи, но Trusty е тази, която Google настоява най-много.
Силна кутия
Устройствата StrongBox са напълно отделни, специално създадени и сертифицирани защитени процесори. Те могат да включват вградени защитени елементи (eSE) или защитено обработващо устройство (SPU) на SoC. Google казва, че в момента StrongBox е „силно препоръчително“ да се доставя с устройства, стартиращи с него Android 12 (съгласно документа за дефиниция на съвместимостта), тъй като е вероятно да стане изискване в бъдеща версия на Android. По същество това е по-стриктно внедряване на хардуерно поддържано хранилище за ключове и може да бъде внедрено заедно с TrustZone. Пример за внедряване на StrongBox е чипът Titan M в смартфоните Pixel. Не много телефони използват StrongBox, а повечето използват Trustzone на ARM.
Keymaster TA
Keymaster Trusted Application (TA) е защитеният keymaster, който управлява и изпълнява всички операции за съхраняване на ключове. Може да работи например в TrustZone на ARM.
Как се променя атестацията на ключове с Android 12 и Android 13
Ако ключ е изложен на смартфон с Android, Google трябва да го отмени. Това създава проблем за всяко устройство, което има ключ, инжектиран фабрично - всякакъв вид изтичане, което излага ключа, би означавало, че потребителите няма да имат достъп до определено защитено съдържание. Това може дори да включва отнемане на достъп до услуги като Google Pay, нещо, на което много хора разчитат. Това е жалко за потребителите, защото без телефонът ви да бъде ремонтиран от производител, няма да има начин да го поправите сами.
Въведете Remote Key Provisioning. Започвайки с Android 12, Google заменя фабричното предоставяне на частни ключове с комбинация от извличане на публичен ключ във фабриката и предоставяне на сертификати по въздуха с кратък живот сертификати. Тази схема ще се изисква в Android 13 и има няколко предимства. На първо място, той не позволява на OEM и ODM да се налага да управляват секретността на ключовете във фабриката. Второ, той позволява устройствата да бъдат възстановени, ако ключовете им бъдат компрометирани, което означава, че потребителите няма да загубят достъп до защитени услуги завинаги. Сега, вместо да използвате сертификат, изчислен с помощта на ключ, който е на устройството и може да бъде изтекъл през 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