Ваша информация не соответствует действительности.
Дело в том, что я работаю в Анкаде и лично занимаюсь разработкой этих замков. Сейчас мы сосредоточились на том, что делаем интегрированные в матери замки, которые позволяют противостоять гораздо большему набору угроз. И они работают без CSM'а. Вся оболочка у них выполнена в виде модулей UEFI.
Все сертифицированные нами PCI'ные замки действительно CSM'ные. На то есть причины, связанные с безопасностью, и эта статья отлично описывает одну из них. Технически, PCI замок без CSM'а у нас давно есть, другое дело, что он никому не нужен и поэтому мы его не стремимся сертифицировать и выводить на рынок.
Неужели вы думаете, что это требует серьезных телодвижений? Единственное, что нужно, чтобы интегрированный на мамку замок стал PCI'ным — добавить UEFI'шный OptionROM.
Про 50 разработчиков я ни разу от них не слышал, так что ничего ответить на это не могу. Может быть человек не правильно понял ваш вопрос или вы его ответ?
1) Да, куплены исходники всего, так что Крафтвей хорошо вложился в это дело.
2) У ФСБ методика исследований строится на бинарниках, а исходники используются только как помощь. Там действительно множество спецов, копаются в бинарниках и пишут документацию. Поэтому сертификация UEFI стоит больших денег и занимает минимум год.
Я лично знаком с большинством разработчиков Крафтвея, там есть очень грамотные ребята. Они не скрывают, что на самом деле они не разрабатывают целиком биос, они только допиливают AMI'шный и пишут модули под него. А также они провели сертификацию этого биоса в ФСБ, что довольно дорогостоящий и длительный процесс.
Только один — это какой? У Анкада таких минимум два :) (правда только один сертифицирован, второй в процессе)
На всех выставках Крафтвей действительно позиционирует мамки как будто Анкад тут не при чем. В политику я стараюсь не лезть, но меня это тоже неприятно удивляет.
Ну мы давно используем его для защиты от DMA атак, но, правда, не из UEFI, а из своего варианта Linux+KVM.
Тут проблема в том, что IOMMU работает далеко не на всех мамках, даже если чипсет его поддерживает. Я, если честно, пока не копал почему. А еще многие мамки имеют 1-2 IOMMU домена на все устройства, т.е. нельзя для конкретного устройства разрешить запись куда-то, а для другого запретить, что довольно уныло :(
На сколько я понял вы сами делаете мамки, так что для вас эта проблема не очень актуальна.
Все правильно. Мы тоже написали сами и поэтому ей верим, а заказчики верят, потому что нашу прошивку сертифицровали в ФСБ, где ее исследовали на закладки и уязвимости в течение полу года, а заказчики верят ФСБ. Но, конечно, каждый конкретный пользователь сам для себя решает кому верить, а кому нет. Если что, прошивку этого чипа можно также как UEFI слить через программатор (или даже через USB, если есть права, но мы же не верим тому, какой вариант себя она выдаст) и исследовать :)
Кстати, его прошивка далеко не всегда в той же флешке, что и UEFI. Бывают с собственной флешкой. А еще он много чего может кроме измерений температуры, например DMA куда-нибудь через LPC, так что довольно опасная для атак штука.
Спасибо, отличная статья :)
Только, по-моему EC — это Embedded Controller, а не Environmental Controller (например мы используем какой-то Nuvoton, типа NPCE791E)
Это честно не реклама, просто рассказываю про технику вопроса
Кстати, для более серьезных применений, есть специальные мамки, например: www.kraftway.ru/products/6/tonkie-klienty/kraftway-credo-vv25/#characteristics (есть и другие, даже планшет и сервер :) )
Если приглядеться в данной мамке есть АПМДЗ «Криптон-витязь» (детище фирмы Анкад). Это микроконтроллер, который управляет всеми питаниями материнки, аутентфицирует пользователей и т.д, а еще он мониторит линии SPI и позволяет разрешать/запрещать запись с гранулярностью 32 бита.
А еще у него две SPI флешки и он может сначала подставлять свою, полностью защищенную от записи, в которой есть все для аутентификации (CoreBoot + Qt) после которой происходит перезагрузка и подставляется настоящий UEFI. Поэтому он может сделать любую политику разрешения/запрета записи любых регионов флешки.
А почему никто не вспомнил про идею луны как плацдарма для постройки больших космических аппаратов? Гравитация ниже, атмосферы нет — значит гораздо дешевле доставлять массу в космос. Алюминий на луне есть. Остается его добыть, переработать и отправить в космос. Вроде еще Хайнлайн писал про катапульту для отправки с луны :) Хотя, конечно, роботы гораздо удобнее :)
Вы имеете в виду, что страница может отправить в плагин один файл, а пользователю дать почитать другой? Чем это отличается от ситуации с вирусом в браузере? Выше многократно говорилось, что единственный хороший вариант защиты канала отображения — это использование отдельного девайса с мониторчиком. Вариант похуже — программный контроль за всем и вся + комплекс административных мер.
Если мы считаем, что браузер доверенный и в нем нет закладок, то ничего не стоит из плагина проконтролировать этот момент. Например, проверить, что страничка подходит под какой-то шаблон. Можно просто отображать документ непосредственно из плагина перед подписью. На крайняк пользователь всегда может почитать исходник странички. По крайней мере, это не концептуальная проблема и с ней можно бороться. И я удивлен, что вы этого не делаете.
Все верно. Выше у меня написано, что нужны два сессионных ключа: один для защиты канала браузер-сервер, второй для защиты канала рутокен-сервер. Под взаимной аутентификацией, естественно, подразумевается еще и выроботка ключей, т.е. Mutual Authentication and Key Agreement protocol.
Кстати, предлагаю обсудить основную проблему: почему рутокен так медленно считает хеш? В чем сложность поставить процессор по-новее? Более того, я, конечно, могу ошибаться, но Ваши обороты вполне позволяют просто заказать свой чип (полузаказной) с аппаратным гостом.
Понятно, что ради небольшого проекта никто не станет заморачиваться, но глобально… Расскажите нам о Ваших планах, пожалуйста :)
Эм… Кстати, я серьезно по поводу «написать». Добавьте в статью разъясняющий дисклеймер. Мол у нас токен тормозной, хеш считает медленно. Добавить считалку хеша в драйвер/плагин не можем по юридическим причинам. Решили унести подсчет хеша на сервер. Естественно, при этом клиент должен всецело доверять серверу. Идея PKI при этом, пострадала. Приватный ключ на сервер не унесли, так как защищать его дорого, хоть и эффективней. В будущей версии (перед сертификацией) добавим взаимную аутентификацию рутокена и сервера, чтобы хоть как-то подтянуть безопасность к модели с локальным токеном.
А то какая-то не честная статья получается.
Дело в том, что я работаю в Анкаде и лично занимаюсь разработкой этих замков. Сейчас мы сосредоточились на том, что делаем интегрированные в матери замки, которые позволяют противостоять гораздо большему набору угроз. И они работают без CSM'а. Вся оболочка у них выполнена в виде модулей UEFI.
Все сертифицированные нами PCI'ные замки действительно CSM'ные. На то есть причины, связанные с безопасностью, и эта статья отлично описывает одну из них. Технически, PCI замок без CSM'а у нас давно есть, другое дело, что он никому не нужен и поэтому мы его не стремимся сертифицировать и выводить на рынок.
Неужели вы думаете, что это требует серьезных телодвижений? Единственное, что нужно, чтобы интегрированный на мамку замок стал PCI'ным — добавить UEFI'шный OptionROM.
Про 50 разработчиков я ни разу от них не слышал, так что ничего ответить на это не могу. Может быть человек не правильно понял ваш вопрос или вы его ответ?
2) У ФСБ методика исследований строится на бинарниках, а исходники используются только как помощь. Там действительно множество спецов, копаются в бинарниках и пишут документацию. Поэтому сертификация UEFI стоит больших денег и занимает минимум год.
Только один — это какой? У Анкада таких минимум два :) (правда только один сертифицирован, второй в процессе)
На всех выставках Крафтвей действительно позиционирует мамки как будто Анкад тут не при чем. В политику я стараюсь не лезть, но меня это тоже неприятно удивляет.
Тут проблема в том, что IOMMU работает далеко не на всех мамках, даже если чипсет его поддерживает. Я, если честно, пока не копал почему. А еще многие мамки имеют 1-2 IOMMU домена на все устройства, т.е. нельзя для конкретного устройства разрешить запись куда-то, а для другого запретить, что довольно уныло :(
На сколько я понял вы сами делаете мамки, так что для вас эта проблема не очень актуальна.
На сколько я понимаю, от DMA атаки можно защититься через IOMMU (VTd или AMD-Vi). Где-нибудь такое используется?
Только, по-моему EC — это Embedded Controller, а не Environmental Controller (например мы используем какой-то Nuvoton, типа NPCE791E)
www.kraftway.ru/products/6/tonkie-klienty/kraftway-credo-vv25/#characteristics (есть и другие, даже планшет и сервер :) )
Если приглядеться в данной мамке есть АПМДЗ «Криптон-витязь» (детище фирмы Анкад). Это микроконтроллер, который управляет всеми питаниями материнки, аутентфицирует пользователей и т.д, а еще он мониторит линии SPI и позволяет разрешать/запрещать запись с гранулярностью 32 бита.
А еще у него две SPI флешки и он может сначала подставлять свою, полностью защищенную от записи, в которой есть все для аутентификации (CoreBoot + Qt) после которой происходит перезагрузка и подставляется настоящий UEFI. Поэтому он может сделать любую политику разрешения/запрета записи любых регионов флешки.
Если мы считаем, что браузер доверенный и в нем нет закладок, то ничего не стоит из плагина проконтролировать этот момент. Например, проверить, что страничка подходит под какой-то шаблон. Можно просто отображать документ непосредственно из плагина перед подписью. На крайняк пользователь всегда может почитать исходник странички. По крайней мере, это не концептуальная проблема и с ней можно бороться. И я удивлен, что вы этого не делаете.
Понятно, что ради небольшого проекта никто не станет заморачиваться, но глобально… Расскажите нам о Ваших планах, пожалуйста :)
А то какая-то не честная статья получается.