Об авторе: Дмитрий Алтухов, cоветник директора ФРИИ
Мобильный рынок России остаётся «технологической колонией» американских компаний Apple и Google, при сокращении доли iOS абсолютным лидером стали китайские смартфоны с Android. «Официальные» приложения банков, попавших под санкции, внешне ничем не отличаются от вредоносного ПО. В Реестре отечественного ПО появились клоны AOSP, в которых уровень безопасности крайне низкий… К чему всё это приведёт? Попробуем разобраться.
В этом году исполняется 10 лет термину «импортозамещение», когда после первых санкций недружественных стран начало появляться понимание, что нельзя полностью зависеть от иностранных IT-решений. Но где же мы находимся сегодня?
За последний год ситуация в части нашей зависимости от мобильных технологий недружественных стран практически не изменилась. Если в области оборудования, настольных и серверных операционных систем, офисных приложений переход на российские решения идёт полным ходом – иностранные производители ушли с рынка, отключают доступ к облачным продуктам, – просто не осталось другого выбора, то в мобильных устройствах и ОС всё остаётся практически без изменений. Apple и Google ушли, но не совсем, поэтому, вероятно, наши регулирующие и надзорные органы так и не начали серьёзно заниматься этим вопросом. Между тем, мобильные приложения компаний (и особенно банков), включённых в санкционные списки, продолжают исчезать из магазинов приложений, а никакой реакции со стороны государства мы не видим. Более того, на платформе Apple банки выпускают «официальные» приложения под непонятными названиями, с каких-то странных одноразовых учётных записей разработчиков. Эти приложения, очевидно, чисто «партизанский» способ публикации обновлений, они существуют в App Store не больше одного дня и исчезают. Хуже того, отличить их от заведомо вредоносных приложений невозможно.
Совсем недавние истории: в конце января в Apple App Store на один день проскочило через цензуру модерации «официальное приложение» «Сбера», которое вообще называлось «Учёт Онлайн» и имело разный функционал в зависимости от страны, а 9 апреля не несколько часов появилось приложение «Т-Помощь», которое «Тинькофф» объявил официальным обновлением. На следующий день МВД в который раз предупредило об опасности фальшивых фишинговых приложений банков, ну а 15 апреля на примерно такой же период времени появилось очередное вредоносное приложение «Сбер: Онлайн Банк». Но как пользователю отличить его от настоящего? Если в обоих случаях приложение разработано непонятно кем, что отлично видно на рисунке. Только по сообщениям банков в соцсетях и прессе? Очень оригинально…
Ну что же, видимо, «у нас в клубе принято джентльменам верить на слово».
Но смартфоны Apple всё же не самая массовая часть рынка. В 2023 году в Россию импортировано 29,5 миллионов смартфонов, доля Apple закономерно сокращается (2,5 миллиона устройств), а доля смартфонов из КНР достигла почти 80%. А это смартфоны с Android, подключённые к облаку Google. Отечественные смартфоны и планшеты продаются в количествах сотен, максимум – нескольких тысяч штук. Ни о каких миллионах российских устройств на рынке речь сегодня не идёт, да и вряд ли ситуация может измениться в ближайшее время без участия государства. Более того, полноценный Android c мобильными сервисами Google (GMS) официальным образом российские производители использовать не могут, поэтому начали появляться «отечественные» мобильные ОС на основе AOSP. Что такое «отечественные» – заслуживает отдельного разговора, к которому я вернусь в следующей публикации.
А теперь попробуем оценить, насколько безопасно использовать банковские приложения, попавшие под санкции и удалённые из Google Play на мобильных устройствах как на базе Android, так и AOSP (без GMS). Большинство людей почему-то считает, что приложения для мобильных ОС ничем не отличаются от приложений на компьютерах: установил, проверил антивирусом и всё в порядке. И ладно бы ещё такое мнение было бы среди рядовых потребителей. К сожалению, эту ошибочную концепцию продвигают и ряд поставщиков IT-решений, и некоторые чиновники, ответственные за регулирование отрасли, и даже разработчик магазина приложений.
Начнём с архитектуры безопасности Android. С учётом многолетней истории взломов, распространения вредоносного ПО, о чём я писал в статье «Запретить нельзя разрешить: как запрет использования iPhone помогает американским спецслужбам», к 2024 году Google проделал огромную работу по усилению мер защиты как самой ОС, так и пользовательских данных и приложений. На сегодняшний день в Android используется многослойный комплекс из аппаратных и программных средств защиты, представленный на рисунке. Значительная часть этого функционала использует облачные сервисы Google и недоступна для устройств с AOSP и производными ОС.
Android использует аппаратные функции современных процессоров ARM для обеспечения надёжной защиты устройства. Процессор предоставляет среду доверенного исполнения (Trusted Execution Environment, TEE) (TrustZone на устройствах ARM). Такая дополнительная изолированная среда «виртуализирует» основной процессор и создаёт безопасную, доверенную среду выполнения. В Android многие конфиденциальные операции (разблокировка устройства, работа с учётными и биометрическими данными) выполняются в ограниченной, изолированной среде TEE. Сама ОС Android считается «недоверенной», что означает, что она не может получить доступ к определенным областям оперативной памяти, аппаратным регистрам и т. д., где хранятся данные, требующие дополнительной защиты (например, криптографические ключи устройства, предоставленные производителем). TEE состоит из отдельной небольшой операционной системы и мини-приложений, которые предоставляют критически важные сервисы Android (например, биометрию и разблокировку устройства). Хотя TEE работает на том же процессоре, что и Android, аппаратное обеспечение ARM архитектурно изолирует ядро Android Linux и приложения от TEE. Реализация TEE в целом остаётся на совести производителя устройств, а для своих смартфонов Pixel Google использует собственную загрузочную операционную систему Trusty.
На аппаратном уровне в Android также реализована аттестация ключей криптографии, и здесь начинается самое интересное. Устройства, выпущенные с Android 8.0 и выше, должны поддерживать функцию «Аттестация ключей», которая позволяет серверу получить подтверждение свойств устройства и сгенерированных на нём ключей. Корневой сертификат подписывается корневым ключом Google, что указывает на то, что устройство является сертифицированным устройством Google Android. Эти ключи аттестации можно использовать для подписания достоверных данных о важных свойствах целостности устройства, например, о том, заблокирован ли загрузчик и какие уровни патчей безопасности установлены. Применимо ли это к AOSP? И да, и нет. С одной стороны, код открыт и доступен, но разработчик дериватива и производитель устройства должны сами обеспечить всю инфраструктуру криптографии и её безопасность. Встроенные СЗИ в полном объёме в AOSP отсутствуют.
На уровне ПО ситуация ещё сложнее: Google Play Protect и Play Integrity API — это облачные сервисы на GMS-сертифицированных устройствах, которые помогают обнаруживать вредоносное ПО и компрометацию устройства. Google Play Protect — самая распространённая в мире служба обнаружения угроз, которая ежедневно активно сканирует более 125 миллиардов приложений на устройствах на предмет выявления вредоносных программ. Google Play Protect сканирует все приложения, включая общедоступные приложения из Google Play, системные приложения, обновляемые производителями оригинального оборудования (OEM) и операторами связи, и даже приложения, загружаемые пользователями самостоятельно. Play Integrity API позволяет разработчикам проверить, что взаимодействия и запросы к серверу исходят от подлинного экземпляра приложения, запущенного на подлинном устройстве Android, которое не было взломано (рут устройства – это взлом). Обнаружив потенциально рискованные и мошеннические взаимодействия, например, из поддельных версий приложений и ненадёжных сред, серверный бэкенд приложения может предпринять соответствующие действия, чтобы предотвратить атаки и уменьшить количество злоупотреблений.
Банковские приложения, как правило, используют какие-то собственные механизмы защиты от взлома, но простота обратного инжиниринга приложений для Android априори делает такую защиту ненадёжной. Только возможности аппаратной аттестации ключей и использования Play Integrity API (ранее – SafetyNet API) дают значительно более надёжную защиту. И в последние годы большая часть банков в мире и России активно использовали такие механизмы защиты. Всего этого функционала, естественно, нет в AOSP.
Итак, уровень безопасности банковского приложения из Google Play, которое использует механизмы защиты Google, на сертифицированном устройстве Android можно оценить как достаточно неплохой. Кстати, в Huawei при реализации своих облачных мобильных сервисов на замену GMS одним из первых разработали аналог, Safety Detect. Safety Detect обеспечивает ряд функций безопасности, в первую очередь контроль целостности системы и приложений.
А теперь посмотрим, что будет с банковским приложением на Android, если сервисы Google недоступны. Если приложение установлено из Huawei AppGallery и использует Safety Detect – то уровень безопасности будет сопоставим.
А вот российские магазины приложений, включая RuStore, никаких механизмов защиты не предлагают, и остаётся лишь надеяться на общий уровень безопасности ОС Android. В RuStore встроен антивирус Касперского, но, как мы уже увидели на примере архитектуры безопасности Android – это совсем не настольная ОС, и одним антивирусом безопасность обеспечить невозможно. Ну что же, похоже, что и здесь «у нас в клубе принято джентльменам верить на слово».
И, наконец, рассмотрим абстрактное устройство с мобильной ОС на базе AOSP из Реестра и встроенным RuStore. Увы, ни у одного устройства и ни у одной ОС вообще нет опубликованной документации, в которой можно было бы найти информацию о включённых функциях безопасности и способах их реализации. У Google и Huawei все механизмы документированы, все API описаны, есть примеры кода. Даже у иностранных деривативов AOSP есть соответствующая документация. А у нас – раз разработчик говорит, что всё совершенно безопасно, то так и есть на самом деле, то есть снова «принято джентльменам верить на слово».
На подобном устройстве с клоном AOSP банковское приложение никак не защищено ни на уровне аппаратной поддержки, ни на уровне ОС, ни на уровне облачных сервисов. Поэтому появление вредоносного ПО, созданного специально для таких устройств – несложная задача и только вопрос времени. А последствия от эксплойтов будут, скорее всего, крайне тяжёлыми и дорогими. Пока спасает только малое количество таких устройств на рынке.
А что в корпоративной мобильности? Android Enterprise включает в себя API-интерфейс управления, встроенный исключительно в сертифицированные GMS устройства, реализующий более 80 функций и настроек, что позволяет осуществлять универсальное и единообразное управление, но только через облако Google: благодаря управляемому Google Play и управляемым аккаунтам Google Play на рабочих устройствах можно не только запретить установку из неизвестных источников, но и в управляемом Google Play будут отображаться только приложения, явно одобренные администраторами, причём фоновая (без участия пользователя) установка приложений является стандартной функцией. Начиная с версии Android 10 для устройств без сертификации GMS на базе AOSP реализация механизмов Android Enterprise официально недоступна. Неофициально современные устройства AOSP (без GMS) предоставляют ограниченные возможности управления, но это не полноценная поддержка EMM-систем (Enterprise mobility management, управление корпоративной мобильностью – ред.), что отражено и в документации иностранных EMM/UEM систем (UEM – Unified Endpoint Management, управление разнородными устройствами в единой IT-системе – ред.).
Таким образом, устройства с «отечественным» AOSP, не имеющие механизмов безопасности, полноценной реализации СЗИ и поддержки взаимодействия с EMM на уровне API не могут быть адекватной заменой Android в управляемой корпоративной среде. А с учётом того, что сложно представить себе, как такие ОС и устройства вообще смогут пройти сертификацию ФСБ и ФСТЭК – не очень понятно, зачем деривативы AOSP включаются в Реестр. Вероятно – в надежде, что у заказчиков тоже «принято джентльменам верить на слово» и не везде нужны эти сертификаты.
Есть ли альтернатива? Да, и существует достаточно давно. Как минимум, одна из мобильных ОС в Реестре, имеющих в основе архитектуру Linux, а именно, «Аврора» реализует все необходимые механизмы обеспечения безопасности и управления мобильными устройствами, детально описанные в документации. По другим мобильным ОС никакой опубликованной документации на момент подготовки статьи обнаружить не удалось.
Итак, «Аврора». Прежде всего, нужно отметить наличие полноценной опубликованной документации для пользователей и разработчиков, реализацию СЗИ (включая алгоритмы ГОСТ) в ОС и сертификацию ФСТЭК и ФСБ. В части аппаратной поддержки функций безопасности присутствуют: верифицируемая загрузка присутствует (в терминах «Авроры» – доверенная), доверенная среда исполнения (TEE), правда, доступна не на всех устройствах. Защищённое хранилище ключей и аттестация ключей – есть на устройствах с ТЕЕ. Кроме того, реализованы механизмы самозащиты ядра, сервисы контроля целостности данных и системы, обеспечивается динамический контроль целостности ядра.
На уровне ОС каждое приложение запускается в изолированном окружении (песочнице), которое ограничивает доступ к API и данным. Обеспечивается защита от загрузки и запуска недоверенного кода на устройствах за счёт подписи пакетов, динамического контроля целостности исполняемых файлов и валидации используемого API. Кроме того, в ОС «Аврора» реализован программный интерфейс Antivirus API, предназначенный для разработки и использования антивирусного ПО с минимально необходимыми для этого правами и изоляцией от внешнего воздействия других приложений или пользователей.
Для использования в корпоративной среде в ОС «Аврора» реализованы API для управления устройствами. MDM (управление мобильными устройствами – ред.) API «Авроры» включает более 100 классов для управления устройствами, что позволяет создавать полноценные EMM-решения. Среди российских EMM систем для «Авроры» отметим собственную разработку ООО «Открытая мобильная платформа» «Аврора Центр» и решение ООО «НИИ СОКБ» UEM SafeMobile.
С учётом того, что «Аврора» и «Аврора TEE» полностью контролируются и развиваются российским разработчиком, включены в Реестр, в ОС полностью реализованы СЗИ, поддерживаются шифрование и сертификаты по ГОСТ – казалось бы, что ещё нужно для обеспечения безопасной мобильности как корпоративного, так и для потребительского рынка, особенно для банковских приложений? В случае «Авроры» — доверенная ОС происходит от слова «доверие», а не от слова «вера».
Но, увы, на рынке продолжается вакханалия иностранных ОС, безопасность которых зависит от американского облака, либо клонов AOSP, где безопасности нет в принципе. Ну что же, видимо, пока в России не будет принято политическое решение, так и будет продолжаться история «принято джентльменам верить на слово».