Представлен (https://keystone-enclave.org/#News) первый выпуск проекта Keystone (https://keystone-enclave.org/), в рамках которого подготовлен набор спецификаций и программных компонентов для встраивания функциональности защищённых анклавов в чипы на базе архитектуры RISC-V. Наработки проекта распространяются (https://github.com/keystone-enclave/) под лицензией BSD. Проект развивается исследовательской группой из Калифорнийского университета в Беркли и Массачусетского технологического института.
Анклав (TEE (https://en.wikipedia.org/wiki/Trusted_execution_environment)... Execution Environment) подразумевает предоставление процессором специальной изолированной области, которая позволяет вынести часть функциональности приложений и операционной системы в отдельное окружение, содержимое памяти и выполняемый код в котором недоступны из основной системы, независимо от уровня имеющихся привилегий. Для своего выполнения в анклав могут перемещаться реализации различных алгоритмов шифрования, функции обработки закрытых ключей и паролей, процедуры аутентификации, код для работы с конфиденциальными данными.
В случае компрометации основной системы злоумышленник не сможет определить хранимую в анклаве информацию и будет ограничен лишь внешним программным интерфейсом. Применение аппаратных анклавов может рассматриваться как альтернатива применению для защиты вычислений методов на основе гомоморфного (https://ru.wikipedia.org/wiki/%D0%93%D0%... шифрования или протоколов конфиденциального вычисления (https://ru.wikipedia.org/wiki/%D0%9F%D1%... но в отличие от данных технологий анклав практически не влияет на производительность вычислений с конфиденциальными данными и существенно упрощает разработку.
Keystone может рассматриваться как открытая альтернатива таким решениям, как Intel SGX (Software Guard Extensions), ARM TrustZone и AMD PSP (Platform Security Processor). Достоинством предлагаемого открытого решения является полная доступность для аудита на всех уровнях, в отличие от вышеупомянутых решений, полагающихся на принцип
"security by obscurity (https://ru.wikipedia.org/wiki/%D0%91%D0%... (безопасность через скрытие внутренней реализации). Как показала практика, подход основанный на ограничении не оградил Intel (https://www.opennet.ru/opennews/art.shtml?num=47597) SGX (https://www.opennet.ru/opennews/art.shtml?num=48173), ARM (https://www.opennet.ru/opennews/art.shtml?num=46911) TrustZone (https://www.opennet.ru/opennews/art.shtml?num=44718) и AMD (https://www.opennet.ru/opennews/art.shtml?num=48302) PSP (https://www.opennet.ru/opennews/art.shtml?num=47866) от критических уязвимостей.Разработанные в рамках проекта Keystone спецификации позволяют интегрировать функциональность анклава в любой процессор на базе архитектуры RISC-V с минимальным числом вносимых изменений, обеспечивающих аппаратную изоляцию. Изменения касаются обеспечения физической изоляции доступа к памяти и изоляции таблиц страниц памяти. Для защиты от физических атак (анализ чипов памяти) содержимое памяти анклава и передаваемые по шине адреса шифруются. Для защиты от атак по сторонним каналам применяется полностью изолированная архитектура.
Для разработки приложений, выносящих часть функциональности и данных в анклав, предлагается специальный SDK (https://github.com/keystone-enclave/keystone-sdk). Проектом также развивается модифицированный вариант ядра Linux (https://github.com/keystone-enclave/riscv-linux), минимальный runtime (https://github.com/keystone-enclave/keystone-runtime), загрузчик (https://github.com/keystone-enclave/sanctum_bootloader) с поддержкой верификации загружаемого кода по цифровой подписи и специальное программное окружение (https://github.com/keystone-enclave/busybear-linux), формирующие операционную систему анклава, набор утилит для верификации окружений и генерации цифровых подписей. Для тестирования разрабатываемых анклавов предоставляются эмулятор (https://github.com/keystone-enclave/keystone) на базе QEMU и аппаратный симулятор (https://github.com/keystone-enclave/keystone-firesim) на базе FireSim, использующий платы FPGA.
URL: https://keystone-enclave.org/#News
Новость: https://www.opennet.ru/opennews/art.shtml?num=49760
Походит на имеи всякие. Надо ли это? Не приведёт ли это в итоге в внедрению сопроцессоров для безопасности, но неподконтрольных пользователю и ОСи и с бинарём внутри?
В итоге? Это происходит уже лет 15.
[i]Это происходит уже лет 15.[/i] - со слоганом "какать в рот качественно".
Увы.
> неподконтрольных пользователю
> бинарём внутритак то MIT, а не GPL
что еще вы хотели
тьфу, BSD, но с митом было бы так же
>> неподконтрольных пользователю
>> бинарём внутри
> так то MIT, а не GPL
> что еще вы хотелиТо ли дело андроид (или либрелинукс) -- никаких блобиков, полный контроль пользователем?
Ну как бы allwinner GPLным uboot с GPLным линем загружается и как бы это полный контроль над железкой. Совсем без блоботни.
> Ну как бы allwinner GPLным uboot с GPLным линем загружается и как
> бы это полный контроль над железкой. Совсем без блоботни.Еще вспомним тинкпады 10 летней давности, на которых можно загрузить либребутом либрелинукс.
Из этого делаем вывод, что есть полный контроль на мобильной и домашнестацинонарной (если взять W модель) платформе! Профит!К сожалению, даже такой передерг фактов никак не вляет на реальность с кучей подгружаемых ядром блобиков.
но это хотя бы какои-то попытки двигаться в правильном направлении, лучше чем совсем сдаваться
первичный загрузчик allwinner все же blob - хотя уже и дешифрованный
>>> неподконтрольных пользователю
>>> бинарём внутри
>> так то MIT, а не GPL
>> что еще вы хотели
> То ли дело андроид (или либрелинукс) -- никаких блобиков, полный контроль пользователем?тивоизация это плохо, поэтому есть более продвинутая версия лицензии, на которую ядро линукс к сожалению не перешло
Если бы перешло, в андроиде использовали бы другое ядро. Sony использует freebsd в своих консолях, и Google так же бы смог
> Если бы перешло, в андроиде использовали бы другое ядро. Sony использует freebsd
> в своих консолях, и Google так же бы смогкто знает, а может не было бы такой дикой тивоизации
можно только гадать
> Не приведёт ли это в итоге в внедрению сопроцессоров для безопасности,
> но неподконтрольных пользователю и ОСи и с бинарём внутри?Ты сейчас Intel Management Engine описал. Который есть во всех компах на интеле с примерно 2010 года. Вообще всех. Повально. В некоторых оно явно маркетуется как vPro/AMT, но урезанным вариантом снабжены ВООБЩЕ ВСЕ. А теперь вот и амд стало завидно - и все эти ryzen и epyc с PSP в комплекте, для вашей "безопасности". Которую предлагается доверить непонятному процессорному ядру, выполняющему хрен знает какой код. Как вы и написали. Только это без всяких RISC-V сделали. Интель вообще использовал какой-то малоизвестный ARC4 для этого. Впрочем gcc для него есть, рутковска даже "ring -3" бэкдор демонстрировала, прорубившись в ME через баги в его прошивке своим кодом прям из x86.
о господи, ну зачем
копирасты со своей тивизацией -- ни как не успокоются
> Применение аппаратных анклавов может рассматриваться как альтернатива применению для защиты вычислений методов на основе гомоморфного шифрования или протоколов конфиденциального вычисления, но в отличие от данных технологий анклав практически не влияет на производительность вычислений с конфиденциальными данными и существенно упрощает разработкуа если этой хренью не заниматься -- то разработка ЕЩЁ сильнее упрощается :-) .. и конфидециальности становится только лучше
А чем плох TEE, если спецификация открыта?
Что-то не пойму местных коментаторов.
В 90+% случаев это решение будет запроприетарено или в лучшем случае залочено на левые ключи, то есть наличие подобной штуковины в проце будет несколько безопаснее проприетарных решений, но вместе с тем приемлемой защиты она дать тоже не сможет.
Чтобы что-то адекватное вышло нужен копилефт + защита от тивоизации как в GPLv3.
там где производитель захочет внедрить проприетарную анальноогороженную реализацию он это сделает не зависимо от того будет у вас копилефт или нет. даже законодательные запреты тут никак не помешают.
> В 90+% случаев это решение будет запроприетарено или в лучшем случае залочено на левые ключиТак голосуй рублем и баксом за тех кто играет честно и не обжуливает. Такие будут. Их уже появляется.
> Чтобы что-то адекватное вышло нужен копилефт + защита от тивоизации как в GPLv3.
Как бы да, но политика вендора все же роялит. Жулье и с GPLем может попытаться протиснуться. Собственно GPLv3 появился потому что жулье нашло в GPLv2 лазейку.
Местные комментаторы на любое впервые увиденное слово так реагируют.
Напоминает историю с открытым uefi
Очень нужно. Кто в теме, скажите а поночтью программно теоретически такое возможно реализовать на обычных процессорах?
В статье прямо указаны альтернативы - гомоморфное шифрование или протоколы конфиденциального вычисления. Вся суть анклава - в отдельности от "обычного поцессора".
Всё это хорошо пока на бумаге, а по факту производители начнут сувать в него свой код который будет "шпионить" ... возможно будет выполнять иные паразитные функции... либо как обычно залочат использование сторонних ОС..имхо, практика показывает что такие вещи обычно во вред юзают..
>Анклав (TEE, Trusted Execution Environment) подразумевает предоставление процессором специальной изолированной области, которая позволяет вынести часть функциональности приложений и операционной системы в отдельное окружение, содержимое памяти и выполняемый код в котором недоступны из основной системы, независимо от уровня имеющихся привилегий.Неверно. User-controlled TEE - это не TEE. TEE только тогда TEE, когда он - как Первый Отдел - вредит интересам собственника, ему не подчиняется, за ним шпионит и хрен его оттуда выкинешь.
Эээ… Стоять! Какой TEE?!? SIMD хотя бы какой-то в реализованных версиях ISA есть? Где векторизация, где контроль кеша? Олоэ! Это не x86, это RISC-V! Хорош всякое блестящее в рот тянуть!
Всё под контролем анон. Векторизация слишком усложняет разработку.