Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 51
Не хватает сводной таблицы в итоге.
Исследование омномном, спасибо!
Исследование омномном, спасибо!
Буквально на днях прилетело для ноута обновление BIOS, где основным изменением был заявлен фикс SMM «Incursion» Attack. А до UEFI обновления на BIOS почти никогда не ставил.
Об этой атаке я планирую рассказать либо в следующей части, либо через одну, там нужны подробности, чтобы понять, в чем состоит уязвимость и почему ее нужно закрыть. Если не хотите ждать историю в моем изложении на русском — вот слайды с презентации наших ребят из Intel ATR на ReCon 2015, там все расписано в подробностях.
Я не видел пока этих новых машин, но на тех, что видел, BootGuard был очень забавно настроен — сами модули присуствуют, но ни verifed boot, ни measured boot не включены, и в итоге система только выглядит защищенной. Буду обновлять железо — надо будет посмотреть.
Про МЕ — добавить мне почти нечего. Последний х86-процессор для ноутбука без PSP — eKabini, все более новые тоже имеют на борту аналог ME, который отключить еще сложнее и данных по нему еще меньше. Да и сама архитектура — далеко не мечта параноика.
Про МЕ — добавить мне почти нечего. Последний х86-процессор для ноутбука без PSP — eKabini, все более новые тоже имеют на борту аналог ME, который отключить еще сложнее и данных по нему еще меньше. Да и сама архитектура — далеко не мечта параноика.
По моим ощущениям примерно так и есть, только вот у платформ Phoenix и Insyde, которые используют лидеры (т.е. Dell, Lenovo и HP), свои недостатки имеются, и NVRAM как разваливался, так и разваливается…
Про Apple мне сказать нечего — не интересовался, но на вид из UEFITool'а — кошмарно, think different во все поля, SecureBoot'а нет, OROMы вредоносные поют и пляшут.
Про платы Intel — она у тебя старая просто, сейчас уже очень мало кто выпускает обновления безопасности для «неактуальных» платформ — это банально дорого, т.к. все тестировать по новой.
Про Apple мне сказать нечего — не интересовался, но на вид из UEFITool'а — кошмарно, think different во все поля, SecureBoot'а нет, OROMы вредоносные поют и пляшут.
Про платы Intel — она у тебя старая просто, сейчас уже очень мало кто выпускает обновления безопасности для «неактуальных» платформ — это банально дорого, т.к. все тестировать по новой.
Ты напиши, кстати, чего-нибудь из своего опыта, а то с этой странной кармической системой тебе даже плюс поставить невозможно.
Немного ясности про ножку #WP на SPI флешках. Она не совсем защита от записи, каковой была во времена параллельных/FWH/LPC флешек.
Разъясню подробнее:
1) SPI флешка разделена аппаратно на регионы, каждый из которых можно заблокировать на запись
2) У неё имеются свои регистры конфигурации
3) Каждый регион имеет свой бит защиты
4) Регистр, в котором лежат эти биты имеет свой собственный бит защиты
5) Пока бит защиты регистра не взведён, защиту регионов можно спокойно изменять, как только он взводится — попытки снятия бит защиты регионов становятся бесполезными.
Про бит защиты регистра битов защиты регионов флешки (масло маслянное получилось)
1) Будучи взведённым этот бит запрещает модификацию регистра защиты
2) Будучи взведённым он запрещает модификацию самого себя
Кажется, что всё отлично, блокируй регионы, далее взводи этот бит и усё хоккей. А вот и индейская народная изба фигвам:
Та самая ножка #WP какраз влияет на второй пункт, если на ней находится земля — всё окей, перевод бита защиты регистров запрещён, но если подать питание, то бит спокойно можно будет перезаписать нулём.
Почему это надо упомянуть — если реализовать защиту «классическим»(ну как во времена Pentium 2/3) путём, забив на программную часть защиты самой флешки, то никакой защиты мы не получим, регионы то не заблокированы, заблокирована только возможность сброса бита защиты регистров, который мы и не взвели.
П.С. Это именно регистры самой флешки, к чипсету они никакого отношения не имеют.
П.П.С. Действительно для продукции SST, Macronix, Winbond, с другими не работал, но у этой тройки даже адреса все совпадали, видать всё стандартно.
Разъясню подробнее:
1) SPI флешка разделена аппаратно на регионы, каждый из которых можно заблокировать на запись
2) У неё имеются свои регистры конфигурации
3) Каждый регион имеет свой бит защиты
4) Регистр, в котором лежат эти биты имеет свой собственный бит защиты
5) Пока бит защиты регистра не взведён, защиту регионов можно спокойно изменять, как только он взводится — попытки снятия бит защиты регионов становятся бесполезными.
Про бит защиты регистра битов защиты регионов флешки (масло маслянное получилось)
1) Будучи взведённым этот бит запрещает модификацию регистра защиты
2) Будучи взведённым он запрещает модификацию самого себя
Кажется, что всё отлично, блокируй регионы, далее взводи этот бит и усё хоккей. А вот и индейская народная изба фигвам:
Та самая ножка #WP какраз влияет на второй пункт, если на ней находится земля — всё окей, перевод бита защиты регистров запрещён, но если подать питание, то бит спокойно можно будет перезаписать нулём.
Почему это надо упомянуть — если реализовать защиту «классическим»(ну как во времена Pentium 2/3) путём, забив на программную часть защиты самой флешки, то никакой защиты мы не получим, регионы то не заблокированы, заблокирована только возможность сброса бита защиты регистров, который мы и не взвели.
П.С. Это именно регистры самой флешки, к чипсету они никакого отношения не имеют.
П.П.С. Действительно для продукции SST, Macronix, Winbond, с другими не работал, но у этой тройки даже адреса все совпадали, видать всё стандартно.
Все верно, два чая этому господину. Я опустил эти подробности, и вот почему: БИОС, подготовленный для RO, при запуске проверяет биты SRP0-1 и BP0-2 в регистре STATUS и если первые оба сброшены (т.е. #WP не работает), то он ставит все BP (защитив таким образом всю прошивку целиком) и SRP0 (чтобы сбросить их можно было только установкой 1 на #WP). В итоге «незащищенным» такой БИОС, при условии #WP=0, остается ровно до инициализации драйвера SPI, а до этого ничего писать все равно невозможно.
Предложу то же самое, что и d_olex'у — напиши что-нибудь из своего опыта, а то хочу поставить плюс в карму — и не могу.
Уважаемое НЛО, я все понимаю, но ситуация, когда карму можно только понизить — отвратительна, и мотивирует она не на написание постов, а на игнорирование Хабра. Сделайте с этим что-нибудь, пожалуйста.
Уважаемое НЛО, я все понимаю, но ситуация, когда карму можно только понизить — отвратительна, и мотивирует она не на написание постов, а на игнорирование Хабра. Сделайте с этим что-нибудь, пожалуйста.
Джампер можно реализовать, и прямо в статье написано, как именно, но этого никто не делает — в текущих условиях это дорого и мало кому нужно.
Если вас защита задевает — покупайте продукты без нее, их море. Только вот доверять ОС, которая, в основном, написана вполне средними программистами 10+ лет назад на С или С++ — решительно невозможно.
Проблема защиты от физического доступа — административная, а не системная, и ключи в кремнии решают не проблему «злой хакер Семен сменил все чипы, и таким образом отключил защиту», а «измененный злым хакером Семеном образ БИОСа не запустился вообще»
Если говорить про аппаратные закладки и т.п., то единственный выход — свободное железо. OpenRISC, вот это все. Пока железо закрытое — с аппаратными закладками надо как-то жить.
Если вас защита задевает — покупайте продукты без нее, их море. Только вот доверять ОС, которая, в основном, написана вполне средними программистами 10+ лет назад на С или С++ — решительно невозможно.
Проблема защиты от физического доступа — административная, а не системная, и ключи в кремнии решают не проблему «злой хакер Семен сменил все чипы, и таким образом отключил защиту», а «измененный злым хакером Семеном образ БИОСа не запустился вообще»
Если говорить про аппаратные закладки и т.п., то единственный выход — свободное железо. OpenRISC, вот это все. Пока железо закрытое — с аппаратными закладками надо как-то жить.
Проблема в том что у нас раньше был SRAM для настроек и отдельно чип EEPROM для кода биосА, запрещаешь запись во второй аппаратно и ништяк. Но… маркетологи решили зачем нам две микросхемы давайте удешевим и поставим одну! И понеслось… в одном чипе теперь хранятся и программные коды и переменные настройки. Теперь получается что поставить защиту чисто на чип уже нельзя — код мы защитим но и сделаем невозможным запись настроек. Дальше защита пошла уже программная — устанавливаются биты защиты от записи для отдельных областей памяти чипа… но это уже не то что механический джампер на плате.
Некоторые производители материнских плат для десктопов
Зато Intel выпускает обновления даже для снятых с производства Desktop Boards.
CodeRush спасибо за содержательную статью. Сложный материал подан весьма просто, а шутки(понравилось про DoS с отвётверткой) в тексте делают его более выразительней. Странно что никто в коментариях не вспомнил про EDK vector от Hacking Team — uefi бэкдор-прошивку на базе tianocore. В любом случае будет интересно прочитать продолжение.
PS.: надеюсь в следующей статье вы затронете несколько паблик векторов в PoC, которые доступны в настоящее время :)
PS.: надеюсь в следующей статье вы затронете несколько паблик векторов в PoC, которые доступны в настоящее время :)
Затрону, конечно, но не сразу, сначала надо рассказать, что атакуют, а потом уже — как.
Про бэкдор HT не вспомнили по причине его примитивности. Понятно, что задачу свою он выполняет, но лучше, чем ThrDev, я о нем, наверное, не скажу.
Про бэкдор HT не вспомнили по причине его примитивности. Понятно, что задачу свою он выполняет, но лучше, чем ThrDev, я о нем, наверное, не скажу.
Hacking Team's EFI «rootkit» makes me sad. It's like buying a Bugatti Veyron and replacing the engine with a box of dildos.
Спасибо, отличная статья :)
Только, по-моему EC — это Embedded Controller, а не Environmental Controller (например мы используем какой-то Nuvoton, типа NPCE791E)
Только, по-моему EC — это Embedded Controller, а не Environmental Controller (например мы используем какой-то Nuvoton, типа NPCE791E)
Это честно не реклама, просто рассказываю про технику вопроса
Кстати, для более серьезных применений, есть специальные мамки, например:
www.kraftway.ru/products/6/tonkie-klienty/kraftway-credo-vv25/#characteristics (есть и другие, даже планшет и сервер :) )
Если приглядеться в данной мамке есть АПМДЗ «Криптон-витязь» (детище фирмы Анкад). Это микроконтроллер, который управляет всеми питаниями материнки, аутентфицирует пользователей и т.д, а еще он мониторит линии SPI и позволяет разрешать/запрещать запись с гранулярностью 32 бита.
А еще у него две SPI флешки и он может сначала подставлять свою, полностью защищенную от записи, в которой есть все для аутентификации (CoreBoot + Qt) после которой происходит перезагрузка и подставляется настоящий UEFI. Поэтому он может сделать любую политику разрешения/запрета записи любых регионов флешки.
www.kraftway.ru/products/6/tonkie-klienty/kraftway-credo-vv25/#characteristics (есть и другие, даже планшет и сервер :) )
Если приглядеться в данной мамке есть АПМДЗ «Криптон-витязь» (детище фирмы Анкад). Это микроконтроллер, который управляет всеми питаниями материнки, аутентфицирует пользователей и т.д, а еще он мониторит линии SPI и позволяет разрешать/запрещать запись с гранулярностью 32 бита.
А еще у него две SPI флешки и он может сначала подставлять свою, полностью защищенную от записи, в которой есть все для аутентификации (CoreBoot + Qt) после которой происходит перезагрузка и подставляется настоящий UEFI. Поэтому он может сделать любую политику разрешения/запрета записи любых регионов флешки.
Я использую старую расшифровку аббревиатуры EC, т.к. сейчас слово embedded уже настолько везде, что практически потеряло значение. А так — сразу понятно, чем занимается EC — температуры меряет и вентиляторами управляет.
Кстати, его прошивка далеко не всегда в той же флешке, что и UEFI. Бывают с собственной флешкой. А еще он много чего может кроме измерений температуры, например DMA куда-нибудь через LPC, так что довольно опасная для атак штука.
Намного лучше, когда он с собственной флешкой, т.к. в таком случае через него невозможна атака на ее содержимое. Я знаю, что EC — та еще гадость в смысле безопасности, но крипточип с закрытой прошивкой, как в вашем примере выше, тоже не очень-то располагает к безграничному доверию. Мы используем в качестве BMC обычный ARM Cortex M4 производства Texas Instruments, подключенный через LPC, и прошивку для него мы написали сами, поэтому я уверен, что в ней нет ни бэкдоров, ни каких-то посторонних возможностей.
Все правильно. Мы тоже написали сами и поэтому ей верим, а заказчики верят, потому что нашу прошивку сертифицровали в ФСБ, где ее исследовали на закладки и уязвимости в течение полу года, а заказчики верят ФСБ. Но, конечно, каждый конкретный пользователь сам для себя решает кому верить, а кому нет. Если что, прошивку этого чипа можно также как UEFI слить через программатор (или даже через USB, если есть права, но мы же не верим тому, какой вариант себя она выдаст) и исследовать :)
Это хорошо, что прошивку можно слить и исследовать, а то обычно залочат фьюзами и все. Если клиенты доверяют — это хорошо. Нам тоже доверяют пока, но у нас BMC никаких функций безопасности не выполняет, таким было требование большинства клиентов в самом начале, чтобы не допустить side channel атак через него.
Про вашу «не рекламу» — стёба ради допроситесь к крафтвею на экскурсию, интересно просто, какое число «разработчиков биоса, которые у них трудятся» они вам скажут.
П.С. На сегодняшний день только один АПМДЗ умеет в UEFI, все остальные работают только в CSM-е. Что это означает для устройства защиты я пожалуй говорить не буду, а то на ум приходит только слово из пяти букв, начинающееся на х.
П.П.С. На всяких новых электрониках всё, что показывал крафтвей шло без анкада.
П.С. На сегодняшний день только один АПМДЗ умеет в UEFI, все остальные работают только в CSM-е. Что это означает для устройства защиты я пожалуй говорить не буду, а то на ум приходит только слово из пяти букв, начинающееся на х.
П.П.С. На всяких новых электрониках всё, что показывал крафтвей шло без анкада.
Я лично знаком с большинством разработчиков Крафтвея, там есть очень грамотные ребята. Они не скрывают, что на самом деле они не разрабатывают целиком биос, они только допиливают AMI'шный и пишут модули под него. А также они провели сертификацию этого биоса в ФСБ, что довольно дорогостоящий и длительный процесс.
Только один — это какой? У Анкада таких минимум два :) (правда только один сертифицирован, второй в процессе)
На всех выставках Крафтвей действительно позиционирует мамки как будто Анкад тут не при чем. В политику я стараюсь не лезть, но меня это тоже неприятно удивляет.
Только один — это какой? У Анкада таких минимум два :) (правда только один сертифицирован, второй в процессе)
На всех выставках Крафтвей действительно позиционирует мамки как будто Анкад тут не при чем. В политику я стараюсь не лезть, но меня это тоже неприятно удивляет.
Скрывать факт работы с IBV глупо — тайна продержится до первого дампа. :)
Насчет сертификации в ФСБ — там же BLOB'ов штук десять как минимум, CSM16, куча расширений к нему, OROM'ы, драйвер PXE, драйвер SATA, драйвер ФС FAT и т.п., неужели пришлось у AMI исходники покупать, или прямо бинарем и сертифицировали? Я не очень разбираюсь во всей этой кухне (и не очень хочу, если честно), но со стороны кажется, что в «сертификации в ФСБ» больше бумажной работы, чем инженерной.
Насчет сертификации в ФСБ — там же BLOB'ов штук десять как минимум, CSM16, куча расширений к нему, OROM'ы, драйвер PXE, драйвер SATA, драйвер ФС FAT и т.п., неужели пришлось у AMI исходники покупать, или прямо бинарем и сертифицировали? Я не очень разбираюсь во всей этой кухне (и не очень хочу, если честно), но со стороны кажется, что в «сертификации в ФСБ» больше бумажной работы, чем инженерной.
1) Да, куплены исходники всего, так что Крафтвей хорошо вложился в это дело.
2) У ФСБ методика исследований строится на бинарниках, а исходники используются только как помощь. Там действительно множество спецов, копаются в бинарниках и пишут документацию. Поэтому сертификация UEFI стоит больших денег и занимает минимум год.
2) У ФСБ методика исследований строится на бинарниках, а исходники используются только как помощь. Там действительно множество спецов, копаются в бинарниках и пишут документацию. Поэтому сертификация UEFI стоит больших денег и занимает минимум год.
Странный вопрос, но все же задам. Зачем ФСБ собственно ковыряться в бинарях когда на руках есть сорсы?
Можно ведь собрать из сорсов билд и задиффать к примеру с оригиналом, посмотреть что изменилось.
Это по теме трудозатрат(временных и денежных издержек) было сказано в первую очередь.
Можно ведь собрать из сорсов билд и задиффать к примеру с оригиналом, посмотреть что изменилось.
Это по теме трудозатрат(временных и денежных издержек) было сказано в первую очередь.
А как ФСБ получит все исходники скажем на новый интеловский сервер?
Вероятно ваше замечание право, однако выше речь шла о том, что исходники используются как помощь при реверсе бинарей, т.е предположительно они существуют.
Слышал также что после инцидента со Stuxnet многие спецслужбы стали более внимательно относиться к иностранному оборудованию(для особоважных объектов страны) и ПО для него. Для ПО обычно требуют сорсы под NDA, для железа вероятно тоже(требуют помимо даташита исходный код для железа(Verilog/HDL/VHDL/SystemC/и т.п)). Возможно я где то не прав, если что поправьте.
Слышал также что после инцидента со Stuxnet многие спецслужбы стали более внимательно относиться к иностранному оборудованию(для особоважных объектов страны) и ПО для него. Для ПО обычно требуют сорсы под NDA, для железа вероятно тоже(требуют помимо даташита исходный код для железа(Verilog/HDL/VHDL/SystemC/и т.п)). Возможно я где то не прав, если что поправьте.
На то есть несколько причин, некоторые технические, некоторые исторические:
1) Действительно, не всегда бывают исходники.
2) Часто исходники собираются компилятором, от которого нет исходников или который никто не исследовал.
3) Существует множество способов спрятать закладку в исходниках так, чтобы при простом их чтении ее было очень сложно найти, например, использовать особенности оптимизатора или архитектуры.
4) В плане поиска сложных закладок или дырок динамический анализ гораздо круче статического, а он, как правило, работает с бинарниками.
5) У них существует набор разработаных и утвержденных методик анализа биосов. Эти методики разрабатывались тогда, когда исходников от биосов еще не было, а сами биосы были небольшими. Методик приходится придерживаться (скорее духа, чем буквы). Разработка и согласование новой методики — это очень длительный процесс, в котором участвует много людей, он требует огромного количества писанины, переучивания людей и т.д.
Кстати, сертификация обычного ПО проходит по исходникам, но сертификат выдается на бинарник. Поэтому бинарник должен собираться в контролируемых ФСБ условиях или надо доказывать, что он собран из тех исходников, которые анализировал ФСБ.
По поводу исходников для спецслужб: большинство крупных компаний действительно выдает исходники своих продуктов для сертификации спецслужбам. На сколько мне известно, тот же Microsoft выдает исходники виндов нашему ФСБ.
1) Действительно, не всегда бывают исходники.
2) Часто исходники собираются компилятором, от которого нет исходников или который никто не исследовал.
3) Существует множество способов спрятать закладку в исходниках так, чтобы при простом их чтении ее было очень сложно найти, например, использовать особенности оптимизатора или архитектуры.
4) В плане поиска сложных закладок или дырок динамический анализ гораздо круче статического, а он, как правило, работает с бинарниками.
Отличия статического и динамического анализа
Если упрощенно, то статический анализ — это «ничего обо всем», а динамический — это «все ни о чем», т.е. в статическом анализе сложно обеспечить глубину анализа, зато он покрывает исходник целиком, а в динамическом анализе сложно обеспечить покрытие, но он позволяет обнаруживать очень сложные закладки/баги/дырки. Статический анализ, обычно, работает с исходником, а динамический с бинарником (часто != всегда).
5) У них существует набор разработаных и утвержденных методик анализа биосов. Эти методики разрабатывались тогда, когда исходников от биосов еще не было, а сами биосы были небольшими. Методик приходится придерживаться (скорее духа, чем буквы). Разработка и согласование новой методики — это очень длительный процесс, в котором участвует много людей, он требует огромного количества писанины, переучивания людей и т.д.
Кстати, сертификация обычного ПО проходит по исходникам, но сертификат выдается на бинарник. Поэтому бинарник должен собираться в контролируемых ФСБ условиях или надо доказывать, что он собран из тех исходников, которые анализировал ФСБ.
По поводу исходников для спецслужб: большинство крупных компаний действительно выдает исходники своих продуктов для сертификации спецслужбам. На сколько мне известно, тот же Microsoft выдает исходники виндов нашему ФСБ.
А у анкада они все CSMные. А тот, что умеет в UEFI, сделан не анкадом =)
Грамотные ребята там есть, это я не спорю, но когда тебе заявляют, что у них одним биосом занимаются 50 профессионалов именно по БИОСу, начинаешь думать, как они умудрились всех БИОСников по стране к себе заманить?
Грамотные ребята там есть, это я не спорю, но когда тебе заявляют, что у них одним биосом занимаются 50 профессионалов именно по БИОСу, начинаешь думать, как они умудрились всех БИОСников по стране к себе заманить?
Ваша информация не соответствует действительности.
Дело в том, что я работаю в Анкаде и лично занимаюсь разработкой этих замков. Сейчас мы сосредоточились на том, что делаем интегрированные в матери замки, которые позволяют противостоять гораздо большему набору угроз. И они работают без CSM'а. Вся оболочка у них выполнена в виде модулей UEFI.
Все сертифицированные нами PCI'ные замки действительно CSM'ные. На то есть причины, связанные с безопасностью, и эта статья отлично описывает одну из них. Технически, PCI замок без CSM'а у нас давно есть, другое дело, что он никому не нужен и поэтому мы его не стремимся сертифицировать и выводить на рынок.
Неужели вы думаете, что это требует серьезных телодвижений? Единственное, что нужно, чтобы интегрированный на мамку замок стал PCI'ным — добавить UEFI'шный OptionROM.
Про 50 разработчиков я ни разу от них не слышал, так что ничего ответить на это не могу. Может быть человек не правильно понял ваш вопрос или вы его ответ?
Дело в том, что я работаю в Анкаде и лично занимаюсь разработкой этих замков. Сейчас мы сосредоточились на том, что делаем интегрированные в матери замки, которые позволяют противостоять гораздо большему набору угроз. И они работают без CSM'а. Вся оболочка у них выполнена в виде модулей UEFI.
Все сертифицированные нами PCI'ные замки действительно CSM'ные. На то есть причины, связанные с безопасностью, и эта статья отлично описывает одну из них. Технически, PCI замок без CSM'а у нас давно есть, другое дело, что он никому не нужен и поэтому мы его не стремимся сертифицировать и выводить на рынок.
Неужели вы думаете, что это требует серьезных телодвижений? Единственное, что нужно, чтобы интегрированный на мамку замок стал PCI'ным — добавить UEFI'шный OptionROM.
Про 50 разработчиков я ни разу от них не слышал, так что ничего ответить на это не могу. Может быть человек не правильно понял ваш вопрос или вы его ответ?
50 разработчиков было сказано на вопрос «а сколько спецов у вас на разработку вашего защищенного бивиса идёт».
Про апмдз — МАКСИМ-М1. Сертификат есть, умеет в UEFI и обычный режим. Что мешает в новой версии замка сделать оптром для UEFI — я не знаю. Насчёт никому не нужен — пардоньте, сейчас купить что-либо не UEFI уже нереально, и те, кому нужен ампдз (а мы с вами понимаем, кому оно надо, если сертификат) уже просто никуда не денутся от этого, а запускать защиту через эмуляцию — это извращение, причём полное.
Про апмдз — МАКСИМ-М1. Сертификат есть, умеет в UEFI и обычный режим. Что мешает в новой версии замка сделать оптром для UEFI — я не знаю. Насчёт никому не нужен — пардоньте, сейчас купить что-либо не UEFI уже нереально, и те, кому нужен ампдз (а мы с вами понимаем, кому оно надо, если сертификат) уже просто никуда не денутся от этого, а запускать защиту через эмуляцию — это извращение, причём полное.
Я вам могу ответить, почему нам не очень интересно тратить деньги на сертификацию PCI'ных замков.
1) Для их эксплуатации требуется материнка и UEFI, исследованные в ФСБ, а их выбор (если говорить о современных платформах) сильно ограничен. Поэтому большинству заказчиков все равно покупать только замок или замок + материнку. Но интегрированное решение обеспечивает значительно больший уровень безопасности. В контексте данной статьи отличный пример — защита SPI флешки.
2) Многие переходят на тонкие клиенты, а чем меньше в них плат, тем они «тоньше».
3) Многим интересны мобильные платформы, т.е. ноутбуки и планшеты (да, их мы тоже разработали).
Как только найдется заказчик, которому потребуется сколько-нибудь крупная партия именно PCI'ных замков с поддержкой UEFI мы получим сертификат и будем им торговать.
1) Для их эксплуатации требуется материнка и UEFI, исследованные в ФСБ, а их выбор (если говорить о современных платформах) сильно ограничен. Поэтому большинству заказчиков все равно покупать только замок или замок + материнку. Но интегрированное решение обеспечивает значительно больший уровень безопасности. В контексте данной статьи отличный пример — защита SPI флешки.
2) Многие переходят на тонкие клиенты, а чем меньше в них плат, тем они «тоньше».
3) Многим интересны мобильные платформы, т.е. ноутбуки и планшеты (да, их мы тоже разработали).
Как только найдется заказчик, которому потребуется сколько-нибудь крупная партия именно PCI'ных замков с поддержкой UEFI мы получим сертификат и будем им торговать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О безопасности UEFI, части нулевая и первая