Защитник Windows System Guard: как аппаратный корень доверия помогает защитить Windows
Для защиты критически важных ресурсов, таких как стек проверка подлинности Windows, маркеры единого входа, биометрический стек Windows Hello и виртуальный доверенный платформенный модуль, встроенное ПО и оборудование системы должны быть надежными.
Защитник Windows System Guard реорганизует существующие функции целостности системы Windows под одной крышей и создает следующий набор инвестиций в безопасность Windows. Он предназначен для обеспечения следующих гарантий безопасности:
- Защита и поддержание целостности системы при запуске
- Убедитесь, что целостность системы действительно поддерживается с помощью локальной и удаленной аттестации
Поддержание целостности системы при запуске
Статический корень доверия для измерения (SRTM)
В Windows 7 одним из средств, которые злоумышленники будут использовать для сохранения и уклонения от обнаружения, было установить в системе то, что часто называют bootkit или rootkit. Эта вредоносная программа запускается до запуска Windows или во время самого процесса загрузки, что позволяет ему запускаться с наивысшим уровнем привилегий.
При использовании Windows 10, работающих на современном оборудовании, аппаратный корень доверия помогает гарантировать, что несанкционированное встроенное ПО или программное обеспечение (например, загрузчик) не может запуститься перед загрузчиком Windows. Этот аппаратный корень доверия поступает из функции безопасной загрузки устройства, которая является частью единого расширяемого интерфейса встроенного ПО (UEFI). Этот метод измерения статических компонентов UEFI при ранней загрузке называется статическим корнем доверия для измерения (SRTM).
Поскольку существуют тысячи поставщиков КОМПЬЮТЕРов, которые производят множество моделей с различными версиями UEFI BIOS, при загрузке становится невероятно большое количество измерений SRTM. Для установления доверия здесь существуют два метода: ведение списка известных «плохих» измерений SRTM (также известного как список блокировок) или список известных «хороших» измерений SRTM (также известный как список разрешений).
У каждого варианта есть недостаток:
- Список известных «плохих» измерений SRTM позволяет хакеру изменить только 1 бит в компоненте, чтобы создать совершенно новый хэш SRTM, который должен быть указан в списке. Это означает, что поток SRTM по своей сути является хрупким — незначительное изменение может привести к аннулированию всей цепочки доверия.
- Список известных «хороших» измерений SRTM требует тщательного добавления каждого нового комбинированного измерения BIOS/PC, что происходит медленно. Кроме того, исправление ошибок для кода UEFI может занять много времени для разработки, сборки, повторного тестирования, проверки и повторного развертывания.
Безопасный запуск — динамический корень доверия для измерения (DRTM)
Защитник Windows System Guard Secure Launch, впервые появившись в Windows 10 версии 1809, призван устранить эти проблемы, используя технологию, известную как динамический корень доверия для измерения (DRTM). DRTM позволяет системе свободно загружаться в ненадежный код, но вскоре после запуска системы в доверенное состояние, принимая под контроль все ЦП и заставляя их сбой хорошо известного и измеряемого пути кода. Это позволяет ненадежный ранний код UEFI загружать систему, но затем безопасно переходить в доверенное и измеряемое состояние.
Безопасный запуск упрощает управление измерениями SRTM, так как код запуска теперь не связан с определенной конфигурацией оборудования. Это означает, что количество допустимых измерений кода невелико, и будущие обновления могут развертываться более широко и быстро.
Защита в режиме управления системой (СММ)
Режим управления системой (СММ) — это специальный режим ЦП в микроконтроллерах x86, который обрабатывает управление питанием, конфигурацию оборудования, тепловой мониторинг и все остальное, что производитель считает полезным. При запросе одной из этих системных операций во время выполнения вызывается немаскируемое прерывание (SMI), которое выполняет код SMM, установленный BIOS. Код СММ выполняется на самом высоком уровне привилегий и невидим для ОС, что делает его привлекательным объектом для вредоносных действий. Даже если System Guard Secure Launch используется для позднего запуска, код СММ может потенциально получить доступ к памяти гипервизора и изменить гипервизор.
Для защиты от этого используются два метода:
- Защита от разбиения на разбиение для предотвращения неуместного доступа к коду и данным
- Контроль и аттестация оборудования СММ
Защита от разбиения по страницам может быть реализована для блокировки определенных таблиц кода, которые должны быть доступны только для чтения, чтобы предотвратить незаконное изменение. Это предотвращает доступ к памяти, которая не была назначена.
Функция аппаратного процессора, известная как обработчик SMI руководителя, может отслеживать СММ и убедиться, что она не обращается к какой-либо части адресного пространства, в которую он не должен.
Защита СММ основана на технологии Secure Launch и требует, чтобы она функционировала. В будущем Windows 10 также будет измерять поведение обработчика SMI и удостоверять, что память, принадлежащей ОС, не была изменена.
Проверка целостности платформы после запуска Windows (время выполнения)
Хотя Защитник Windows System Guard обеспечивает расширенную защиту, которая поможет защитить и сохранить целостность платформы во время загрузки и во время выполнения, реальность такова, что мы должны применить менталитет «предполагать нарушение» даже к нашим самым сложным технологиям безопасности. Мы можем верить, что технологии успешно выполняют свою работу, но нам также нужна способность убедиться, что они были успешными в достижении своих целей. Для обеспечения целостности платформы мы не можем просто доверять платформе, которая потенциально может быть скомпрометирована, чтобы подтвердить состояние ее безопасности. Таким образом, Защитник Windows System Guard включает ряд технологий, позволяющих удаленно анализировать целостность устройства.
При загрузке Windows Защитник Windows System Guard с помощью доверенного платформенного модуля 2.0 устройства (TPM 2.0) выполняется ряд измерений целостности. System Guard Secure Launch не поддерживает более ранние версии доверенного платформенного модуля, например TPM 1.2. Этот процесс и данные изолированы аппаратно от Windows, чтобы гарантировать, что данные измерений не подвержены типу незаконного изменения, которое может произойти в случае компрометации платформы. Здесь измерения можно использовать для определения целостности встроенного ПО устройства, состояния конфигурации оборудования и компонентов, связанных с загрузкой Windows.
После загрузки системы Защитник Windows System Guard подписывает и запечатывает эти измерения с помощью доверенного платформенного модуля. По запросу система управления, например Intune или Microsoft Configuration Manager, может получить их для удаленного анализа. Если Защитник Windows System Guard указывает на отсутствие целостности устройства, система управления может выполнить ряд действий, например запретить устройству доступ к ресурсам.
Требования к выпуску и лицензированию Windows
В следующей таблице перечислены выпуски Windows, поддерживающие Защитник Windows System Guard:
| Windows Pro | Windows Корпоративная | Windows Pro для образовательных учреждений/SE | Windows для образовательных учреждений |
|---|---|---|---|
| Да | Да | Да | Да |
Защитник Windows System Guard лицензии предоставляются следующими лицензиями:
| Windows Pro/Pro для образовательных учреждений/SE | Windows Корпоративная E3 | Windows Корпоративная E5 | Windows для образовательных учреждений A3 | Windows для образовательных учреждений A5 |
|---|---|---|---|---|
| Да | Да | Да | Да | Да |
Дополнительные сведения о лицензировании Windows см. в статье Обзор лицензирования Windows.
Требования к системе для System Guard
Эта функция доступна для следующих процессоров:
- Процессоры Intel® vPro™, начиная с Intel® Coffeelake, Whiskeylake или более поздней версии
- Процессоры AMD®, начиная с кремния Zen2 или более поздней версии
- Процессоры Qualcomm с набором® микросхем SD850 или более поздней версии
Требования к процессорам Intel® vPro™, начиная с Intel® Coffeelake, Whiskeylake или более поздней версии
- Именно стиль «TXT PS2» Атрибуты при создании следующим образом:
- AuthWrite
- PolicyDelete
- Запись заблокирована
- WriteDefine
- AuthRead
- WriteDefine
- Нода
- Написано
- ПлатформаСоздать
- A = TPM2_PolicyLocality (Locality 3 & Locality 4)
- B = TPM2_PolicyCommandCode (TPM_CC_NV_UndefineSpecial)
- authPolicy = OR >
- дайджест authPolicy = 0xef, 0x9a, 0x26, 0xfc, 0x22, 0xd1, 0xae, 0x8c, 0xec, 0xff, 0x59, 0xe9, 0x48, 0x1a, 0xc1, 0xec, 0x53, 0x3d, 0xbe, 0x22, 0x8b, 0xec, 0x6d, 0x17, 0x93, 0x0f, 0x4c, 0xb2, 0xcc, 0x5b, 0x97, 0x24
- Дескриптор: 0x01C101C0
- Атрибуты:
- TPMA_NV_POLICYWRITE
- TPMA_NV_PPREAD
- TPMA_NV_OWNERREAD
- TPMA_NV_AUTHREAD
- TPMA_NV_POLICYREAD
- TPMA_NV_NO_DA
- TPMA_NV_PLATFORMCREATE
- TPMA_NV_POLICY_DELETE
- A = TPM2_PolicyAuthorize(MSFT_DRTM_AUTH_BLOB_SigningKey)
- B = TPM2_PolicyCommandCode(TPM_CC_NV_UndefineSpaceSpecial)
- authPolicy = OR >
- Дайджест-значение 0xcb, 0x45, 0xc8, 0x1f, 0xf3, 0x4b, 0xcf, 0x0a, 0xfb, 0x9e 0x1a, 0x80, 0x29, 0xfa, 0x23, 0x1c, 0x87, 0x27, 0x30, 0x3c, 0x09, 0x22, 0xdc, 0xce, 0x68, 0x4b, 0xe3, 0xdb, 0x81, 0x7c, 0x20, 0xe1
- Intel® SINIT ACM должна быть перенесена в BIOS OEM
- Платформы должны поставляться с рабочим ACM, подписанным правильным рабочим подписывателем Intel® ACM для платформы.
Требования к процессорам AMD®, начиная с Zen2 или более поздней версии
- Дескриптор: 0x01C101C0
- Атрибуты:
- TPMA_NV_POLICYWRITE
- TPMA_NV_PPREAD
- TPMA_NV_OWNERREAD
- TPMA_NV_AUTHREAD
- TPMA_NV_POLICYREAD
- TPMA_NV_NO_DA
- TPMA_NV_PLATFORMCREATE
- TPMA_NV_POLICY_DELETE
- A = TPM2_PolicyAuthorize(MSFT_DRTM_AUTH_BLOB_SigningKey)
- B = TPM2_PolicyCommandCode(TPM_CC_NV_UndefineSpaceSpecial)
- authPolicy = OR >
- Дайджест-значение 0xcb, 0x45, 0xc8, 0x1f, 0xf3, 0x4b, 0xcf, 0x0a, 0xfb, 0x9e 0x1a, 0x80, 0x29, 0xfa, 0x23, 0x1c, 0x87, 0x27, 0x30, 0x3c, 0x09, 0x22, 0xdc, 0xce, 0x68, 0x4b, 0xe3, 0xdb, 0x81, 0x7c, 0x20, 0xe1
- Платформы AMD® Secure Launch должны поставляться с предоставленным devnode драйвера AMD® DRTM и установленным драйвером AMD® DRTM.
Требования к процессорам Qualcomm с наборами® микросхем SD850 или более поздней версии
- НЕ содержат никаких сопоставлений с EfiConventionalMemory (например, нет памяти, принадлежащей ОС или VMM).
- Они не должны иметь разрешения на выполнение и запись для одной и той же страницы.
- Платформы должны разрешать только страницы в режиме мониторинга, помеченные как исполняемые файлы
- Карта памяти должна сообщать о режиме монитора как EfiReservedMemoryType.
- Платформы должны обеспечить механизм защиты таблиц страниц режима монитора от изменения
Обратная связь
Были ли сведения на этой странице полезными?
Root of trust что это
Корень доверия (Root-of-Trust, RoT) — это надёжный источник или компонент, который обеспечивает безопасное исполнение кода и хранение критических данных в системе. Он служит основой для построения иерархии доверия в системах информационной безопасности.
Так, например, при запуске компьютера или мобильного устройства первый загружаемый код (обычно это прошивка или загрузчик) должен быть надежным, так как он определяет, каким образом будут загружены и выполнены все последующие компоненты системы. Если этот первый код скомпрометирован, то вся система может быть под угрозой. Корень доверия обеспечивает загрузку и выполнение только доверенного кода.
В реализации RoT часто используют аппаратные средства (например, защищенные аппаратные модули, или HSM) или специализированные чипы (например, TPM), которые обеспечивают хранение ключей шифрования, генерацию криптографических подписей и другие функции безопасности.
Trusts
В данной статье рассмотрено доверительное управление между двумя доменами Active Directory: как Samba обрабатывает доверительные отношения (трасты), какие бывают трасты и виды трастов, которые вы можете создать. Рассмотрен пример создания двух доменов, каждый со своим пространством имен. С помощью bind9 будет настроен DNS-прокси для управления разрешением имен SRV-записей между этими двумя доменами. После создания трастов расссмотрим как управлять пользователями и группами между этими доменами.
Основные определения
Прежде чем начинать создавать траст, мы начнем с некоторых основ. Давайте сначала поговорим о некоторых общих определениях.
Доверяющий домен
В доверяющем домене A вы можете получить доступ к пользователям и группам из доверенного домена Б. Пользователи и доменные группы из домена Б могут использоваться администратором домена A для предоставления этим пользователям и группам разрешений на доступ к ресурсам в домене А. Если доверие является односторонним, администратор домена A должен пройти проверку подлинности со своими учётными данными в домене Б. Это означает, что администратор домена Б должен настроить учётную запись для администратора из домена А. Эта учётная запись будет использоваться администратором из домена A для аутентификации в домене Б, чтобы получить доступ к пользователи и группам из домена Б.
Доверенный домен
Пользователи и доменные группы из доверенного домена Б могут использоваться доверяющим доменом А. Пользователи домена Б не увидят ни одного пользователя из домена A, если доверие является односторонним. Пользователи из домена A не смогут получить доступ к каким-либо ресурсам из домена Б.
Одностороннее доверие
Одностороннее доверие устанавливается только в одном направлении от домена A к домену Б или наоборот. Если домен A доверяет домену Б, то домен Б будет не доверять домену A.
Двустороннее доверие
Если установлено двустороннее доверие в обоих направлениях, то все доменные пользователи и группы из любого домена будут иметь возможность доступа к ресурсам из другого домена. Двустороннее доверие — это доверие по умолчанию в Active Directory.
Переходное (транзитивное) доверие
Если у вас более двух доменов, или Active Directory-дерево, или Active Directory-лес и для проверки подлинности используется Kerberos, вы можете установить транзитивное доверие. Преимущество транзитивного доверия состоит в том, что Kerberos управляет аутентификацией между трастами. Все клиенты из домена A всегда будут отправлять запрос на аутентификаци к собственному контроллеру домена (который всегда является сервером Kerberos), после чего контроллер домена будет управлять билетами. Если теперь пользователь из домена A получит доступ к общему ресурсу на файловом сервере в домене Б, пользователь получит билет от своего собственного контроллера домена для домена Б. Файловый сервер в домене Б проверит билет на своем собственном Kerberos-сервере в домен Б. Таким образом, клиенты с обеих сторон ничего не знают о доверии. В инфраструктуре Active Directory у вас всегда будет транзитивное двустороннее доверие, поэтому все домены будут доверять друг другу.
Виды трастов
Здесь рассмотрены доверительные отношения, о которых Microsoft упоминает в своей документации, но это не означает, что Samba поддерживает все эти виды трастов. Ниже рассмотрены трасты, которые Samba поддерживает в настоящее время, и о том, какие ограничения у Samba все еще есть.
Траст (доверие) между доменами
Если есть одно дерево доменов с доменом верхнего уровня, который обрабатывает основное пространство имён (например, example.net). Тогда все домены будут использовать поддомен из домена верхнего уровня. В примере под доменом верхнего уровня есть еще два домена: dom1.example.net и dom2.example.net. В этом случае все три домена будут доверять друг другу в обоих направлениях. Это называется трастом домена.
Внешние трасты (External trust)
Внешнее доверие впервые было введено в Windows-NT. Внешнее доверие — это доверие между двумя доменами, каждый со своим собственным пространством имен. Во внешнем доверии Kerberos не используется, поэтому единый вход (single-sign-on) невозможен. Можно установить внешнее доверие между двумя доменами в стиле NT или между доменом в стиле NT и доменом Active Directory. Пример внешнего доверия:
Доверие в лесу доменов (Forest trust)
Если у вас есть два активных дерева каталогов с разными пространствами имен, например, example.net и example.com, вы можете настроить доверительные отношения между двумя доменами верхнего уровня ваших деревьев, тогда все домены обоих деревьев будут доверять друг другу. Вам не нужно настраивать доверие между каждым доменом двух деревьев, доверие будет управляться через домены верхнего уровня. На рисунке ниже показано доверие леса. Доверие осуществляется на верхнем уровне, все остальные доверительные отношения будут установлены автоматически. Для доверия леса нужен Kerberos, для обработки всех проверок подлинности между всеми доменами.
Самба и трасты
Как упоминалось ранее, не всё, что объясняет Microsoft, возможно в Samba. Итак, самый важный вопрос: что уже поддерживается?
- Доверие в лесу доменов — как двустороннее доверие так и транзитивное доверие. Это доверие может быть установленным между двумя Samba-доменами или Samba-доменом и Windows-доменом.
- Внешние доверительные отношения между доменом AD и доменом в стиле NT.
- Добавление пользователей и групп доверенного домена в группы доверяющего домена. Но при этом необходимо использовать SID пользователей и групп, чтобы добавить их в свою группу (имя пользователя или имя группы использовать невозможно).
- В RSAT вы увидите foreignSecurityPrincipal для всех добавленных пользователей и групп из доверенного домена. Таким образом Microsoft показывает, что пользователь или группа являются частью доверенного домена.
Некоторые вещи по-прежнему невозможны, если вы хотите использовать доверительные отношения в Samba:
- Доверительные отношения между доменами в одном дереве с одним и тем же пространством имён верхнего уровня.
- Фильтрация SID для ограничения разрешений.
- Обе стороны траста должны полностью доверять друг другу. Это означает, что администратор из домена A может управлять всеми объектами в домене Б и наоборот.
- Выборочная аутентификация в настоящий момент не поддерживается. Возможно создание таких доверий, но KDC и winbindd всё равно будут их игнорировать.
Окружение
Поскольку основной интерес в этом руководстве представляет представляет настройка доверия и управление пользователями и группами, настройка Linux-машин не рассмотрена. В примере используется: четыре Linux-машины и одна Windows-машина:
Два контроллера домена Samba Два контроллера домена, из которых имеет свое пространство имен. Домены используют внутренний DNS-сервер. Один Samba-Linux-клиент Этот клиент будет членом одного из доменов для проверки входа в систему и настройки разрешения доступа. Одна Linux-система в качестве DNS-прокси Чтобы настроить DNS-прокси для разрешения SRV-записей между двумя доменами будет использоваться bind9. Один Windows-клиент Эта Windows-система будет членом одного из доменов для проверки входа в систему.
Далее в таблице указаны параметры которые используются в примере.
Информация о двух доменах
Параметр Домен 1 Домен 2 DNS-суффикс s1.example.net s2.example.net Realm S1.EXAMPLE.NET S2.EXAMPLE.NET Имя NetBios S1 S2 IP-адрес 192.168.56.41 192.168.56.42 DNS-search s1.example.net s2.example.net Настройка DNS-прокси
Одна из самых важных вещей, которую нужно сделать, прежде чем приступить к настройке доверия, — это настроить разрешение имён между двумя доменами. Недостаточно поместить контроллеры домена во все /etc/hosts всех других контроллеров домена, поскольку также должна быть возможность разрешать SRV-записи со всех доменов и всех контроллеров домена. По этой причине самый простой способ заставить работать разрешение имен — настроить DNS-прокси между двумя доменами. DNS-прокси будет перенаправлять запрос между доменами и внешним DNS-серверами для разрешения любого другого имени хоста.
Для DNS-прокси используется bind9 на одной из Linux-машин. Пакеты, которые вам нужны уже установлены и настроены в системе с IP-адресом 192.168.56.50. Для настройки DNS-прокси нужно отредактировать файл /etc/bind/named.conf.option :
forwarders 1.1.1.1; >; forward only; dnssec-validation no; dnssec-enable no; allow-recursion < any; >;Затем необходимо настроить переадресацию зон в файле /etc/bind/named.conf.local :
zone "s1.example.net" in type forward; forwarders < 192.168.56.41; >; >; zone "s2.example.com" in type forward; forwarders < 192.168.56.42; >; >;В файлах /etc/samba/smb.conf на обоих контроллерах доменов можно увидеть,что DNS-прокси является сервером пересылки для обоих контроллеров домена.
Теперь можно проверить, могут ли разрешаться SRV-записи на обоих контроллерах домена:
vagrant@addc-01:~$ host -t srv _kerberos._tcp.s1.example.net _kerberos._tcp.s1.example.net has SRV record 0 100 88 addc-01.s1.example.net. vagrant@addc-01:~$ host -t srv _kerberos._tcp.s2.example.com _kerberos._tcp.s2.example.com has SRV record 0 100 88 addc-02.s2.example.com. vagrant@addc-02:~$ host -t srv _kerberos._tcp.s1.example.net _kerberos._tcp.s1.example.net has SRV record 0 100 88 addc-01.s1.example.net. vagrant@addc-02:~$ host -t srv _kerberos._tcp.s2.example.com _kerberos._tcp.s2.example.com has SRV record 0 100 88 addc-02.s2.example.com.
Следующая проверка, которую следует сделать — попытаться получить Kerberos-билет из любого домена:
vagrant@addc-02:~$ kinit administrator@S2.EXAMPLE.COM administrator@S2.EXAMPLE.COM’s Password: vagrant@addc-02:~$ klist Credentials cache: FILE:/tmp/krb5cc_1000 Principal: administrator@S2.EXAMPLE.COM Issued Expires Principal Jan 2 18:19:28 2019 Jan 3 04:19:28 2019 krbtgt/S2.EXAMPLE.COM@S2.EXAMPLE.COM vagrant@addc-02:~$ kinit administrator@S1.EXAMPLE.NET administrator@S1.EXAMPLE.NET’s Password: vagrant@addc-02:~$ klist Credentials cache: FILE:/tmp/krb5cc_1000 Principal: administrator@S1.EXAMPLE.NET Issued Expires Principal Jan 2 18:20:00 2019 Jan 3 04:20:00 2019 krbtgt/S1.EXAMPLE.NET@S1.EXAMPLE.NET
Внимание! realm необходимо указывать заглавными буквами
Проверку можно выполнить с обоих контроллеров домена в обоих доменах. После этих проверок можно быть уверенным, что DNS-прокси запущен.
Создание траста
Теперь,после выполнения всех подготовок и тестов, можно приступить к настройке доверия с samba-tool . Доверие можно настроить с любого контроллера домена в любом из доменов. В примере команда выполняется на контроллера домена addc-01.s1.example.net:
# samba-tool domain trust create s2 --type=forest --direction=both --create-location=both -U administrator@S2.EXAMPLE.COM LocalDomain Netbios[S1] DNS[s1.example.net] SID[S-1-5-21-3126357314-3577825812-2501707040] RemoteDC Netbios[ADDC-02] DNS[addc-02.s2.example.com] ServerType[PDC,GC,LDAP,DS,KDC,TIMESERV,CLOSEST,WRITABLE,\ GOOD_TIMESERV,FULL_SECRET_DOMAIN_6] Password for [administrator@S2.EXAMPLE.COM]: RemoteDomain Netbios[S2] DNS[s2.example.com] SID[S-1-5-21-2406301074-2875553281-1464783146] Creating remote TDO. Remote TDO created. Setting supported encryption types on remote TDO. Creating local TDO. Local TDO created Setting supported encryption types on local TDO. Setup local forest trust information. Namespaces[2] TDO[s2.example.com]: TLN: Status[Enabled] DNS[*.s2.example.com] DOM: Status[Enabled] DNS[s2.example.com] Netbios[S2] SID[S-1-5-21-2406301074-2875553281-1464783146] Setup remote forest trust information. Namespaces[2] TDO[s1.example.net]: TLN: Status[Enabled] DNS[*.s1.example.net] DOM: Status[Enabled] DNS[s1.example.net] Netbios[S1] SID[S-1-5-21-3126357314-3577825812-2501707040] Validating outgoing trust. OK: LocalValidation: DC[\\addc-02.s2.example.com] CONNECTION[WERR_OK] TRUST[WERR_OK] VERIFY_STATUS_RETURNED Validating incoming trust. OK: RemoteValidation: DC[\\addc-01.s1.example.net] CONNECTION[WERR_OK] TRUST[WERR_OK] VERIFY_STATUS_RETURNED Success.
Не забудьте использовать заглавные буквы при указании realm в имени администратора из домена s2.
В данном примере мы создали траст в лесу доменов. Помните, что такое доверие всегда двунаправленное и транзитивное.
Проверка доверия
Первым тестом будет проверка доверия между двумя доменами (команда выполняется на контроллера домена addc-01.s1.example.net):
# samba-tool domain trust show s2 LocalDomain Netbios[S1] DNS[s1.example.net] SID[S-1-5-21-3126357314-3577825812-2501707040] TrustedDomain: NetbiosName: S2 DnsName: s2.example.com SID: S-1-5-21-2406301074-2875553281-1464783146 Type: 0x2 (UPLEVEL) Direction: 0x3 (BOTH) Attributes: 0x8 (FOREST_TRANSITIVE) PosixOffset: 0x00000000 (0) kerb_EncTypes: 0x18 (AES128_CTS_HMAC_SHA1_96,AES256_CTS_HMAC_SHA1_96) Namespaces[2] TDO[s2.example.com]: TLN: Status[Enabled] DNS[*.s2.example.com] DOM: Status[Enabled] DNS[s2.example.com] Netbios[S2] \ SID[S-1-5-21-2406301074-2875553281-1464783146]
Повторите тест с другого контроллера домена, результат должен быть таким же.
Поскольку у вас может быть более одного доверия, следующий тест покажет список всех доверительных отношений от или к вашему домену (команда выполняется на контроллера домена addc-01.s1.example.net):
# samba-tool domain trust list Type[Forest] Transitive[Yes] Direction[BOTH] Name[s2.example.com]
В разных доменах вы можете получить разные результаты. Результат зависит от типа доверия, который установлен с этим доменом.
Если после настройки доверия у вас возникли проблемы с доступом пользователей из доверенного домена в ваш домен, следует проверить, действительно ли установлен траст. В листинге 7.4 вы можете увидеть тест для проверки того, действует ли доверие:
В разных доменах могут быть разные результаты. Результат зависит от типа траста который установлен с этим доменом. Если у вас после настройки траста возникли проблемы с доступом пользователей из трастового домен в свой домен, тогда вы должны проверить, действительно ли установлен траст. Проверка траста (команда выполняется на контроллера домена addc-01.s1.example.net):
# samba-tool domain trust validate s2 -Uadministrator@S2.EXAMPLE.COM LocalDomain Netbios[S1] DNS[s1.example.net] SID[S-1-5-21-3126357314-3577825812-2501707040] LocalTDO Netbios[S2] DNS[s2.example.com] SID[S-1-5-21-2406301074-2875553281-1464783146] OK: LocalValidation: DC[\\addc-02.s2.example.com] CONNECTION[WERR_OK] \ TRUST[WERR_OK] VERIFY_STATUS_RETURNED OK: LocalRediscover: DC[\\addc-02.s2.example.com] CONNECTION[WERR_OK] RemoteDC Netbios[ADDC-02] DNS[addc-02.s2.example.com] ServerType[PDC,GC,\ LDAP,DS,KDC,TIMESERV,CLOSEST,WRITABLE,\ GOOD_TIMESERV,FULL_SECRET_DOMAIN_6] Password for [administrator@S2.EXAMPLE.COM]: OK: RemoteValidation: DC[\\addc-01.s1.example.net] CONNECTION[WERR_OK] TRUST[WERR_OK] VERIFY_STATUS_RETURNED OK: RemoteRediscover: DC[\\addc-01.s1.example.net] CONNECTION[WERR_OK]
Этот тест можно выполнить с любого контроллера домена в обоих доменах.
Управление пользователями и группами
Теперь можно назначать пользователей и группы из доверяющего домена в группу доверенного домена. Так как у нас настроено двустороннее доверие, можно назначать пользователей и группы в обоих направлениях.
Прежде чем мы сможем назначать пользователей и группы, необходимо создать несколько пользователей и групп в обоих доменах. Просто создайте несколько пользователей и групп с samba-tool .
Список пользователей и групп
Список пользователей и групп из обоих доменов нельзя получить с помощью команды wbinfo , можно получить список пользователей и групп только из своего домена:
root@addc-02:# wbinfo -u --domain=s2 S2\administrator S2\guest S2\krbtgt S2\user1 S2\user2 S2\user3 S2\user4 root@addc-02:# wbinfo -u —domain=s1 root@addc-02:# wbinfo -g --domain=s2 S2\cert publishers S2\ras and ias servers S2\allowed rodc password replication group S2\denied rodc password replication group S2\dnsadmins S2\enterprise read-only domain controllers S2\domain admins S2\domain users S2\domain guests S2\domain computers S2\domain controllers S2\schema admins S2\enterprise admins S2\group policy creator owners S2\read-only domain controllers S2\dnsupdateproxy S2\dom2-g1 S2\dom2-g2 root@addc-02:# wbinfo -g —domain=s1
Причина в том, что, возможно, вы не увидите всех пользователей и группы из доверяющего домена, из-за некоторых настроек безопасности (особенно если доверяющий домен — это Windows-домен), поэтому в актуальной Samba-версии команда была отключена для контроллера домена. Чтобы увидеть всех пользователей, можно выполнить LDAP-запрос с помощью samba-tool :
root@addc-02:# samba-tool user list -H ldap://addc-01 \ -U administrator@S1.EXAMPLE.NET Password for [administrator@S1.EXAMPLE.NET]: Guest hhirsch ktom Administrator krbtgt adent ptau root@addc-02:# samba-tool user list -H ldap://addc-02 \ -U administrator@S2.EXAMPLE.COM Password for [administrator@S2.EXAMPLE.COM]: user1 user2 Guest user4 Administrator user3 krbtgt
Здесь вы можете видеть, что все еще можно увидеть всех пользователей и группы из обоих доменов.
Использование wbinfo
После того, как вы смогли получить список всех пользователей из обоих доменов, вам нужно найти SID пользователя или группы, и добавить SID в качестве члена к вашей группе. Первым шагом является получение дополнительной информации от ваших доменов с помощью wbinfo :
root@addc-02:# wbinfo --all-domains BUILTIN S2 S1 root@addc-02:# wbinfo --own-domain S2 root@addc-02:# wbinfo --trusted-domains BUILTIN S2 S1 root@addc-02:# wbinfo --online-status BUILTIN : active connection S2 : active connection S1 : active connection
Теперь можно получить SID пользователей и групп:
root@addc-02:# wbinfo -n s1\\ktom S-1-5-21-3126357314-3577825812-2501707040-1104 SID_USER (1) root@addc-02:# wbinfo -n s2\\user1 S-1-5-21-2406301074-2875553281-1464783146-1104 SID_USER (1) root@addc-02:# wbinfo -n s1\\dom1-g1 S-1-5-21-3126357314-3577825812-2501707040-1108 SID_DOM_GROUP (2) root@addc-02:# wbinfo -n s2\\dom2-g1 S-1-5-21-2406301074-2875553281-1464783146-1108 SID_DOM_GROUP (2) root@addc-02:# wbinfo -i s1\\hhirsch S1\hhirsch:*:3000018:3000019::/home/S1/hhirsch:/bin/false root@addc-02:# wbinfo -i s2\\user2 S2\user2:*:3000020:100::/home/S2/user2:/bin/false
Таким образом вы получили всю информацию обо всех пользователях из обоих доменов.
Тестирование аутентификации
С помощью команды wbinfo можно протестировать процесс аутентификации разных пользователей из обоих доменов.
Вы увидите два типа аутентификации. Первым тестом будет аутентификация по паролю с открытым текстом. Этот тип аутентификации всегда имеет место, когда пользователь входит в систему локально (открытый текст не означает, что пароль будет отправлен без шифрования, это просто название процесса входа в систему). Второй тип — аутентификация по паролю запрос/ответ. Этот тип аутентификации использует NTLM или Kerberos. Тестирование обоих процессов аутентификации:
root@addc-02:# wbinfo -a s1\\hhirsch Enter s1\hhirsch’s password: plaintext password authentication succeeded Enter s1\hhirsch’s password: challenge/response password authentication succeeded root@addc-02:# wbinfo -a s2\\user1 Enter s2\user1’s password: plaintext password authentication succeeded Enter s2\user1’s password: challenge/response password authentication succeeded
Также можно проверить, какие контроллеры домена отвечают за аутентификацию:
root@addc-02:# wbinfo --ping-dc checking the NETLOGON for domain[S2] dc connection to "addc-02.s2.example.com" \ succeeded root@addc-02:# wbinfo --ping-dc --domain=s1 checking the NETLOGON for domain[s1] dc connection to "addc-01.s1.example.net" \ succeeded
Назначение пользователя и групп
Теперь вы достигли точки, когда вы можете назначать пользователей и группы из доверенных доменов в любую из групп доверяющего домена. Как я уже упоминал ранее, вы не можете назначить пользователей и групп используя имя, вы должны использовать SID. В примере 8.1.3 показаны все шаги:
root@addc-02:# wbinfo -n s1\\ktom S-1-5-21-3126357314-3577825812-2501707040-1104 SID_USER (1) root@addc-02:# samba-tool group addmembers dom2-g1 \ S-1-5-21-3126357314-3577825812-2501707040-1104 Added members to group dom2-g1 root@addc-02:# wbinfo -n s1\\dom1-g1 S-1-5-21-3126357314-3577825812-2501707040-1108 SID_DOM_GROUP (2) root@addc-02:# samba-tool group addmembers dom2-g1 \ S-1-5-21-3126357314-3577825812-2501707040-1108 Added members to group dom2-g1 root@addc-02: samba-tool group listmembers dom2-g1 S-1-5-21-3126357314-3577825812-2501707040-1108 user2 S-1-5-21-3126357314-3577825812-2501707040-1104 user1
Членство в группе действительно для всех членов в доверенном домене, поэтому, если у вас есть файловый сервер в качестве члена вы можете назначить группу и предоставить разрешения группе.
Проверка доверия в Windows
После того, как вы выполнили все тесты непосредственно на контроллере домена, можно посмотреть, как Windows показывает доверие в RSAT.
Использование трастов на LINUX-клиентах
Теперь, после настройки траста, мы рассмотрим Linux-клиент и то, как вам нужно настроить клиент для пользователей и групп из обоих доменов. Если вы хотите использовать пользователей из обоих доменов вы должны настроить winbind на всех своих клиентах, чтобы разрешить всех пользователей и группы из обоих доменов.
Присоединение к Linux-клиенту
Прежде чем вы сможете присоединиться к клиенту, вы должны настроить его через smb.conf. Вы должны установить ID-маппинг для обоих доменов в вашем smb.conf, как показано в примере 9.1:
[global] workgroup = s1 realm = S1.EXAMPLE.NET security = ADS winbind refresh tickets = Yes template shell = /bin/bash idmap config * : range = 10000 - 19999 idmap config S1 : backend = rid idmap config S1 : range = 1000000 - 1999999 idmap config S2 : backend = rid idmap config S2 : range = 10000000 — 19999999
Теперь вы можете присоединить Linux-клиент к домену. На вашей Linux-машине файл smb.conf уже готов присоединить машину к домену s1. Таким образом, вы можете присоединиться к машине, как в примере:
root@linux-client:# net ads join -U administrator Enter administrator’s password: Using short domain name -- S1 Joined ’LINUX-CLIENT’ to dns domain ’s1.example.net’ root@linux-client:# net ads testjoin Join is OK
После перезапуска smbd , nmbd и winbind вы можете проверить, можете ли вы просмотреть пользователей из обоих доменов с wbinfo . В примере 9.3 вы видите несколько тестов с wbinfo на клиенте:
root@linux-client:# wbinfo -m BUILTIN LINUX-CLIENT S1 S2 root@linux-client:# wbinfo --online-status BUILTIN : online LINUX-CLIENT : online S1 : online S2 : online root@linux-client:# net rpc trustdom list -Uadministrator Enter administrator’s password: Trusted domains list: S2 S-1-5-21-2406301074-2875553281-1464783146 Trusting domains list: S2 S-1-5-21-2406301074-2875553281-1464783146 root@linux-client:# wbinfo -n s1\\ktom S-1-5-21-3126357314-3577825812-2501707040-1104 SID_USER (1) root@linux-client:# wbinfo -n s2\\user1 S-1-5-21-2406301074-2875553281-1464783146-1104 SID_USER (1)
Если вы хотите видеть всех пользователей из любого домена, на клиенте Linux вы все равно можете использовать команду
wbinfo — | g> —domain =
Использование пользователей и групп После того, как вы подключитесь к машине и сможете видеть всех пользователей и группы, вам необходимо отредактировать файл /etc/nsswitch.conf :
passwd: compat winbind group: compat winbind
После настройки /etc/nsswitch.conf вы можете протестировать пользователей и группы с помощью getent как вы можете видеть в примере:
root@linux-client:# getent group s1\\dom1-g1 S1\dom1-g1:x:1001108: root@linux-client:# getent group s2\\dom2-g1 S2\dom2-g1:x:10001108: root@linux-client:# getent passwd s1\\ktom S1\ktom:*:1001104:1000513:ktom:/home/S1/ktom:/bin/bash root@linux-client:# getent passwd s2\\user1 S2\user1:*:10001104:10000513:user1:/home/S2/user1:/bin/bash
Если вы видите своих пользователей и группы из обоих доменов, вы можете приступить к настройке разрешений внутри файловой системы. Я создал несколько домашних каталогов для пользователей из разных доменов. чтобы проверить логин:
root@linux-client:/# mkdir /data-dom1 root@linux-client:/# mkdir /data-dom2 root@linux-client:/# chgrp s1\\dom1-g1 /data-dom1 root@linux-client:/# chgrp s2\\dom2-g1 /data-dom2 root@linux-client:/# chown s1\\ktom /data-dom1 root@linux-client:/# chown s2\\user2 /data-dom2 root@linux-client:/# ls -ld /data-dom1 drwxr-xr-x 2 S1\ktom S1\dom1-g1 4096 Jan 4 16:32 /data-dom1 root@linux-client:/# ls -ld /data-dom2 drwxr-xr-x 2 S2\user2 S2\dom2-g1 4096 Jan 4 16:32 /data-dom2 root@linux-client:/# mkdir /home/S1 root@linux-client:/# mkdir /home/S2 root@linux-client:/# chmod 755 /home/S* root@linux-client:/# mkdir /home/S1/ktom root@linux-client:/# chown s1\\ktom /home/S1/ktom/ root@linux-client:/# mkdir /home/S2/user1 root@linux-client:/# chown s2\\user1 /home/S2/user1
Последний тест будет заключаться в том, сможете ли вы войти в клиент Linux пользователями из обоих доменов. В примере вы увидите тест:
vagrant@linux-client:~$ ssh s1\\ktom@192.168.56.51 s1\ktom@192.168.56.51’s password: . Last login: Fri Jan 4 16:34:52 2019 from 192.168.56.51 S1\ktom@linux-client:~$ vagrant@linux-client:~$ ssh s2\\user1@192.168.56.51 s2\user1@192.168.56.51’s password: . Last login: Fri Jan 4 16:42:09 2019 from 192.168.56.51 S2\user1@linux-client:~$
Теперь вы можете начать создавать несколько общих ресурсов и использовать свою систему в качестве файлового сервера для обоих доменов.
Root-of-Trust для IoT и другие тенденции безопасности устройств интернета вещей
Тема информационной безопасности становится всё более актуальной с каждым годом. Большинство статей по этому вопросу посвящены различным сетевым, веб, облачным и другим технологиям, традиционно рассматриваемым в контексте безопасности. И почти не касаются встраиваемых применений, особенно с ограниченными ресурсами. В то время, как количество последних больше на порядки. В этой статье мы рассмотрим некоторые особенности и тенденции безопасности интернета вещей, берущие своё начало в разработке и модели распространения.
Разработка под встраиваемые применения всегда несла в себе определённые особенности, причём такие, что большинство «обычных» программистов даже не задумываются об этом, а понятие QA и процесс тестирования в многих случаях кардинально отличается от того, что принято понимать в общем случае.
Одна из любимых и периодически обсуждаемых тем в крупном IT-канале в Телеграм Embedded Group — «почему embedded разработчиков никто не понимает и так мало платят? (на фоне «обычных» программистов)»
Встраиваемая система — система, которая будет работать, будучи встроенной непосредственно в устройство, которым она управляет. Пара фото для наглядности:
Левое изображение взято из статьи Wikipedia про встраиваемые системы, это пример крупной сложной системы. Справа фото из обзора умного дома Redmond, здесь всё гораздо проще и компактнее, по сути всё устройство сделано на одном чипе с минимальной обвязкой. Важно, что оба устройства функционируют, как законченные устройства (одноплатному компьютеру всё же нужен корпус и какая-то периферия).
Как правило компания производитель выпускает законченные устройства, которые включает в себя в первую очередь «железо», а софт, как правило, идёт в комплекте и работает только на этом самом железе. Почти никому не придёт в голову идея покупать «голый» смартфон без ПО, а потом ставить на ОС и необходимые приложения, всё должно работать из коробки. В итоге зачастую разработчики выполняют весь спектр задач по разработке устройств, как программных, так и аппаратных.
Ещё одной особенностью разработки под встраиваемые системы является то, что они практически всегда имеют гораздо меньше ресурсов, как по вычислительной мощности, так и памяти, каналу данных, а также потреблению. Большинство привычных многим технологий запустить на таких системах невозможно, даже ОС есть не везде. Необходимо вписаться в доступные ресурсы и часто значительно экономить. В том числе это сказывается и на безопасности — многие стандарты из «большого мира» не поддерживаются или поддерживаются с ограничениями.
C до сих пор является самым массовым языком разработки встраиваемых систем. У него есть ряд недостатков по работе с памятью, прямо влияющих на безопасность. Для их решения был разработан Rust, он набирает популярность (на первом месте любимых языков на StackOverflow уже несколько лет, обгоняя даже Python и Kotlin, особо популярные последнее время), но всё равно пока ещё далёк от лидера по применимости в embedded из-за поддерживаемых систем и библиотек. Более высокоуровневые языки являются редкостью для встраиваемых систем и скорее всего таковыми и останутся в ближайшее время.
Важной особенностью разработки встраиваемых системы является ограничение аппаратных возможностей платформой и SDK поставляемого производителем. Многие технологии реализовать своими силами с нуля для отдельного проекта просто невозможно или крайне затратно. Поэтому крайне важно, чтобы производитель чипов поддерживал современные технологии по безопасности. До недавнего времени этому уделяли на так много внимания. Например, если аппаратный AES появился достаточно давно почти у всех, то поддержку TLS/DTLS до сих пор многие не умеют. Встаёт вопрос, каким образом этого достичь. Один из примеров решения – это SDK на базе Zephyr от Nordic, который решает эту задачу за счёт интеграции с крупным проектом поддерживаемым Linux Foundation. Это один из подходов. Ниже рассмотрим другие.
В рамках рассмотрения вопроса безопасности встраиваемых систем необходимо отметить группу применений, подпадающих под требования стандартов функциональной безопасности: медицина, автомобильная, железнодорожная техника, промышленная автоматизация. Это применения, которые напрямую влияют на жизнь и здоровье человека, а также для систем, которые невозможно остановить (например, ядерные реактор). Здесь всё чётко регламентировано на всех этапах разработки и учитываются потенциальная возможность отказа и эффект на работу системы в целом. Разработка ведётся на специализированных аппаратных и программных решениях, которые в дальнейшем необходимо ещё и сертифицировать. В итоге это получается долго и дорого. Поэтому, те, кто начинают разработку не задумываются об этом, если нет обязательных к исполнению стандартов.
Кроме вопроса разработки важно обратить внимание на условия эксплуатации систем.
Как правило крупные компании, производители облачных сервисов заботятся о безопасности своих сервисов по ряду причин:
- Они занимаются разработкой и поддержкой функционирования сервиса напрямую
- У них гораздо ближе контакт между разработчиками и инженерами поддержки
- Оборудование находится в прямом доступе для инженеров, даже, если в облаках
- Широкие каналы передачи данных и высокая вычислительная способность оборудования позволяет использовать системы мониторинга и выявления аномальной активности
Устройства же интернета вещей работают в прямо противоположном виде:
- Как правило они являются собственностью конечного клиента и настройкой, и поддержкой занимаются инженеры конечного клиента, компетенции, которых в большинстве случаев уступают по объективным причинам.
- Ресурсы каждого устройства ограничены, как по производительности, так и по передаче данных. В результате системы мониторинга и выявления аномальной активности практически невозможны в данном случае.
Для наглядности приведу сравнительную таблицу. Сразу оговорюсь, что:
- есть множество вариантов поставки и поддержки ПО. Приведены лишь общие группы для наглядности отличий
- Количество устройств интернета вещей сложно оценить точно, так как все понимают под ним что-то своё, а также нет хорошей статистики по ним.
Сервера и облачные решения (SaaS и подобные)
Пользовательские устройства (ПК, смартфоны и т.п.)
Кто устанавливает / интегрирует?
Конечный пользователь или ИТ служба компании
Конечный пользователь или системный интегратор
Кто контролирует /эксплуатирует?
Конечный пользователь или ИТ служба компании
Конечный пользователь или ИТ служба компании
Низкоскоростной, в том числе не постоянный
Ограничено массовостью применения (подстанцией)
Крайне низкое (в том числе батарейное)
Количество устройств по миру
От тысяч до сотен тысяч (Amazon, Google) на сервис
За 2019 год продано: Ноутбуки ~266 K, Смартфоны ~1.37 М
Только в РФ количество умных счётчиков 9 миллионов в год
В результате периодически случаются ситуации, что устройства подверглись взлому, а об этом ничего не известно в силу объективных причин. Такая ситуация к сожалению не редкость и может длиться месяцами, а иногда и годами.
Наиболее известны взломы встраиваемых систем за последнее время:
- ботнет Mirai в 2016 году, работающий в основном на видеокамерах. По разным оценкам количество заражённых устройств превышало 380 тысяч. Его наследник Satori в 2018 захватил уже 700 тысяч устройств, ориентируясь в первую очередь на майнеры криптовалюты.
- KRACK поразивший в 2017 году WPA2 Wi-Fi (практически все устройства с Wi-Fi за последние 15 лет) и его наследник Kr00k, с числом более миллиарда устройств в 2019 году.
- В 2018 году Bleedingbit поразил BLE-чипы Texas Instruments. Официально проблеме были подвержены только несколько моделей точек доступа, которые использовали семейства CC26xx, а сама проблема решалась в новой версии стека. Однако, в данном случае не учитывается, что данные чипы используются в гораздо большем числе устройств (второй в мире производитель BLE, 16% от 3.9 млрд за 2018 год).
Большинство производителей оборудования выпускает исправления для своих устройств. Однако, эти исправления необходимо ещё применить на самих устройствах, что для устройств интернета вещей сложно или в ряде невозможно. Как следствие значительная часть устройств так и остаётся потенциально уязвимой. И об этом могут так никогда не узнать из-за отсутствия контроля и должного внимания к этому вопросу.
Соответственно необходимо использовать принципиально иные подходы для предотвращения появления уязвимостей и устранения последствий для устройств интернета вещей. Безопасность должна лежать в самой платформе с самого этапа её проектирования и выполняться на всех этапах разработки и эксплуатации конечного устройства, но при этом быть достаточно простой и недорогой для массового внедрения (как минимум относительно функциональной безопасности и TEE мощных процессоров).
ARM ещё в 2017 года рассказывал про безопасность встраиваемых систем на основе CryptoCell и Cortex-M33, однако серийные образцы чипов на M33 появились лишь в прошлом году. Представленная технология получила название Platform Security Architecture (PSA).
Суть идеи заключалась в том, чтобы разделить критичные части системы (ключи, права, прошивку) от потенциально подверженных взлому компонентов, как аппаратных, так и программных, для систем, где полная реализация TEE невозможна или затруднена. Технология ориентирована в первую очередь на Cortex-M, но совместима со всеми семействами Cortex-A/-R/-M.
В основном рассматривают 4 этапа защиты устройств интернета вещей. Рассмотрим их в последовательности по мере возникновения в процессе работы устройства.
Безопасная загрузка (Secure Boot)
- Проверяется, что прошивка является подлинной, не была изменена и не может быть понижена в версии (downgrade).
Безопасное обновление прошивки по воздуху (Secure FOTA)
- Могут быть загружены только аутентифицированные и проверенные обновления.
- Будущие угрозы безопасности могут быть устранены (сохранение контроля над обновлением в будущем)
Безопасные физические интерфейсы и API
- Только авторизованные пользователи могут получить отладочный доступ к устройству, и каждое разрешение на доступ уникально.
- Блокирует «разработку» закладок и обеспечивает авторизованное использование API.
- Данные аутентифицированы и защищены целостностью в обоих направлениях — внутри и снаружи модуля
Безопасный транспортный уровень
- Устройство может аутентифицировать и подписывать или шифровать сообщения с сервером
- Нет атак посредника (MITM) на пути между устройством и сервером
Для защиты устройства предлагается идентифицировать/верифицировать данные поступающие на каждом этапе. В основе концепции лежит идея корня доверия (Root-of-Trust, RoT). Суть заключается в том, что в устройстве зашивается некий идентификатор (ключ) и происходит аппаратная процедура проверки соответствия уникальности ключа текущей платформе и исполняемому коду. В дальнейшем все важные библиотеки используют RoT для собственной работы.
Как правило это происходит в 3 основных этапа:
- Предоставление доверия: включение Root-of-Trust на этапе производства в структуру чипа
Неизменяемый идентификатор чипа и аппаратный корень доверия обеспечивают базовую безопасность и уникальную идентификацию устройства. - Использование доверия: получение доверенных ключей
Защищенные библиотеки позволяют создавать аппаратные криптографические функции и ключи, которые используются обычными функциями в дальнейшем - Гарантия доверия: ключи используются для защиты любой функции
Гарантируется подлинность, целостность и конфиденциальность работы любой функции с использованием ключей и функций со 2 этапа.
Наиболее распространённым решением на рынке является TrustZone от ARM.
В контексте данной статьи стоит отметить, что ранее TrustZone был привилегией высокопроизводительных процессоров семейства Cortex-A. А за прошедший год практически все производители беспроводных систем на кристалле выпустили решения на базе Cortex-M, наибольшей популярностью пользуется Cortex-M33.Говоря про информационную безопасность стоит напомнить про систему общих критериев (Common Criteria), принятых как на международном уровне, так и качестве национального стандарта. Она позволяет определить уровень доверия Evaluation Assurance Level (EAL) от 1 до 7 (EAL1 — EAL7), более высокая цифра показывает более высокий уровень безопасности. Для понимания, уровень EAL4 или EAL4+ имеют большинство ОС Windows, LInux/Unix, EAL5 в осном имеют смарт-карты (банковские, транспортные, в том числе бесконтактные), EAL6 позволяет использовать решение в высокорисковых ситуациях, EAL7 в экстремально рисковых ситуациях, например, для однонаправленных сетей (диодов данных).
В апреле этого года Cortex-M33 и M35P были сертифицированы по уровню EAL6+. Это очень высокий уровень, позволяющий применять решения в высокорисковых ситуациях.
ARM TrustZone Cryptocell в новых Cortex-M33/M23 обеспечивает безопасное хранение ключей (в том числе с уникальным аппаратным идентификатором), проверку прошивок, как на этапе загрузки, так и обновления по воздуху, аппаратное ускорение шифрования AES, SHA, ChaCha, ECC, в том числе с DMA (как следствие все данные во Flash и RAM могут быть зашифрованы), генераторы случайных чисел (TRNG, PRNG).
Из интересного можно отметить, что CryptoCell позволяет иметь несколько корней доверия для различных задач (например, встраивать дополнительный RoT под заказчика, который хочет интегрировать массовое решение с рынка в свою закрытую IT систему, например, банк, не привязываясь к основному RoT от производителя), а также безопасную отладку (Secure Debug) с авторизацией прав.
300 серия CryptoCell ориентирована как раз на малопотребляющие устройства интернета вещей. Потребление новых M33 примерно на 20-40% ниже, чем M4, учитывая потери в энергопотреблении на работу TrustZone в 20% имеем такой же или более низкий уровень потребления, чем сейчас. Как следствие можно сказать, что аппаратная безопасность пришла в наиболее массовый бюджетный сегмент с Cortex-M33/M23 и в ближайшее время количество продуктов на базе их будет только увеличиваться.
В качестве TrustZone альтернативы можно назвать OpenTitan спонсируемый Google. Однако, он пока не распространён и ориентирован на другие применения, нежели конечные устройства интернета вещей.
Стоит отметить, что аппаратная реализация корня доверия не является панацей и тоже может быть взломана. В качестве примера можно привести недавнюю историю с Intel. Важно упомянуть, что в данном случае была найдена ошибка в ROM и был использован один ключ на все поколения чипсетов, поэтому его можно воспроизвести. И даже такая реализация значительно усложняет взлом.
Рассмотрим 5 этапов эволюции реализации Root-of-Trust в модулях сотовой связи uBlox, разработанной в сотрудничестве с Kudelski Group. Это интересно с точки зрения поставленной задачи, так как их решения значительно отличаются от подходов других компаний. Модули сотовой связи Nb-IoT/ LTE Cat-M относятся к переходным классам между 4 и 5 поколениям LTE и ориентированы на низкопотребляющие сети LPWAN. В большинстве случаев устройства должны работать годами без вмешательства человека. Современные решения позволяют работать 7-10 лет на одном элементе питания (батарейке). Средний срок службы устройства часто достигает 15 лет. За это время могут значительно измениться требования по безопасности, появиться новые угрозы. Устройства при этом должны работать стабильно без вмешательства человека весь срок службы. Соответственно необходимо защищать подобные устройства с учётом срока и характера их работы.
Как видно на структуре с каждым следующим поколением корень доверия меняет своё положение. Это является ключевым моментом влияющим на безопасность решения в целом.
1 и 3 варианты признаны ненадёжными по мнению uBlox/Kudelski из-за программной реализации RoT и наиболее вероятного взлома. В том числе для случая вынесения корня доверия во внешний eSIM (eUICC), который обеспечивает защиту достаточную для банковских применений начального уровня EAL4 (ключи в eUICC невозможно прочитать или изменить, чтобы это не стало заметно извне). Однако такой подход несёт с собой недостатки и потенциальные уязвимости, возникающие из-за того, что общение с внешним компонентом можно перехватить и потенциально исказить, сложности взаимодействия на начальных этапах инициализации системы (проверка загрузчика), а также сложный механизм программирования из-за ограниченных ресурсов чипов в UICC. Кроме того внешний модуль можно заменить или удалить из системы (просто поменяв SIM карту) и тем самым оставив всю систему без корня доверия.
Поэтому дальнейший путь развития заключается в интеграцией корня доверия в защищённой области чипа. Этот подход соответствует компепции ARM TrustZone CryptoCell.
Вариант с реализацией Root-of-Trust в защищённой ОС является наиболее распространённым на рынке и обеспечивает достаточный для большинства задач уровень безопасности. Наиболее распространённое решение на рынке — ARM TrustZone (про него выше), но ещё без CryptoCell, хранящего ключи в защищённой области.
Наибольшей же защитой обладает решение с защитой интегрированной внутрь чипсета, к которому практически нет доступа извне. В текущем решении используется встроенный элемент безопасности (Secure Element), сертифицированный по уровню EAL5+. Это допускает сертификацию Common Criteria для всего устройства в целом, а также позволяет размещать функции SIM-карты и профили мобильного сетевого оператора (MNO) внутри устройства. Это соответствует современному уровню безопасности.
В разработке находится следующее поколение чипсета от uBlox, где Secure Element будет интегрирован в кремний самого модемного чипсета. Это еще больше уменьшает поверхность атаки и повышает безопасность до самого высокого уровня. Это будет реализовано через iUICC (Integrated Universal Integrated Circuit Card) — следующее поколение UICC, при котором весь код и SIM идентификатор будут располагаться внутри системы на кристалле, стандарт пока не завершён.
- Всё больше производителей электронных компонентов разрабатывают и выпускают устройства с учётом требований безопасности, начиная с самых ранних этапов разработки.
- Компании разработчики конечных устройств получают инструменты управления безопасностью, работающие прямо из коробки. Привлечение экспертов на этапе разработки инструментов позволяет избежать ошибок, а также значительно снизить стоимость решения в целом.
- Ценник на новые решения зачастую оказывается близок к текущим решениям, но даёт принципиально иной уровень защиты, что также значительно упрощает переход
- Рост числа устройств обеспечивающий новый уровень безопасности является лишь вопросом времени
- В новых решениях secure element UICC переносится внутрь кристалла чипа для повышения безопасности и затруднения атаки
- Современные решения позволяют получить уровни безопасности вплоть до EAL6+, достаточные для использования в высокорисковых ситуациях.
- В разработке находятся решения уровня EAL7, однако они используют технологии без окончательно утверждённого стандарта, поэтому срок доступности их рынке не определён.