The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Первая открытая реализация анклава для аппаратно изолированных окружений

11.12.2018 13:47

Представлен первый выпуск проекта Keystone, в рамках которого подготовлен набор спецификаций и программных компонентов для встраивания функциональности защищённых анклавов в чипы на базе архитектуры RISC-V. Наработки проекта распространяются под лицензией BSD. Проект развивается исследовательской группой из Калифорнийского университета в Беркли и Массачусетского технологического института.

Анклав (TEE, Trusted Execution Environment) подразумевает предоставление процессором специальной изолированной области, которая позволяет вынести часть функциональности приложений и операционной системы в отдельное окружение, содержимое памяти и выполняемый код в котором недоступны из основной системы, независимо от уровня имеющихся привилегий. Для своего выполнения в анклав могут перемещаться реализации различных алгоритмов шифрования, функции обработки закрытых ключей и паролей, процедуры аутентификации, код для работы с конфиденциальными данными.

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

Keystone может рассматриваться как открытая альтернатива таким решениям, как Intel SGX (Software Guard Extensions), ARM TrustZone и AMD PSP (Platform Security Processor). Достоинством предлагаемого открытого решения является полная доступность для аудита на всех уровнях, в отличие от вышеупомянутых проприетарных решений, полагающихся на принцип "security by obscurity" (безопасность через скрытие внутренней реализации). Как показала практика, подход основанный на ограничении не оградил Intel SGX, ARM TrustZone и AMD PSP от критических уязвимостей, сводящих на нет всю предоставляемую защиту.

Разработанные в рамках проекта Keystone спецификации позволяют интегрировать функциональность анклава в любой процессор на базе архитектуры RISC-V с минимальным числом вносимых изменений, обеспечивающих аппаратную изоляцию. Изменения касаются обеспечения физической изоляции доступа к памяти и изоляции таблиц страниц памяти. Для защиты от физических атак (анализ чипов памяти) содержимое памяти анклава и передаваемые по шине адреса шифруются. Для защиты от атак по сторонним каналам применяется полностью изолированная архитектура.

