Справедливо. Никакой свой код в первичном загрузчике и в том что работает в ARM TrustZone без embedded ключа запустить не получится, разумеется.
Тем не менее «желтого» состояния достаточно чтобы при физическом доступе нельзя было загрузить рековери образ или поменять что-либо в read-only разделах.
Похоже на то. Значит их ещё могут и выпускать. Я сам никогда не сталкивался с FDE лично, а почти везде написано что в основном шифрование в андроиде это всегда FBE
О, интересно, не знал о таком. Может потихоньку это переползёт и в основной андроид.
Самсунги вообще крепко заморачиваются с безопасностью, и для многих нововведений являются локомотивом. Я читал про то что они используют отдельные расширения ядра для защиты от модификации и в установщике magisk даже есть отдельные патчи именно под самсунги, как раз видимо для подобных случаев. Именно с подачи самсунга в android был введён SELinux, Google перетащили его в основную кодовую базу именно посмотрев на самсунг
Ломать экран ему нет необходимости. Пользователь сам введёт код разблокировки. Пока система грузится, зловредный процесс уже начинает работу, он ждёт расшифровки и когда она происходит предоставляет удалённый доступ. Если устройство, например имеет установленную систему до android 8 включительно, где шифрование хранилища ещё не было обязательным, и речь идёт именно о таком устройстве, то тогда злоумышленник сразу получает доступ к данным, не дожидаясь ввода кода разблокировки
FDE заставляет пользователя вводить лишний раз пароль при старте, усложняет процесс загрузки — сначала необходимо загрузить мини-образ системы с формой ввода пароля, а потом уже основную систему. Если я правильно понял, (сам я не застал устройств с FDE) то там также шифровался только userdata раздел, так что, в общем-то, выигрыша по безопасности в плане невозможности модифицировать boot и system FDE не даёт
Увы, большинство мер по доверенной загрузке и прочим очень низкоуровневым механизмам не относятся к коду самой системы напрямую, их реализует вендор просто ориентируясь на определённый интерфейс в системе с которым будет взаимодействовать. Сейчас эта мера — комплекс всех инструментов реализующих процесс verified boot. Накрутить что-то кастомное — очень сложно, и требует владения железом и драйверами к нему, т.е. фактически невозможно в нынешних условиях
Получается организованы. Начиная с android 9 это обязательное требование для получения сертификации от гугла. Думаю что на всех современных устройствах это работает, и это хорошо.
В системе существует API DirectBoot, которое позволяет запускать приложения до расшифровки хранилища. Это нужно для будильников, звонилок, и т.д, но все обычные приложения до расшифровки файловой системы работать не могут
Спасибо. Да, злоумышленник получает доступ только после того как владелец сам введёт код разблокировки устройства. Без этого никак — хранилище будет зашифровано до первого ввода кода.
А то что дальше по статье, как я понимаю, фиксится достаточно просто: после получения телефона обратно, нужно не разблокируя перезагрузить в свой образ twrp через fastboot, зашить свой twrp, вдруг его тоже заменили. Затем загрузиться в него, зашить заново ту же ОС, что и стояла ранее (перезапишутся /system и /boot)
Да, такой подход решает проблему, но требует ковыряния руками, что не каждому захочется делать. Как я упоминал, суть статьи не в том, чтобы не пользоваться альтернативными сборками ОС, а в том, чтобы не забывать что их использование несёт дополнительные риски, о которых необходимо помнить.
Мы рассматриваем гипотетический случай когда условный пограничник получил в руки заблокированный телефон, и не прибегает к насилию для того чтобы заставить его разблокировать. Установить root можно, но зачем? Это не поможет снять информацию на месте если владелец не станет разблокировать устройство, а вот подкинуть бэкдор — другое дело. Владелец разблокирует девайс самостоятельно, а бэкдор поможет изъять данные
Ого, спасибо большое за отзыв. Я пробовал CarbonROM. Отдельный респект за user-сборки!
1. Увы, разблокированный загрузчик даёт злоумышленнику возможность не полагаться на текущее установленное рековери. Он просто загружает и использует своё.
2. В теории может, если будет подписано приватным ключом зашитым в TEE либо в avb_custom_key, но это максимально маловероятно. К тому же, наличие заблокированного загрузчика не даст загрузить систему после внесённых изменений, aboot будет падать в «red state» и откажется загружаться.
Насколько я понимаю, повлиять на aboot мы не можем, он зашивается в девайс и его целостность проверяется при загрузке ключом из TEE, мы можем начинать устраивать какие-то махинации, но только с запуска ядра, aboot работает раньше.
По поводу user-settable root of trust. Это точно возможно на пикселях, ванплюсах, и, как подсказывают камрады в комментариях, яндексофонах, на остальных — маловероятно.
Это dynamic partitions. Насколько я понимаю, такой подход нужен для удобного изменения размеров разделов, но пока что он не так распространён. Тем не менее, даже при старом подходе объём занятого system никак не влияет на объём userdata
К сожалению, пароль в TWRP — это прикладная логика именно самого TWRP. Состояние заблокированного/разблокированного загрузчика к TWRP никакого отношения не имеет. Если у вас установлен TWRP, то в 99% случаев это значит что устройство имеет разблокированный загрузчик.
Это никак не защищает от описанного потому, что с разблокированным загрузчиком злоумышленнику нет смысла пытаться угадывать пароль TWRP — он просто загружает образ TWRP без пароля и шьёт в устройство что пожелает.
Часть статьи как раз описывает что когда мы обычно говорим что устройство «зашифровано», то на самом деле в нём зашифровано всего лишь две директории. Злоумышленник может установить нагрузку в ту часть системы, которая не шифруется FBE
Приведённый в примере пейлоад ждёт пока владелец введёт код разблокировки первый раз, после чего открывает удалённый шелл к устройству. После первой разблокировки устройства данные уже всегда остаются незашифрованными, вплоть до выключения смартфона, поэтому злоумышленник может стащить документы с устройства. Если после возврата устройства пользователь ни разу не будет вводить код разблокировки, то конечно ничего достать не получится
Честно говоря, не слышал о том что по вышеупомянутому закону планируется устанавливать дополнительные корневые сертификаты, но не удивлюсь если им очень сильно захочется попытаться это сделать.
Я видел патч для сорцов андроида, который удаляет из системного хранилища некоторые корневые сертификаты китайского происхождения, автор уверяет что они используются для МИТМов. Уверен, что если кто-то подкинет эту идею нашим органам, то она им очень понравится и они постараются её претворить в жизнь
Современные устройства, на мой взгляд, однозначно будут менее подвержены разным зловредам, т.к. получают регулярные обновления безопасности. В общем-то, я не призываю отказываться от LineageOS, это отличная альтернативна стоковой прошивке для тех кто хочет большей приватности. Статья про то, что пользуясь ей нужно помнить о появлении дополнительного рода угроз и стараться не допускать попадания устройства в чужие руки
Да, это реально сработает. Можно проверять что хэши разделов не изменились если есть подозрения на модификации. Сменились — накатываем бэкап. К сожалению, для этого нужно выработать привычку пересчитывать хэши всех важных разделов сразу после установки обновлений
Спасибо! Похожий трюк с сохранением последней рабочей конфигурации делает, например, сам magisk. Только он так сохраняет лишь boot и dtb* разделы. При удалении — шьёт их на место чтобы всё было как на немодифицированной системе.
А ещё так делает сам андроид. Механизм который вы описываете очень похож на систему обновлений с A/B разделами, которая есть на большинстве современных устройств. Там разделы дублируются и обновление устанавливается только на один «слот» из двух, а второй остаётся неизменным, чтобы иметь возможность откатиться на него в случае если обновление поломает работу системы.
Теоретически, мы можем «откатиться» на резервный слот после того как устройство побывало у злоумышленников, однако злоумышленник может накатить нагрузку в оба слота сразу
Заглянул вот в документацию:
https://source.android.com/security/encryption/file-based?hl=en
Пишут вот такое:
For new devices running Android 10 and higher, file-based encryption is required.
Да, при штатном поведении в обоих случаях раздел userdata будет отформатирован.
Справедливо. Никакой свой код в первичном загрузчике и в том что работает в ARM TrustZone без embedded ключа запустить не получится, разумеется.
Тем не менее «желтого» состояния достаточно чтобы при физическом доступе нельзя было загрузить рековери образ или поменять что-либо в read-only разделах.
Похоже на то. Значит их ещё могут и выпускать. Я сам никогда не сталкивался с FDE лично, а почти везде написано что в основном шифрование в андроиде это всегда FBE
Самсунги вообще крепко заморачиваются с безопасностью, и для многих нововведений являются локомотивом. Я читал про то что они используют отдельные расширения ядра для защиты от модификации и в установщике magisk даже есть отдельные патчи именно под самсунги, как раз видимо для подобных случаев. Именно с подачи самсунга в android был введён SELinux, Google перетащили его в основную кодовую базу именно посмотрев на самсунг
Увы, большинство мер по доверенной загрузке и прочим очень низкоуровневым механизмам не относятся к коду самой системы напрямую, их реализует вендор просто ориентируясь на определённый интерфейс в системе с которым будет взаимодействовать. Сейчас эта мера — комплекс всех инструментов реализующих процесс verified boot. Накрутить что-то кастомное — очень сложно, и требует владения железом и драйверами к нему, т.е. фактически невозможно в нынешних условиях
В системе существует API DirectBoot, которое позволяет запускать приложения до расшифровки хранилища. Это нужно для будильников, звонилок, и т.д, но все обычные приложения до расшифровки файловой системы работать не могут
Да, такой подход решает проблему, но требует ковыряния руками, что не каждому захочется делать. Как я упоминал, суть статьи не в том, чтобы не пользоваться альтернативными сборками ОС, а в том, чтобы не забывать что их использование несёт дополнительные риски, о которых необходимо помнить.
1. Увы, разблокированный загрузчик даёт злоумышленнику возможность не полагаться на текущее установленное рековери. Он просто загружает и использует своё.
2. В теории может, если будет подписано приватным ключом зашитым в TEE либо в avb_custom_key, но это максимально маловероятно. К тому же, наличие заблокированного загрузчика не даст загрузить систему после внесённых изменений, aboot будет падать в «red state» и откажется загружаться.
Насколько я понимаю, повлиять на aboot мы не можем, он зашивается в девайс и его целостность проверяется при загрузке ключом из TEE, мы можем начинать устраивать какие-то махинации, но только с запуска ядра, aboot работает раньше.
По поводу user-settable root of trust. Это точно возможно на пикселях, ванплюсах, и, как подсказывают камрады в комментариях, яндексофонах, на остальных — маловероятно.
Это никак не защищает от описанного потому, что с разблокированным загрузчиком злоумышленнику нет смысла пытаться угадывать пароль TWRP — он просто загружает образ TWRP без пароля и шьёт в устройство что пожелает.
Часть статьи как раз описывает что когда мы обычно говорим что устройство «зашифровано», то на самом деле в нём зашифровано всего лишь две директории. Злоумышленник может установить нагрузку в ту часть системы, которая не шифруется FBE
Честно говоря, не слышал о том что по вышеупомянутому закону планируется устанавливать дополнительные корневые сертификаты, но не удивлюсь если им очень сильно захочется попытаться это сделать.
Я видел патч для сорцов андроида, который удаляет из системного хранилища некоторые корневые сертификаты китайского происхождения, автор уверяет что они используются для МИТМов. Уверен, что если кто-то подкинет эту идею нашим органам, то она им очень понравится и они постараются её претворить в жизнь
Спасибо большое!
Современные устройства, на мой взгляд, однозначно будут менее подвержены разным зловредам, т.к. получают регулярные обновления безопасности. В общем-то, я не призываю отказываться от LineageOS, это отличная альтернативна стоковой прошивке для тех кто хочет большей приватности. Статья про то, что пользуясь ей нужно помнить о появлении дополнительного рода угроз и стараться не допускать попадания устройства в чужие руки
Да, это реально сработает. Можно проверять что хэши разделов не изменились если есть подозрения на модификации. Сменились — накатываем бэкап. К сожалению, для этого нужно выработать привычку пересчитывать хэши всех важных разделов сразу после установки обновлений
Спасибо! Похожий трюк с сохранением последней рабочей конфигурации делает, например, сам magisk. Только он так сохраняет лишь boot и dtb* разделы. При удалении — шьёт их на место чтобы всё было как на немодифицированной системе.
А ещё так делает сам андроид. Механизм который вы описываете очень похож на систему обновлений с A/B разделами, которая есть на большинстве современных устройств. Там разделы дублируются и обновление устанавливается только на один «слот» из двух, а второй остаётся неизменным, чтобы иметь возможность откатиться на него в случае если обновление поломает работу системы.
Теоретически, мы можем «откатиться» на резервный слот после того как устройство побывало у злоумышленников, однако злоумышленник может накатить нагрузку в оба слота сразу