Современный рынок мобильных операционных систем поделен на два сегмента. К одному относятся аппараты на базе Android, к другому — iPhone. Однако в 2019-м году после некоторых событий компания Huawei представила свою операционную систему Harmony OS.

Что такое Harmony OS

Разработанная Huawei операционная система взаимодействует с несколькими умными устройствами для создания своей экосистемы. На данный момент она поддерживает следующие устройства:

• Мобильные телефоны/планшеты

• Носимые устройства

• IoT

• Телевизоры

• Машины

Доля Harmony OS на мировом рынке:

Доля Harmony OS на китайском рынке:

Источник

Как можно заметить, ОС неплохо развивается на своем родном рынке и понемногу отбирает долю Android-смартфонов.

С технической точки зрения, Harmony OS в текущей многоядерной структуре использует подходящие ядра для устройств с различными компонентами. Известно, что для IoT-устройств система основана на ядре LiteOS, в то время как для смартфонов и планшетов — на ядре Linux с AOSP для поддержки приложений в формате APK (в дополнение к нативным приложениям HAP с помощью компилятора Ark).

ОС включает в себя коммуникационную систему DSoftBus для интеграции физически отдельных устройств в виртуальное суперустройство, позволяющее одному гаджету управлять другими и обмениваться данными между девайсами с разными возможностями.

Архитектура ОС

Именно так выглядит архитектура HarmonyOS. Далее более подробно рассмотрим каждый уровень ОС.

• Уровень ядра:

  • Подсистема ядра:

    • Harmony использует многоядерную структуру, поэтому можно использовать подходящие ядра ОС для устройств с различными ресурсами. Уровень абстракции ядра (KAL) скрывает различия в реализациях ядра и предоставляет верхнеуровневые базовые возможности, включая управление процессами и потоками, управление памятью, файловой системой, сетевым управлением и периферийным управлением.

  • Подсистема драйверов:

    • Hardware Driver Foundation (HDF) закладывает основу для открытой аппаратной экосистемы HarmonyOS. Это обеспечивает единый доступ с периферийных устройств и обеспечивает базу для разработки драйверов и управления ими.

• Уровень системы:

  • Набор базовых подсистем возможностей системы:

    • Реализует работу приложений между разными HarmonyOS-девайсами. Также, Ark (компилятор) использует среды выполнения С, С++, JS и предоставляет набор базовых системных библиотек. Он также предоставляет среду выполнения для Java-программ, статически скомпилированных Ark.

  • Набор базовых подсистем сервисов программного обеспечения:

    • Обеспечивает HarmonyOS общими и универсальными программными сервисами, включая уведомления, телефонию, мультимедиа и тд.

  • Набор расширенных подсистем сервисов программного обеспечения:

    • Обеспечивает HarmonyOS расширенными программными сервисами, включая "умные" телевизоры, носимые устройства, IoT-устройства и тд.

  • Набор аппаратных подсистем сервисов:

    • Обеспечивает HarmonyOS аппаратными сервисами, включая определение местоположения, биометрическое распознавание, а также сервисы, предназначенные для носимых и IoT-устройств.

• Уровень Фреймворка:

  • Предоставляет API для взаимодействия приложений с программными и аппаратными сервисами, фреймворки приложений для соответствующих ЯП и UI. Доступно для разных девайсов Harmony OS.

• Уровень приложений

  • Состоит из системных и сторонних приложений. Каждое приложение состоит из 1 и более Feature ability(FA) и Particle ability(PA). FA предоставляет UI для взаимодействия с пользователем, а PA уже реализует функциональность FA.

Уровень системы (Набор базовых подсистем возможностей системы):

Совместная работа разных девайсов. Применяемые технологии: DSoftBus, распределенная виртуализация девайсов, данные и планировщик.

Более подробно можно посмотреть тут

Безопасность

Распределенная модель безопасности:

• Аутентификация пользователя

• Аутентификация устройства

• Проверка запрашиваемых данных

Пользователь

• Модель "нулевого" доверия

• Мультифакторная аутентификация

• Совместная аутентификация

Девайс

• Secure Boot

• TEE

