Если вам интересно, чем безопасности прошивки могут помочь STM, SGX и PSP — жду вас под катом.
Желая показать бунтарский дух и наплевательство на традиции, ссылки на предыдущие части не даю — сами ищите их там.
Часть седьмая. Технологии будущего
Несмотря на то, что все описываемые далее технологии уже давно представлены официально, рассказывать о них я все равно буду как о возможностях завтрашнего дня, по весьма прозаической причине — даже в такой быстроразвивающейся среде как UEFI от представления какой-то технологии до ее внедрения могут пройти годы (достаточно вспомнить PFAT, появившуюся еще в Haswell, но не внедренную толком до сих пор).
Про SGX и STM я уже упоминал в конце третьей части, поэтому начну рассказ с PSP, которым теперь без вариантов комплектуются все новые AMD APU.
AMD Platfrom Security Processor
Наблюдая за успехами Intel Management Engine, которым последние 5 лет оборудован каждый чипсет и SoC Intel, в AMD тоже решили не отставать от прогресса и встроить в свои SoC'и чего-нибудь эдакого.
Еще бы — хочется иметь аппаратный корень доверия, хочется нормальный генератор случайных чисел, хочется криптоускоритель и эмулятор TPM 2.0, в общем — много всего хочется, и реализовать это все не трудно — купи IP Core у какого-нибудь поставщика, напиши к нему прошивку и навесь на него побольше системных функций, чтобы пользователь твоей платформы даже не вздумал отключить то, за что столько денег уплочено.
В итоге в качестве IP Core купили ядро ARM Cortex-A5 с поддержкой технологии TrustZone, для эмуляции TPM 2.0 приобрели у Trustonic код TEE, остальное реализовали сами и представили получившийся SoC-внутри-SoC'а в 2013 году на очередном UEFI Plugfest.
Оригинальная схема PSP, про эмуляцию TPM речи тогда еще не шло.
Для обеспечения безопасности UEFI этот самый PSP предоставляет следующее: подсистему HVB, внутреннее хранилище для S3 BootScript, эмулятор TPM для реализации Measured Boot, генератор случайных чисел и ускоритель криптографических операций.
Hardvare Validated Boot
Про эту технологию я уже рассказывал в первой части, теперь расскажу более подробно. Суть ее простая — PSP получает управление до старта BSP и проверяет, чтобы содержимое второй стадии его прошивки и стартового кода не было изменено, в случае успеха BSP стартует с ResetVector'а и машина загружается как обычно, а в случае неудачи пользователю показывают код ошибки на POST-кодере, а BSP крутит мертвый цикл до hard reset'а, после которого все повторяется заново.
HVB, таким образом, является аппаратным корнем доверия для системы, но защищает эта технология только PEI-том, проверка же всего остального — на совести авторов прошивки.
Оригинальная схема AMD HVB
По умолчанию HVB отключен на всех платформах и для включения необходима достаточно нетривиальное его конфигурирование, поэтому я пока и сам не испытывал технологию на практике (хотя непосредственно работаю с прошивками для второго поколения процессоров с PSP), и машин с включенным HVB на открытом рынке не видел.
Integrated TPM 2.0
К релизу Windows 10 рабочая группа TCG подготовила интересное нововведение: вместо использовавшегося ранее интерфейса TIS для взаимодействия с модулями TPM теперь можно использовать вызовы ACPI, что позволяет производителям процессоров реализовать TPM не на внешнем чипе, а прямо в чипсете, да еще и половину реализации сделать программной. Такое решение имеет как преимущества (заменить чипсет сложнее, чем чип TPM в корпусе SSOP-28), так и недостатки (vendor lock-in), но реализовали его на данный момент и Intel (в Skylake) и AMD (в APU с PSP). Стандарт TPM 2.0 поддерживается обоими решениями не целиком, а только настолько, чтобы система со встроенным TPM могла использовать BitLocker и получить сертификат Windows 10 Ready. Тем не менее, теперь полку пользователей TPM однозначно прибудет. Вместе с встроенным TPM появились также аппаратный ГСЧ и криптоускоритель, которые, при желании, можно использовать отдельно.
Secure S3 BootScript Storage
Еще одна фишка PSP — встроенный NVRAM, в котором можно безопасно хранить какие-то пользовательские данные. На данный момент AMD сохраняет туда S3 BootScript, что хорошо защищает систему от атак на него. При этом немного страдает время выхода из S3, но лишние 50-100 мс ради безопасности вполне можно терпеть.
К сожалению, у AMD с открытой документацией на PSP очень грустно, поэтому дать полезных ссылок не могу, все, что мог рассказать без нарушения NDA — уже рассказал.
Intel Software Guard Extensions
Вернемся теперь к технологиям Intel. Об SGX начали говорить около года назад, но для конечного пользователя она стала доступна всего несколько недель назад, когда Intel включила ее для процессоров Skylake в очередном обновлении микрокода. SGX — это новый набор инструкций, позволяющих приложениям создавать т.н. «анклавы», т.е. регионы памяти для кода и данных, аппаратно защищенные от доступа извне, даже если этот доступ производится из более привилегированных режимов исполнения вроде ring 0 и SMM.
Технология достаточно сложная для понимания и использования (почти 200 страниц Programming Reference), но потенциально очень мощная, поэтому Intel начала заниматься ее продвижением.
Принципиальная схема работы SGX, один из более 200 слайдов вот этой презентации, она же в виде 80-минутного видео.
Intel называет SGX «обратной песочницей», т.е вместо того, чтобы пытаться изолировать потенциально вредоносное или недоверенное ПО, при помощи SGX программа может изолировать себя от всего остального мира. Идея сходна с ARM TrustZone, но если у ARM мир делится на обычный и доверенный и они выполняются на разных ядрах, взаимодействуя только через вызов инструкции SMC, то у Intel ядро одно и то же, зато память делится обычную и безопасную:
Безопасный анклав посреди обычной памяти.
Мое отношение к этой технологии пока еще не сформировалось — я ее просто еще не пробовал, т.к. не работаю над Skylake в данный момент. Тем не менее, стараюсь не отставать от прогресса слишком уж сильно, поэтому читаю краем уха все, что пишут про SGX, к примеру:
Портал об SGX на сайте Intel.
Обзорная лекция об SGX с сайта Дармштадтского Технического Университета.
Обзорная статья NccGroup с кучей интересных ссылок.
Открытая платформа для написания своего кода для SGX.
И вообще, весь раздел про SGX на firmwaresecury.com.
Intel SMI Transfer Monitor
Вторая технология Intel, о которой я уже упоминал — STM. Первые упоминания о нем датированы 2009 годом, и после 6 лет разработки технология наконец-то была представлена в августе 2015. Суть ее простая: вместо диспетчера SMM в SMRAM запускается гипервизор, и все обработчики SMI выполняются в виртуализованном окружении, что позволяет запретить им вредоносные действия вроде изменения данных в памяти ядра и тому подобные.
Слайд из презентации STM на IDF2015
Технология позволяет значительно уменьшить как «поверхность атаки» на обработчики SMM, так и разрушительность последствий взлома обработчиков SMI. К примеру, запретив доступ к MMIO чипсета для всех обработчиков, кроме используемого для обновления прошивки, можно защитить ее от остальных обработчиков, путь даже они взломаны атакующим и он имеет возможность выполнить в них произвольный код.
Самое главное преимущество — неприхотливость, для работы STM нужны только включенные VT-x/AMDV и правильные настройки уровней доступа. На данный момент предварительная поддержка STM реализована в EDK2 только для тестовой платы MinnowBoard Max, но в ближайшие полгода-год IBV адаптируют ее для своих платформ, и взлома SMM можно будет опасаться гораздо меньше. Понятно, что бесплатной безопасности не бывает, и STM вносит дополнительную сложность в итак не самый простой процесс инициализации SMM, плюс обработка SMI занимает больше времени (страшнее, на самом деле, то, что оно занимает еще более неопределенное время, опять страдают пользователи жестких ОСРВ), плюс виртуализацию незнающий пользователь платформы может отключить и STM не получится использовать в таких условиях. Тем не менее, я потыкал в STM веткой на MinnowBoard и могу сказать: чем скорее IBV внедрят её — тем лучше.
Дополнительная информация для желающих:
Пост Винсента Циммера с анонсом STM.
Портал об STM на сайте Intel, с полезными ссылками.
Заключение
Ну вот и подошел к концу этот цикл статей, надеюсь читателю было интересно.
Технологии развиваются быстро, и если завтра появится какая-то прорывная технология (или найдут зияющую дыру в существующих) — постараюсь о них написать.
В следующей статье будет укрощать SecureBoot — сгенерируем свои ключ PK и KEK, а параноики смогут запретить загрузку любых вещей, не подписанных их ключами. Спасибо за внимание.
P.S. Обещал в последней части итоговую таблицу, но не смог в нее. Кодить — могу, писать по-русски — туда-сюда, красиво размечать таблицы — не выходит каменный цветок. Прошу искреннего пардону.
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий