Comments 21
Просто оставлю это здесь:
Researchers use Intel SGX to put malware beyond the reach of antivirus software
Processor protects malware from attempts to inspect and analyze it.
Ещё есть свежачок уже не по теме SGX Новая уязвимость Spoiler затрагивает все поколения процессоров Intel Core
А я же правильно помню, что самоподписанный SGX-анклав запустить нельзя? Только подписанный ключом, заверенным Intel?
А зачем устанавливать в сервер дополнительное оборудование для защиты кода от пользователя? Я хочу видеть код, который исполняется на моём оборудовании. Весь. Желательно, в исходниках, но если все такие жадные, то хотя бы в бинарном виде.
А вот эта железка позволяет кому-то (не мне!) запускать их код на моём железе за мой счёт без подотчётности мне.
И нафига оно сдалось? Больше DRM дьяволу DRM?
А вот эта железка позволяет кому-то (не мне!) запускать их код на моём железе за мой счёт без подотчётности мне.
И нафига оно сдалось? Больше DRM дьяволу DRM?
Запускать код, который оперирует с чувствительными данными (ключи, секреты) в ограниченной доверенной среде (облако).
А почему облако должно доверять этому коду, если этот код не может быть проинспектирован? Как так получается, что intel решает, что можно на железе исполнять, а что нет? У меня ощущение, что в этот момент под обещание «безопасные секреты» intel хочет начать торговать лицензиями на выполнение кода. Хочет — разрешает, не хочет — не разрешает.
А почему облако должно доверять этому коду, если этот код не может быть проинспектирован?
Потому что для анклавов разрешен только тот набор инструкций, которые не вызывают выход из гипервизора, не возбуждают прерывания, и не обращаются к I/O напрямую, т.е. такой код содержит только изолированную логику по обработке чувствительных данных (например, перешифровка) или защищенные проприетарные алгоритмы. за всем IO анклав обращается к коду который его породил.
А там уже можно ограничивать ввод-вывод средствами ОС и гипервизора.
У меня ощущение, что в этот момент под обещание «безопасные секреты» intel хочет начать торговать лицензиями на выполнение кода.
Да, тоже промелькнула такая мысль.
… Например, он может использовать rop для выполнения IO (выше ссылку уже приводили), расшифровывать малварь вне доступа антивирусов и, вообще, идеально подходит для хранения секретов от пользователя на его же машине.
Ну, тут, кмк, эвристику антивирусов менять. Т.е. если приложение загружает анклав и только гоняет в него сетевой трафик, а с диска только читает конфиги и персистит по разрешенным путям и только своё — это норма.
А можно мне, как владельцу оборудования, запустить там мой код? Я владелец устройства. Почему мне нужно получать согласие компании на запуск моего кода на моём же оборудовании?
Можно. Берите SDK, собирайте, запускайте.
Если вы владелец Gen6 или позднее Core процессора — у вас там этот самый SGX уже есть, и процессор вполне может выполнять одобренные анклавы от производителя ОС, поставщиков приложений и драйверов без вашего ведома.
А конкретно эта железка — для массового хостинга анклавов в облаках.
Если вы владелец Gen6 или позднее Core процессора — у вас там этот самый SGX уже есть, и процессор вполне может выполнять одобренные анклавы от производителя ОС, поставщиков приложений и драйверов без вашего ведома.
А конкретно эта железка — для массового хостинга анклавов в облаках.
Можно я уточню, если "производитель" OC — это
git clone https://git.kernel.org/
cd linux
make && make installТо чьё одобрение мне требуется, чтобы запустить в анклаве свой собственный код?
Зависит. Судя по комментарию выше и вот этому документу — возможны несколько сценариев.
1. Умолчательный. Есть SGX, нету DCAP. Можно запускать только анклавы, чьи ключи заверены Intel.
2. Developer-friendly. Поставщик ОС имеет whitelisted-ключ, и реализовал launch-анклав, который разрешает запускать любой корректно подписанный (например самоподписанный) анклав.
3. Есть SGX, есть DCAP, развернута инфраструктура приватной сертификации. Можно управлять своим корнем доверия, и самостоятельно определять ключи, для которых разрешен запуск подписанного кода.
1. Умолчательный. Есть SGX, нету DCAP. Можно запускать только анклавы, чьи ключи заверены Intel.
2. Developer-friendly. Поставщик ОС имеет whitelisted-ключ, и реализовал launch-анклав, который разрешает запускать любой корректно подписанный (например самоподписанный) анклав.
3. Есть SGX, есть DCAP, развернута инфраструктура приватной сертификации. Можно управлять своим корнем доверия, и самостоятельно определять ключи, для которых разрешен запуск подписанного кода.
Единственный способ вызвать функцию анклава — с помощью новой инструкции, выполняющей несколько защитных проверок.так что из себя представляют проверки?
весь смысл злонамеренного кода и майлвари в том что процессор/операционная система/бекдоры от интел не могут понять — кто здесь кто. Именно в определении этих проверок кроется защита.
На сколько я помню, запуск только подписанного кода уже давным давно поддерживается во всех операционных системах, и городить отельную железку для этого не нужно, и спасет это только от старого вредоносного кода, не успевшего приспособиться.
Кстати как быть с интерпретаторами? их код так же тегируется на свой чужой? А то у нас он браузеры и всякие javascript…
так что из себя представляют проверки?
Криптографическая верификация ЭЦП, обход пути сертификации до корня доверия, как в любом PKI.
запуск только подписанного кода уже давным давно поддерживается во всех операционных системах
Тут он не только подписан, еще и зашифрован, а во время выполнения еще и аппаратно изолирован от любых попыток доступа, с любого кольца. Потому и «анклав».
Кстати как быть с интерпретаторами?
Никак. Так же как раньше продолжают работать в памяти, управляемой и защищаемой ОС. Либо портировать на SGX-поддерживаемую псевдо-ОС, например, Graphene.
Шикарный костыль.
ОСь нужна человеческая.
ОСь нужна человеческая.
Sign up to leave a comment.
Intel SGX Card. Своего SGX достоин каждый сервер