• Device certificate authentication

  • HarmonyOS предварительно конфигурирует public key infrastructure(PKI) в TEE устройства для дальнейшей аутентификации данного устройства с другими устройствами. Приватный ключ хранится и может быть использован только в ТЕЕ.

  • При передачи чувствительных данных безопасный канал связи между устройствами создается только после подтверждения PKI устройств.

Данные

• Генерация данных

• Хранение данных

• Использование данных

• Передаче данных

• Уничтожение данных

Разработка приложений

В HarmonyOS, помимо стандартной для Android разработки на Java(Kotlin), есть возможность разработки на ArkTS. Он является предпочтительным (нативным) для этой ОС.

Основы приложений

Приложения, работающие на HarmonyOS, делятся на следующие виды:

• Приложения, устанавливаемые обычным способом

• Приложения, не требующие установки Atomic Services, обеспечивающие определенную функциональность

Структура приложений

Приложение выпускается как App Pack(.app), состоит из одного и более файлов HarmonyOS Ability Package (HAP) и файла pack.info, который описывает атрибуты каждого HAP-файла.

Один HAP-файл — это пакет модулей, состоящий из кода, ресурсов, сторонних библиотек и файла конфигурации приложения. HAP-файлы можно разделить на модули Entry и Feature.

• Entry — основной модуль приложения. В приложении может быть более одного Entry HAP для поддержки разного типа устройств, для это требуется настроить правила распространения(distroFilter — distribution rules).

• Feature — динамический модули; только эти модули, содержащие функциональность, могут работать независимо.

Ability

Ability — это абстракция функциональности, которую может предоставить приложение. Одно приложение может содержать одну или несколько Abilities. Способности классифицируются на Feature ability (FA) и Particle ability (PA). FA и PA являются базовыми единицами приложений для реализации конкретных функциональных возможностей приложения. Их различие заключается в том, что у FA есть пользовательский интерфейс, а у PA — нет.

Libs

Файлы сторонних библиотек — это файлы кода сторонних разработчиков, от которых зависят приложения. Это двоичные файлы, такие как .so, .jar, .bin и .har, хранящиеся в каталоге libs.

Resources

Файлы ресурсов приложения, такие как строки, изображения и аудио файлы. Хранятся в каталоге ресурсов, что позволяет вам легко получить к ним доступ, использовать и поддерживать их.

Config.json

config.json — это конфигурационный файл приложения. Он используется для объявления возможностей приложения и разрешений, необходимых приложению.

• global — информация о приложении (bundle name, version, vendor)

• device-specific — информация о приложении (backup, restoration network security capabilities)

• HAP information — информация об атрибутах (basic, permissions — взаимодействие с системой и другими приложениями)

Приложения на Java и ArkTS имеют разные набор атрибутов.

pack.info

pack.info описывает атрибуты каждого HAP в составе приложения.
Атрибуты:

• delivery-with-install — указывает, может ли HAP-файл быть установлен во время установки приложения. Значение true указывает, что HAP-файл может быть установлен во время установки приложения, а false — наоборот.

• name — указывает имя HAP-файла,

• module-type — указывает тип модуля. Значение может быть entry или feature,

• device-type — указывает тип устройства, поддерживающего HAP-файл..

Безопасная разработка приложений

Сама Huawei разработала гайд о том, как безопасно разрабатывать приложения для своей ОС. Практически все пункты из данного списка можно использовать для аудита мобильных приложений.

Huawei Mobile Services

Платформа HMS Core, созданная на базе устройств Huawei и платформы Android, — это среда, которая открывает множество возможностей для разработчиков приложений. HMS Core предоставляет пользователям устройств Huawei базовые службы.

Как и GMS Core (сервисы Google для мобильных устройств), сервисы HMS Core могут работать на базе Android Open Source Project (система Android) и поддерживать приложения Android. Однако некоторые приложения Android требуют поддержки GMS Core и могут не работать на HMS Core.

Основные категории HMS Core:

• App Services

• Graphics

• Media

• AI

• Smart Device

• Security

• System

• Cross-platform

• Common

Более подробно разбирать приложения из каждой категории необходимости нет, поскольку это не предмет данной статьи.

Но вот подходы компаний по применению данных сервисов:

1. https://habr.com/ru/companies/koshelek/articles/522008/

2. https://habr.com/ru/companies/hh/articles/665204/

3. https://habr.com/ru/companies/friflex/articles/665686/

4. https://habr.com/ru/companies/vk/articles/546564/

5. https://habr.com/ru/companies/agima/articles/715206/

Безопасность HarmonyOS

Вообще, у Huawei есть подробная документация насчет технологий, применяемых в ОС для ее безопасности.

1. тут

2. тут

Поэтому об этом всем вкратце :)

Система построена на 3 RoT (Root of Trust): Boot RoT, Storage RoT, Computing RoT.

В самой ОС есть 5 уровней безопасности устройства SL1-SL5

SL1

Secure Boot

На каждом этапе загрузки устройства проверяются электронные подписи boot objects.

• Запуск устройства:

  ROM SoC Bootloader (на чипе ROM) (Root of Trust) -> Загрузка Flash Device Bootloader с flash storage chip (использует хеш публичного ключа из eFuse пространства главного чипа, чтобы проверить PK и потом использует этот PK, чтобы проверить signature of Flash Device Bootloader image) -> Далее FDB загружается и также проверяет PK и подпись следующего image.

• Обновление:

  Девайсы проверяют подписи пакетов обновлений. Дополнительно осуществлен контроль обновления: перед обновлением HarmonyOS отправляет информацию об идентификаторе устройства, номер версии и хеш обновления, и device upgrade token на сервер обновлений; сервер обновлений подписывает эту информацию и отправляет обратно и аутентифицирует процесс обновления.

SL2

Hardware Unique Key (HUK)

Встроен в hardware, используется как root key для распределения ключей. HUK можно использовать только через hardware cryptographic engine (нельзя через software).

Key Management (HUKS)

HarmonyOS Universal Keystore Service (HUKS) позволяет разработчикам управлять ключами, сертификатами, а также вызывать encryption/decryption алгоритмы.

!! Только приложения, которые генерируют ключи, могут обращаться к HUKS. Когда приложение генерирует ключ, HUKS записывает эти данные (UID, signature, package name of the application). Эта информация в дальнейшем используется для идентификации и аутентификации, когда приложение запрашивает ключ.

HarmonyOS может использовать другие функции auth’а (биометрия, пин-код), чтобы усилить контроль доступа к ключам.

HarmonyOS также реализует функцию проверку подлинности ключа на основе сертификата устройства.

Stack Protection

Стековые канарейки

Lightweight TEE

TrustZone

SL3

ASLR

Реализация "полной" и "стековой" рандомизации размещения адресного пространства. Также рандомизация базовых защищенных объектов.

На SL4 и SL5 ASLR для сегментов кода и кучи.

Data Execute Never (NX)

Реализация предотвращения выполнения данных как произвольного кода.

Privileged Acces Never (PAN) и Privileged eXecute Never (PXN)

Реализация предотвращения выполнения произвольного кода из user-space в kernel-space.

Hardware Encryption/Decryption Engine

Реализация криптографических алгоритмов

SL4

Control over Privileged Software Versions

Проверка подписей, используя ключи из eFuse, поэтому только коммерческие версии могут запускаться.

TEE

iTrustee — TrustedOS используется на устройствах с чипами Kirin.
Security services:

• Trusted storage service. Связь и изоляция Trusted Applications (TA). Состоит из secure file system (SFS) и replay protected memory block (RPMB). RPMB имеет anti-deletion, anti-rollback защиту.

• Encryption/decryption services. Использует много алгоритмов, а также независимые чипы для Key generation и вычислений; совместим с GlobalPlatform TEE standard.

• Trusted time service.

• Trusted User Interface.

Hierarchical Encryption of the File System

Шифрование файлов (осуществляется by kernel encryption file system module и hardware encryption/decryption engine) с помощью XTS-AES-256.
Два вида шифрования:

• Credential Encryption (CE), Sub Enhanced Credential Encryption (SECE) и Enhanced Credential Encryption (ECE). Используется с паролем разблокировки экрана

• Device Encryption (DE); не связано с паролем разблокировки экрана.

Стандартно используется первый вариант.

• CE Эти данные доступны, если после включения был введен пароль. Данные доступны даже если экран заблокирован. Например, SMS, контакты, информация о звонках и тд.

• SECE Усиление CE. Когда устройство заблокировано, файлы не могут быть открыты, но операции создания файлов и записи могут быть выполнены. Например, вложения электронной почты могут быть загружены.

• ECE Усиление SECE. Когда устройство заблокировано, файлы не доступны вовсе.

• DE Доступ к защищенным данным DE возможен при включении питания независимо от того, заблокировано ли устройство. Такие данные включают обои, будильники и мелодии звонка. Ключ DE защищен HUK и не имеет никакого отношения к паролю экрана блокировки.

В зависимости от уровня риска используются разные уровни. S4 — ECE, S3 — SECE, S2/S1 — CE/DE.

Control Flow Integrity (CFI)

Защита от ROP/JOP-атак.

Mandatory Acces Control (MAC)

Политики доступа к защищенным файлам. Также используется seccomp.

Kernel Integrity Protection*

• только определенные чипы HiSilicon поддерживают это

Технология защиты целостности ядра поддерживает следующие механизмы защиты:

• Фрагменты кода ядра и модуля драйвера не могут быть изменены.

• Данные ядра и модуля драйвера, доступные только для чтения, не могут быть изменены.

• Фрагменты кода, не относящиеся к ядру, не могут быть выполнены.

• Критические динамические данные ядра не могут быть изменены.

SL5

Secure Element (SE)

SE — это подсистема, которая обеспечивает высокозащищенную среду выполнения и хранения. Harmony поддерживает развертывание SE, которое используется для обеспечения безопасности основных сервисов и данных, таких как мобильные платежи и идентификационные данные. В отличие от TEE, решение SE обеспечивает как программную, так и аппаратную защиту благодаря высокому уровню безопасности конструкции и программных алгоритмов.

Independent Security Chip

Специальный чип безопасности, который реализует различные функции (защита паролем экрана блокировки, шифрование файлов, биометрия, управление ключами, RoT и т.д.).

Formal Verification + Microkernel

Формальная верификация проверяет корректность системы из исходников с помощью математических теорем.

TEE использует архитектуру микроядра чтобы уменьшить поверхность атаки, а также чтобы можно было легко масштабировать систему и повысить безопасность.

Physical Attack Defense

Специальные аппаратные методы, чтобы защититься от атак по сторонним каналам (side-channel) и атак, с внедрением ошибки (fault injection), в частности, для криптографических алгоритмов.

Например, умножение точек на эллиптической кривой, а также умножение по модулю в RSA защищены от атак SPA (simple power analysis), DPA (differential power analysis).
Симметрия тоже защищена: специальные механизмы для S-box.

Безопасность HMS Core

• FIDO

• Keyring

• Safety Detect

• DataSecurity Engine

• LocalAuthentication Engine

FIDO (Fast Identity Online)

Система для аутентификации с возможностями проекта FIDO2, основанными на стандарте WebAuthn и BioAuthn для авторизации по отпечатку пальца и лицу.

FIDO2:

• поддерживает платформонезависимые ключи, USB, NFC, Bluetooth;

• поддерживает платформозависимые ключи, отпечаток пальца, 3d слепок лица;

• использует проверку системы перед использованием FIDO2.

Keyring

Механизмы для управления учетными данными, позволяющее передавать их как локально между приложениями, так и между устройствами.

Safety Detect

Набор механизмов безопасности системы, включает в себя:

• SysIntegrity API — позволяет проверить безопасность устройства, на котором запущенно приложение (проверка наличия root прав).

• AppsCheck API — получает список вредоносных приложений.

• URLCheck API — определяет тип угрозы для конкретного URL адреса.

• UserDetect API — определяет, взаимодействует ли ваше приложение с истинным пользователем.

• WifiDetect API — определяет, является ли подключаемый Wi-Fi безопасным.

DataSecurity Engine

Secure Asset Storage

Позволяет безопасно хранить, обновлять, удалять, запрашивать персональные данные.
Использует TEE для хранения ключей, шифрования и расшифровки данных.

Classified File Protection

Позволяет классифицировать и маркировать данные, а также настроить права относительно политики рисков от S0 до S4.

Основываясь на стандартах классификации данных, вы можете установить политики управления безопасностью жизненного цикла и требования к защите данных, которые будут соблюдаться службами в конкретных сценариях использо—вания.

Политики рисков:

S4 — Severe — должен включать наиболее чувствительные персональные данные или данные которые в случае утечки могут оказать очень негативное влияние — информация о здоровье, кредитной карте.
S3 — High — данные которые в случае утечки могут оказать негативное влияние для конкретного человека или организации — персональная информация о точном местоположении в режиме реального времени и маршруты тренировок.
S2 — Medium — данные которые в случае утечки могут оказать существенное влияние для конкретного человека или организации — подробные личные адреса, имена.
S1 — Low, данные которые в случае утечки могут оказать ограниченное влияние для конкретного человека или организации — национальность, место рождения и информация об образовании.
S0 — Public — данные которые можно найти публично.

LocalAuthentication Engine

Facial Recognition

Предоставляет метод локальной идентификации и верификации личности человека с использованием его профиля лица.

DevEco Studio

Аналог Android Studio от Huawei

Эмуляторы

Эмулятор можно использовать только с версии 3.1. Для обновления требуется поменять регион на CN следующим образом:

win:

C:\Users\username\AppData\Roaming\Huawei\DevEcoStudio3.0\options directory, open the country.region.xml.

MacOS:
~/Library/Application Support/Huawei/DevEcoStudio3.0/options/country.region.xml

Для Linux нет версии DevEco :(

В версии 3.1 можно создать 3 вида виртуальных устройств:

• телефон, APIv6, HarmonyOS

• носимые устройства, APIv6, HarmonyOS

• телевизор, APIv6, HarmonyOS

Эти же категории устройств доступны как удаленные устройства (эмуляторы) для тестирования своих приложений.

Также можно запустить удаленный эмулятор — тогда добавляются планшеты и машины.

Версия qemu, которая используется эмулятором, сильно ограничена по функциональности, по сравнению с версией для Android Studio.

Аудит приложений для HarmonyOS

Root-права

После 2020-го года Huawei полностью запретила разблокировку загрузчика. Соответственно, простого получения root-прав на текущий момент нет, кроме публичных эксплоитов, позволяющих разблокировать загрузчик. Да и то доступно это только под очень ограниченный ряд устройств с определенными чипами.

На эмуляторе в DevEco Studio, предоставляемой Huawei, нет возможности получить root-права.

Таким образом, использовать полноценно устройство на HarmonyOS для аудита мобильных приложений на текущий момент практически невозможно.

Сейчас самый удобный способ — использовать устройство с уже полученными root-правами и установка на них HMS.

Нативные приложения для HarmonyOS

Такие приложения не встречаются под мобильную версию HarmonyOS на нашем рынке. Большинство разработчиков предпочитают разрабатывать сразу приложение под Android и HarmonyOS в варианте apk, использующие разный набор базовых сервисов (это было описано ранее).

Tools

Специально созданных инструментов для анализа приложений под HarmonyOS не было найдено. Стандартные тулзы для Android-приложений могут быть использованы для анализа HarmonyOS-приложений.

Порядок анализа мобильных приложений для HarmonyOS

В связи с невозможностью получить root-права на устройстве и эмуляторе для удобного анализа приложений предлагается использовать следующую схему:

1. Берем любой Android-телефон с разблокированным загрузчиком

2. Устанавливаем форк от AOSP без GMS

3. Устанавливаем HMS core

4. Устанавливаем исследуемое приложение

5. Исследуем как обычно :)

В данной статье мы познакомились с третьим игроком на рынке мобильных ОС. Рассмотрели архитектуру HarmonyOS, замену GMS в виде HMS. Исследовали как аппаратные, так и программные средства защиты ОС. Сейчас нативные приложения не распространены на нашем рынке, доля Harmony слишком мала.

На данный момент мало возможностей исследовать саму HarmonyOS и приложения для нее из-за ее закрытости. Поэтому пора искать новые дыры безопасности хД