Для разработки приложений, выносящих часть функциональности и данных в анклав, предлагается специальный SDK. Проектом также развивается модифицированный вариант ядра Linux, минимальный runtime, загрузчик с поддержкой верификации загружаемого кода по цифровой подписи, специальное программное окружение, формирующие операционную систему анклава, набор утилит для верификации окружений и генерации цифровых подписей. Для тестирования разрабатываемых анклавов предоставляются эмулятор на базе QEMU и аппаратный симулятор на базе FireSim, использующий платы FPGA.

  1. Главная ссылка к новости (https://keystone-enclave.org/#...)
  2. OpenNews: Linux Foundation и RISC-V Foundation объединили усилия по продвижению архитектуры RISC-V
  3. OpenNews: Проект Libre RISC-V развивает свободный GPU
  4. OpenNews: Уязвимости в реализации аппаратно изолированных окружений TrustZone
  5. OpenNews: Компания Intel открыла компоненты для использования технологии защиты SGX в Linux
  6. OpenNews: Google анонсировал Asylo, универсальный фреймворк для защищённых анклавов
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/49760-keystone
Ключевые слова: keystone, enclave, risc, sgx, limit
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (29) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, кировлес (?), 14:30, 11/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    Походит на имеи всякие. Надо ли это? Не приведёт ли это в итоге в внедрению сопроцессоров для безопасности, но неподконтрольных пользователю и ОСи и с бинарём внутри?
     
     
  • 2.2, Annoynymous (ok), 14:36, 11/12/2018 [^] [^^] [^^^] [ответить]  
  • +8 +/
    В итоге? Это происходит уже лет 15.
     
     
  • 3.8, eganru (?), 15:25, 11/12/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    [i]Это происходит уже лет 15.[/i] - со слоганом "какать в рот качественно".
    Увы.
     
  • 2.10, annual slayer (?), 15:31, 11/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > неподконтрольных пользователю
    > бинарём внутри

    так то MIT, а не GPL

    что еще вы хотели

     
     
  • 3.11, annual slayer (?), 15:32, 11/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    тьфу, BSD, но с митом было бы так же
     
  • 3.23, Анонн (?), 19:49, 11/12/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> неподконтрольных пользователю
    >> бинарём внутри
    > так то MIT, а не GPL
    > что еще вы хотели

    То ли дело андроид (или либрелинукс) -- никаких блобиков, полный контроль пользователем?

     
     
  • 4.25, Аноним (25), 20:27, 11/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну как бы allwinner GPLным uboot с GPLным линем загружается и как бы это полный контроль над железкой. Совсем без блоботни.
     
     
  • 5.27, Анонн (?), 20:58, 11/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну как бы allwinner GPLным uboot с GPLным линем загружается и как
    > бы это полный контроль над железкой. Совсем без блоботни.

    Еще вспомним тинкпады 10 летней давности, на которых можно загрузить либребутом либрелинукс.
    Из этого делаем вывод, что есть полный контроль на мобильной и домашнестацинонарной (если взять W модель) платформе! Профит!

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


     
     
  • 6.29, annual slayer (?), 21:41, 11/12/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    но это хотя бы какои-то попытки двигаться в правильном направлении, лучше чем совсем сдаваться
     
  • 5.31, fi (ok), 15:11, 12/12/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    первичный загрузчик allwinner все же blob - хотя уже и дешифрованный
     
  • 4.28, annual slayer (?), 21:40, 11/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >>> неподконтрольных пользователю
    >>> бинарём внутри
    >> так то MIT, а не GPL
    >> что еще вы хотели
    > То ли дело андроид (или либрелинукс) -- никаких блобиков, полный контроль пользователем?

    тивоизация это плохо, поэтому есть более продвинутая версия лицензии, на которую ядро линукс к сожалению не перешло

     
     
  • 5.34, Аноним (34), 07:03, 19/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Если бы перешло, в андроиде использовали бы другое ядро. Sony использует freebsd в своих консолях, и Google так же бы смог
     
     
  • 6.35, annual slayer (?), 15:14, 19/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Если бы перешло, в андроиде использовали бы другое ядро. Sony использует freebsd
    > в своих консолях, и Google так же бы смог

    кто знает, а может не было бы такой дикой тивоизации

    можно только гадать

     
  • 2.24, Аноним (25), 20:25, 11/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Не приведёт ли это в итоге в внедрению сопроцессоров для безопасности,
    > но неподконтрольных пользователю и ОСи и с бинарём внутри?

    Ты сейчас Intel Management Engine описал. Который есть во всех компах на интеле с примерно 2010 года. Вообще всех. Повально. В некоторых оно явно маркетуется как vPro/AMT, но урезанным вариантом снабжены ВООБЩЕ ВСЕ. А теперь вот и амд стало завидно - и все эти ryzen и epyc с PSP в комплекте, для вашей "безопасности". Которую предлагается доверить непонятному процессорному ядру, выполняющему хрен знает какой код. Как вы и написали. Только это без всяких RISC-V сделали. Интель вообще использовал какой-то малоизвестный ARC4 для этого. Впрочем gcc для него есть, рутковска даже "ring -3" бэкдор демонстрировала, прорубившись в ME через баги в его прошивке своим кодом прям из x86.

     

  • 1.4, Xasd5 (?), 15:01, 11/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    о господи, ну зачем
     
  • 1.5, Xasd5 (?), 15:05, 11/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    копирасты со своей тивизацией -- ни как не успокоются
     
  • 1.6, Xasd5 (?), 15:09, 11/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > Применение аппаратных анклавов может рассматриваться как альтернатива применению для защиты вычислений методов на основе гомоморфного шифрования или протоколов конфиденциального вычисления, но в отличие от данных технологий анклав практически не влияет на производительность вычислений с конфиденциальными данными и существенно упрощает разработку

    а если этой хренью не заниматься -- то разработка ЕЩЁ сильнее упрощается :-) .. и конфидециальности становится только лучше

     
  • 1.12, хотел спросить (?), 15:57, 11/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А чем плох TEE, если спецификация открыта?
    Что-то не пойму местных коментаторов.
     
     
  • 2.15, DerRoteBaron (ok), 16:20, 11/12/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В 90+% случаев это решение будет запроприетарено или в лучшем случае залочено на левые ключи, то есть наличие подобной штуковины в проце будет несколько безопаснее проприетарных решений, но вместе с тем приемлемой защиты она дать тоже не сможет.
    Чтобы что-то адекватное вышло нужен копилефт + защита от тивоизации как в GPLv3.
     
     
  • 3.21, nevfr (?), 18:56, 11/12/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    там где производитель захочет внедрить проприетарную анальноогороженную реализацию он это сделает не зависимо от того будет у вас копилефт или нет. даже законодательные запреты тут никак не помешают.
     
  • 3.26, Аноним (25), 20:31, 11/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > В 90+% случаев это решение будет запроприетарено или в лучшем случае залочено на левые ключи

    Так голосуй рублем и баксом за тех кто играет честно и не обжуливает. Такие будут. Их уже появляется.

    > Чтобы что-то адекватное вышло нужен копилефт + защита от тивоизации как в GPLv3.

    Как бы да, но политика вендора все же роялит. Жулье и с GPLем может попытаться протиснуться. Собственно GPLv3 появился потому что жулье нашло в GPLv2 лазейку.

     
  • 2.18, Аноним (-), 17:53, 11/12/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Местные комментаторы на любое впервые увиденное слово так реагируют.
     

  • 1.17, Аноним (17), 17:28, 11/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Напоминает историю с открытым uefi
     
  • 1.19, Аноним (19), 18:04, 11/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Очень нужно. Кто в теме, скажите а поночтью программно теоретически такое возможно реализовать на обычных процессорах?
     
     
  • 2.20, Иван (??), 18:36, 11/12/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В статье прямо указаны альтернативы - гомоморфное шифрование или протоколы конфиденциального вычисления. Вся суть анклава - в отдельности от "обычного поцессора".
     

  • 1.22, svsd_val (ok), 19:32, 11/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Всё это хорошо пока на бумаге, а по факту производители начнут сувать в него свой код который будет "шпионить" ... возможно будет выполнять иные паразитные функции... либо как обычно залочат использование сторонних ОС..

    имхо, практика показывает что такие вещи обычно во вред юзают..

     
  • 1.30, Аноним (30), 00:23, 12/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Анклав (TEE, Trusted Execution Environment) подразумевает предоставление процессором специальной изолированной области, которая позволяет вынести часть функциональности приложений и операционной системы в отдельное окружение, содержимое памяти и выполняемый код в котором недоступны из основной системы, независимо от уровня имеющихся привилегий.

    Неверно. User-controlled TEE - это не TEE. TEE только тогда TEE, когда он -  как Первый Отдел - вредит интересам собственника, ему не подчиняется, за ним шпионит и хрен его оттуда выкинешь.

     
  • 1.32, Аноним (32), 15:58, 12/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Эээ… Стоять! Какой TEE?!? SIMD хотя бы какой-то в реализованных версиях ISA есть? Где векторизация, где контроль кеша? Олоэ! Это не x86, это RISC-V! Хорош всякое блестящее в рот тянуть!
     
     
  • 2.33, Кеша (?), 08:20, 13/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Всё под контролем анон. Векторизация слишком усложняет разработку.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру