Root of trust что это
root of trust
Смотреть что такое «root of trust» в других словарях:
Root certificate — In cryptography and computer security, a root certificate is either an unsigned public key certificate or a self signed certificate that identifies the Root Certificate Authority (CA). A root certificate is part of a public key infrastructure… … Wikipedia
Web of trust — For the internet security website, see WOT: Web of Trust. In cryptography, a web of trust is a concept used in PGP, GnuPG, and other OpenPGP compatible systems to establish the authenticity of the binding between a public key and its owner. Its… … Wikipedia
Martha Root — Martha Louise Root Martha Louise Root (August 10, 1872 – September 28, 1939) was a prominent traveling teacher of the Bahá í Faith in the late 19th and early 20th century. Shoghi Effendi, the Guardian of the Bahá í Faith called her the foremost… … Wikipedia
Purpose trust — Wills, trusts and estates … Wikipedia
Cystic Fibrosis Trust — The Cystic Fibrosis Trust, founded in 1964, is the United Kingdom’s only national charity dedicated to all aspects of cystic fibrosis (CF). It funds research to treat and cure CF and aims to ensure appropriate clinical care and support for people … Wikipedia
London Probation Trust — Logo of the London Probation Trust. Agency overview Fo … Wikipedia
Bankers Trust — The Bankers Trust was a historic American banking organization that was acquired by Deutsche Bank in 1998.HistoryIt was originally set up when banks could not perform trust company services. A consortium of banks all invested in a new trust… … Wikipedia
Chain of trust — In computer security, a chain of trust is established by validating each component of hardware and software from the bottom up. It is intended to ensure that only trusted software and hardware can be used while still remaining flexible.… … Wikipedia
Operation Broken Trust — Operation Broken Trust, the largest investment fraud sweep by the Federal government of the United States, was conducted between August 16 and December 1, 2010.[1] The stated purpose of the operation was to root out and expose investment scams… … Wikipedia
Off-line Root CA — In a Public Key Infrastructure PKI the top of the trust path is the Certificate authority (CA), because is on the top is called the root CA. The CA is able to issue, distribute and revoke digital certificates X.509. The CA which is software… … Wikipedia
The Remnant Trust, Inc. — Infobox Company company name = The Remnant Trust, Inc. company company type = Non profit organization foundation = 1997 location address = location city = 129 East Court Avenue, Jeffersonville, Indiana location country = United States, GPS: N 38… … Wikipedia
Intel х86 Root of Trust: утрата доверия
Вот и настал момент, которого, возможно, больше всего боялись системные архитекторы, инженеры и специалисты по безопасности компании Intel: была найдена ошибка в неперезаписываемой области памяти (ROM) подсистемы Intel Converged Security and Management Engine, и эта ошибка ставит под сомнение все усилия компании по созданию корня доверия и фундамента безопасности на ее платформах.
И дело здесь даже не в том, что ошибки микропрограммного обеспечения (firmware), которое «зашито» в бортовой памяти Mask ROM микропроцессоров и чипсетов, уже невозможно исправить, а скорее в том, что найденная ошибка разрушает цепочку доверия всей платформы в целом, позволяя скомпрометировать ее аппаратную основу.
Специалисты компании Positive Technologies нашли аппаратную ошибку в оборудовании Intel, а также ошибку в firmware Intel CSME, которая проявляется на очень раннем этапе работы этой подсистемы, в ее загрузочной ROM (boot ROM). Известно, что именно Intel CSME обеспечивает начальную аутентификацию системы, построенной на чипах Intel, загружая и проверяя все остальное микропрограммное обеспечение современных платформ. Например, именно Intel CSME, взаимодействуя с микрокодом CPU, обеспечивает подлинность прошивки UEFI BIOS посредством технологии BootGuard. Кроме того, Intel CSME загружает и верифицирует прошивку контроллера электропитания (Power Management Controller), управляющего подачей напряжения к каждому аппаратному блоку в микросхемах Intel.
Но важнее то, что именно Intel CSME отвечает за криптографическую базу таких аппаратных технологий защиты, разработанных компаний Intel и используемых повсеместно, как DRM, fTPM и Intel Identity Protection. Внутри прошивки Intel CSME реализована схема удаленной аттестации доверенных систем, называемая EPID (Enhanced Privacy ID), которая позволяет однозначно и анонимно идентифицировать каждый конкретный экземпляр вычислительной системы (компьютер), находя множество полезных применений, таких как защита цифрового контента, обеспечение безопасности финансовых транзакций, аттестация интернета вещей. Кроме того, в прошивке Intel CSME реализован программный модуль TPM, позволяющий использовать ее для хранения ключей шифрования без дополнительной микросхемы TPM, которая имеется далеко не в каждом компьютере.
И компания Intel постаралась сделать этот корень доверия как можно более безопасным. Система безопасности платформ Intel построена таким образом, что даже ошибка произвольного выполнения кода в любом из модулей прошивки Intel CSME не несет риска потери корневого ключа безопасности (он же Chipset Key), а только лишь подвергает риску конкретные функции, за которые отвечает уязвимый модуль, при этом позволяя легко нивелировать риск путем смены ключей шифрования с помощью механизма безопасного номера версии SVN. Это было наглядно продемонстрировано в 2017 году, когда была найдена ошибка произвольного выполнения кода в модуле прошивки BringUP (bup), описанная в Intel SA-00086. Тогда компания Intel просто выполнила перегенерацию ключей, увеличив SVN, и таким образом легко избежала риска компрометации технологий, построенных на EPID.
Но к сожалению, не существует идеальных систем безопасности, и, как любая другая, архитектура безопасности Intel имеет свою ахиллесову пяту — загрузочную ROM. Ошибка в ROM на ранних стадиях выполнения действительно позволяет контролировать процесс считывания Chipset Key и генерации всех остальных ключей шифрования. Один из таких ключей предназначен для шифрования массива данных контроля целостности (Integrity Control Value Blob, ICVB). Имея этот ключ, можно подделать код любого из модулей прошивки Intel CSME — и система проверки подлинности не сможет распознать подделку. Это равнозначно утечке закрытого ключа цифровой подписи прошивки Intel CSME, но для данной конкретной платформы.
На данный момент ситуацию с EPID смягчает тот факт, что Chipset Key хранится внутри платформы (в специальной OTP-памяти, One-Time Programmable Memory) в зашифрованном виде и для полной компрометации EPID требуется также извлечь аппаратный ключ, на котором зашифрован Chipset Key, хранящийся в специальном хранилище SKS (Secure Key Storage). Но этот ключ не уникален для платформы, а один на все поколение чипсетов Intel. И поскольку найденная ошибка в ROM позволяет перехватить выполнение кода до запирания (locking) механизма генерации аппаратного ключа в SKS, а сама ошибка в ROM не может быть исправлена, мы считаем, что это только дело времени — когда этот ключ будет извлечен. И тогда наступит полный хаос: аппаратная идентификация будет подделана, цифровой контент извлечен, зашифрованная информация с постоянных носителей расшифрована.
Итак, специалисты Positive Technologies нашли ошибку в Intel CSME boot ROM во всех выпущенных на данный момент чипсетах и SoC Intel кроме Ice Point (10-е поколение процессоров). Эта ошибка позволяет извлечь Chipset Key, а также манипулировать частью аппаратного ключа и процессом его генерации, не позволяя, однако, на данный момент напрямую получить его аппаратную составляющую (зашитую в SKS). При этом данная ошибка в ROM позволяет организовать произвольное выполнение кода на нулевом уровне привилегий Intel CSME.
Более подробно мы опишем технические детали в полном white paper, посвященном этой ошибке, который мы планируем опубликовать немного позже. Следует отметить, что после того, как наши специалисты обратились в Intel PSIRT с отчетом о данной ошибке, Intel сообщила, что ошибка уже известна (CVE-2019-0090). В Intel понимают, что ошибку в ROM исправить в уже выпущенном оборудовании нельзя, и поэтому просто блокируют все возможные пути ее эксплуатации. Патч для CVE-2019-0090 исправляет лишь один из возможных векторов атаки — через интегрированный сенсорный хаб (Integrated Sensors Hub, ISH). Мы думаем, что потенциально существует немало способов эксплуатации данной уязвимости в ROM. Часть из них возможно требуют локального доступа, часть физического. Чтобы немного приоткрыть завесу тайны, скажем пару слов о самой уязвимости:
Автор: Марк Ермолов, ведущий специалист отдела исследований безопасности ОС и аппаратных решений Positive Technologies.
root of trust
1 root of trust
См. также в других словарях:
Root certificate — In cryptography and computer security, a root certificate is either an unsigned public key certificate or a self signed certificate that identifies the Root Certificate Authority (CA). A root certificate is part of a public key infrastructure… … Wikipedia
Web of trust — For the internet security website, see WOT: Web of Trust. In cryptography, a web of trust is a concept used in PGP, GnuPG, and other OpenPGP compatible systems to establish the authenticity of the binding between a public key and its owner. Its… … Wikipedia
Martha Root — Martha Louise Root Martha Louise Root (August 10, 1872 – September 28, 1939) was a prominent traveling teacher of the Bahá í Faith in the late 19th and early 20th century. Shoghi Effendi, the Guardian of the Bahá í Faith called her the foremost… … Wikipedia
Purpose trust — Wills, trusts and estates … Wikipedia
Cystic Fibrosis Trust — The Cystic Fibrosis Trust, founded in 1964, is the United Kingdom’s only national charity dedicated to all aspects of cystic fibrosis (CF). It funds research to treat and cure CF and aims to ensure appropriate clinical care and support for people … Wikipedia
London Probation Trust — Logo of the London Probation Trust. Agency overview Fo … Wikipedia
Bankers Trust — The Bankers Trust was a historic American banking organization that was acquired by Deutsche Bank in 1998.HistoryIt was originally set up when banks could not perform trust company services. A consortium of banks all invested in a new trust… … Wikipedia
Chain of trust — In computer security, a chain of trust is established by validating each component of hardware and software from the bottom up. It is intended to ensure that only trusted software and hardware can be used while still remaining flexible.… … Wikipedia
Operation Broken Trust — Operation Broken Trust, the largest investment fraud sweep by the Federal government of the United States, was conducted between August 16 and December 1, 2010.[1] The stated purpose of the operation was to root out and expose investment scams… … Wikipedia
Off-line Root CA — In a Public Key Infrastructure PKI the top of the trust path is the Certificate authority (CA), because is on the top is called the root CA. The CA is able to issue, distribute and revoke digital certificates X.509. The CA which is software… … Wikipedia
The Remnant Trust, Inc. — Infobox Company company name = The Remnant Trust, Inc. company company type = Non profit organization foundation = 1997 location address = location city = 129 East Court Avenue, Jeffersonville, Indiana location country = United States, GPS: N 38… … Wikipedia
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 год продано: Ноутбуки |
1.37 М
В результате периодически случаются ситуации, что устройства подверглись взлому, а об этом ничего не известно в силу объективных причин. Такая ситуация к сожалению не редкость и может длиться месяцами, а иногда и годами.
Наиболее известны взломы встраиваемых систем за последнее время:
Соответственно необходимо использовать принципиально иные подходы для предотвращения появления уязвимостей и устранения последствий для устройств интернета вещей. Безопасность должна лежать в самой платформе с самого этапа её проектирования и выполняться на всех этапах разработки и эксплуатации конечного устройства, но при этом быть достаточно простой и недорогой для массового внедрения (как минимум относительно функциональной безопасности и TEE мощных процессоров).
ARM ещё в 2017 года рассказывал про безопасность встраиваемых систем на основе CryptoCell и Cortex-M33, однако серийные образцы чипов на M33 появились лишь в прошлом году. Представленная технология получила название Platform Security Architecture (PSA). 
Суть идеи заключалась в том, чтобы разделить критичные части системы (ключи, права, прошивку) от потенциально подверженных взлому компонентов, как аппаратных, так и программных, для систем, где полная реализация TEE невозможна или затруднена. Технология ориентирована в первую очередь на Cortex-M, но совместима со всеми семействами Cortex-A/-R/-M.
В основном рассматривают 4 этапа защиты устройств интернета вещей. Рассмотрим их в последовательности по мере возникновения в процессе работы устройства.
Как правило это происходит в 3 основных этапа:
В контексте данной статьи стоит отметить, что ранее 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 идентификатор будут располагаться внутри системы на кристалле, стандарт пока не завершён.