По постоянной (т.н. black-box mitigation) тоже есть работы, но они по большей части требуют использования hard-RTOS, почитайте пункт 5.3.2 вот этого анализа.
Про спец-проц: кто вам сказал, что это он? Intel fTPM — это программная реализация, исполняемая на синтезированном из верилога аналоге i586 (т.н. Minute IA). Что внутри у STMicro я не знаю, не не удивлюсь какому-нибудь 8051, MIPS или ARCompact'у. Специальные вычислительные ядра делать дорого и долго, а бизнесу нужно дешево и вчера.
Вот это максимальное время может быть очень сложным концептом. Как его вычислить, не перебирая всех возможных nonce? Как гарантировать, что это время именно максимальное? Как замерять время, если источника качественных часов у тебя нет? Пробовали задержки, и где-то они даже работают относительно как-то, но консенсус у авторов крипто-библиотек сейчас в том, что задержки — это только малая часть общего решения, и смысл в них если и есть, то не очень много.
Про задержку написал выше, идея эта крайне плохая, т.к. внесение случайной задержки требует наличия источника и очень хорошей случайности, и «хороших» в некотором смысле задержек (слишком маленькая задержка удаляется из данных статистикой, за слишком большую не пропустят, т.к. она очень заметно снижает производительность).
Про прописные истины: оглянитесь вокруг, среди ваших коллег много специалистов по криптоанализу? И если завтра к вам придет начальство и скажет «а давайте сделаем свой TPM», вы ляжете костьми, но специалиста такого наймете? Ну вот. Людям дали микроконтроллер и библиотеку на С, и сказали, чтобы за полгода-год они сделали из этого TPM, не не простой, а проходящий все сертификации. Они его сделали, выпустили, и продают успешно, а что там они подвержены простейшим атакам — это надо сначала дождаться, чтобы кто-то атаковать пришел, будучи при этом достаточно умелым.
Ну вот к ним и пришли теперь люди, которые там в академической среде имеют и массу времени, и достаточно знаний, и сильное желание сломать и опубликовать результаты (потому что диссертация им нужна намного сильнее, чем ключи какие-то). Реальный же атакующий (который за ключами пришел как раз) раскрывать суть успешной атаки не станет никогда (потому что ее тут же закроют), поэтому любым подобным сообщениям производители должны радоваться (потому что для них бесплатно сделали дорогой аудит).
Сложно сделать эти случайности достаточно непредсказуемыми, чтобы их нельзя было отфильтровать статистикой. Намного лучше будет использовать вычисления, устойчивые к этой атаке, т.е. такие, в котором секретное значение (nonce) не влияет на скорость вычисления результата. Таких "устойчивых к тайминг-атакам" крипто-библиотек уже разработано немало, но сама по себе задача написания такого кода очень нетривиальная, и зачастую практически невозможная без активной поддержки со стороны разработчиков и процессора, и компилятора. Пока что дальше предложений дело не пошло, поэтому так и приходится очень осторожно писать на ассемблере и тестировать непрерывно.
Все можно подсмотреть осциллографом, если TPM живет на шине LPC, но обсуждаемый в статье Intel fTPM находится внутри чипсета или SoC'а, а туда просто так осциллограф уже не подсунешь.
Графики с этой новости совсем не те, которые нужны, оригинальная статья намного лучше поясняет, в чем именно проблема.
А проблема в том, если в используемых для генерации ключей затравочных однократно используемых значений (nonce) оказывается много нулей в начале, то генерация такого ключа выполняется быстрее (т.к. при наивной реализации на 0 быстрее умножать, чем на число, и умножение на число с большим количеством ведущих нулей оказывается быстрее, чем с небольшим. Мозг человека тоже уязвим, т.к. умножать в уме на 0007 легче, чем на 0183, а на 0183 легче, чем на 2749.).
В результате авторы, замеряя время генерации ключа, и собирая сгенерированные ключи, смогли накопить достаточно материала для lattice-атаки. По сути атака сводится к решению большой СЛАУ, которую получается составить только если можно каким-то образом отличить «уязвимые» ключи от «обычных». Там где у авторов это получилось, они смогли достать приватные ключи из устройств, специально сделаных для того, чтобы ключи из них достать было максимально непросто.
Разница в таймингах при этом оказалась настолько заметная, что ее можно замерять даже с удаленной машины.
Вот графики зависимости времени генерации ключа от количества ведущих нулей в nonce на уязвимых реализациях:
Intel — зависимость ступенчатая.
STMicro — зависимость линейная.
Приведенный тут график для Infinion — это то, как выглядит неуязвимая к данной атаке реализация.
Короче, и интересующимся, и особенно автору посоветую оригинальную публикацию прочитать все же, а не переводить новости из источников, которые только звон слышали, и то где-то далеко, и картинки прикрепляют почти случайные.
Это именно единственный источник отопления, а котел — общий на весь дом (небольшой, 3 этажа, 9 квартир). Там действительно не нужно управление толком, потому что либо отопление не нужно совсем (большую часть года), либо его можно один раз включить утром и один раз выключить перед сном.
Есть, водяные, в трех комнатах, по одному регулятору на комнату.
Точнее сказать, были в Германии, теперь в Калифорнии теплые полы не очень нужны, и большую часть года нужен кондиционер.
Можно регулировать прямо на месте, но простым регулятором вроде такого:
Автоматизация, на мой взгляд, нужна там, где она либо экономит кучу времени на монотонную, но необходимую работу (стиральная, посудомоечная и кофе-машины, робот-пылесос — прекрасные примеры), либо если работа должна быть выполнена без участия человека по каким-то причинам. А тут автоматизируется действие «встать с дивана три-пять раз в день», которое само по себе полезно для здоровья, и времени отнимает от силы минуты две. Взамен предлагается устройство, за которым надо следить, обновлять ему прошивку, защищать его от атак, бороться с его глюками и зависаниями, и по итогу может оказаться, что потраченное на его выбор, установку, программирование и поддержку время больше, чем сэкономленное им же за весь период эксплуатации. Simplicity that is the ultimate of sophistication plus practicality, и все вот это вот.
Очень не хватает вариантов вроде «предпочту механические системы электронным». Не нужны мне эти блютусы-вайфаи-тачскрины, вполне хватит не очень страшного крана не посреди комнаты, в крайнем случае — простейшего регулятора под выключателем света. Мне не трудно встать и покрутить, в случае необходимости, и внедрять сложные системы туда, где отлично работают простые, я не стану.
Никак, к сожалению, тут кроме как на себя надеятся больше не на кого. Ну или писать на Расте обертки и работать с ними уже…
Еще можно попробовать брать указатель на указатель первым параметром всех функций, и ставить его в NULL при успехе, т.е. если все сработало, вот вам указатель нового типа, а старый мы вам занулили автоматически, спасибо.
Т.е. в момент ее создания там есть состояние (структура которого скрыта, и писать в него напрямую тоже не стоит), и функции, которые возвращают указатель на ту же самую структуру, только уже не с reserved_do_not_use_*(...), а с функциями, которые доступны на данный момент.
typedef struct {
const uint8_t state[STATE_SIZE];
void* reserved_do_not_use_0(...);
void* reserved_do_not_use_1(...);
UNINITIALIZED* reset(...);
STATUS reserved_do_not_use_2(...);
STATUS read(...);
...
} READ;
typedef struct {
const uint8_t state[STATE_SIZE];
void* reserved_do_not_use_0(...);
void* reserved_do_not_use_1(...);
UNINITIALIZED* reset(...);
STATUS write(...);
STATUS reserved_do_not_use_2(...)
...
} WRITE;
Получается такой себе фасад, за которым на конкретном этапе доступны только те функции, которые имеют на нем смысл. Понятно, что можно вручную кастовать что угодно к чему угодно, и все порушить, но даже такая защита сильно лучше, чем никакой, потому что случайно уже вызвать не ту функцию не получится.
Мы тут, мне кажется, говорим про разную безопасность, я — про «security», а вы — про «safety». Более того, одним только переходом на другой ЯП дело точно не ограничится, и это вовсе не серебряная пуля, но без этого перехода ограничения становятся слишком сильные, разработка слишком медленной и дорогой, и потому security продолжают заметать под ковер в погоне за сроками.
Safety — это отдельная тема, которой я касался не очень сильно, и довольно давно, поэтому разговор предметный по ней не поддержу, прошу пардону.
Мы тут, мне кажется, уже перешли на обсуждение проектов вообще, а не только таких мелких, как в этой статье. Я согласен с тем, что там, где можно использовать Питон, Раст тоже отлично зайдет.
Запрос на замену С на низком уровне идет сейчас с нескольких сторон, и производительность — не самая популярная из них, на мой взгляд. Код на и на Расте, и на С — достаточно быстрый, а критические части все равно придется писать на чем-то, напрямую ложащемся на архитектуру, будь это ассемблер или что-то еще похожее.
Я безопасник, и потому мне замена С нужна для того, чтобы среднестатистический код, написанный среднестатистическим обычным разработчиком-мидлом (который мало что понимает во всей этой безопасности ненужной, он по своей предметной области специалист) перестал быть невыносимо отвратительным с точки зрения сопротивления внешним воздействиям. Если такой достаточно-безопасный код при этом еще и нормально переживет нахождение в большом репозитории на несколько десятков проектов, в который каждый день коммитят несколько десятков человек, и его безопасность не деградирует со временем до состояния «след простыл» — моя жизнь станет значительно лучше, и CVE станет значительно меньше.
Опыт при этом показывает, что С в данном случае не помогает ничего, ни тулинг, ни грамотное управление, ни внедрение SDL, ни обучение всех разработчиков основам security mindset, потому что инструмент никогда под безопасность не затачивался, и требует соблюдение железной дисциплины не просто от программиста, а вообще от всех программистов, когда либо трогавших код на нем.
Писать безопасный код на С нечеловечески сложно, медленно, и потому дорого, от этого дырявое нынче абсолютно все, и очень много усилий направлено в итоге на то, чтобы заставить всю эту гору кода на С и его производных, которую мы все уже написали и вынуждены использовать и поддерживать, вести себя хоть в каких то рамках приличия. В железо пришлось затащить и теневой стек (чтобы хоть как-то бороться с ROP), и шифрованную и\или тегированную память, и компартментализацию (многоуровневую), и даже контракты (CHERI), и занесут еще вагон всего, только бы ПО не чинить.
В общем, Раст — это шаг в очень правильном направлении, и я его приветствую всеми фибрами души.
Согласен с тем, что свидетелям святого дедлайна и поборникам стиля куяк-куяк-и-в-прод замена С на Раст поможет мало, и они в своем новом коде тоже начнут срезать углы направо и налево. При этом даже в таком говно-расте срезанные углы можно искать поиском по unsafe, плюс компилятор не даст собрать совсем уже невообразимую херню вроде замены "&" на "&&" или "&&" на ",".
В приличных местах (где за качество результата все таки готовы сколько-нибудь отвечать) говнокодеров рано или поздно либо перевоспитывают, либо изгоняют, и остаются люди, которые хотели бы писать на С хороший, добротный код, решающий их задачи и не отнимающий на написание слишком много времени, но они не могут, даже если хотят, потому что это выше человеческих сил.
На Расте, все же, намного проще писать, потому что нужно меньше вещей держать в голове (управление ресурсами в коде, переполнение буферов отслеживается компилятором, инициализация автоматическая, молчаливых приведений типов нет, молчаливых знаковых расширений нет, за арифметику с указателями бьют по рукам, за накидывание структур на память бьют по рукам, и т.п.), т.е. по итогу писать нормально, стабильно выдавая подходящий результат за разумное время, на нем может большее количество людей, и ошибок в коде получается в среднем меньше, по крайней мере мне так показалось. На С же нужна предельная концентрация внимания, постоянные проверки и перепроверки, вагон всякого тулинга и анализаторов, а в результате все равно имеем вот такое:
Толк будет в любом случае, я думаю, потому что затраты на поддержку низкого уровня ошибок теперь переложены на компилятор (который не устает), и в долгую эта стратегия все-таки окупается так или иначе. Безопасники давят со своей стороны, хоть и несильно, но стабильно, плюс можно оказаться в авангарде прогресса и получить бесплатную рекламу, плюс те подходы к дизайну, которые вынуждает применять Раст (иммутабельность по умолчанию, RAII, pattern matching, data race safety) — они сами по себе часто приводят к ускорению и упрощению кода, и получается тут на 5% быстрее стало, тут на 10% меньше ошибок, с миру по нитке — вот новый телевизор.
Рано или поздно на Раст (или другой более безопасный, но все еще достаточно низкоуровневый ЯП) все равно перейдут (т.к. С для потоковой коммерческой разработки — это все-таки очень плохой инструмент, скальпель в руках коновала), потому что их додавят таки безопасники, но не думаю, что это получится сделать скоро.
Про спец-проц: кто вам сказал, что это он? Intel fTPM — это программная реализация, исполняемая на синтезированном из верилога аналоге i586 (т.н. Minute IA). Что внутри у STMicro я не знаю, не не удивлюсь какому-нибудь 8051, MIPS или ARCompact'у. Специальные вычислительные ядра делать дорого и долго, а бизнесу нужно дешево и вчера.
Про прописные истины: оглянитесь вокруг, среди ваших коллег много специалистов по криптоанализу? И если завтра к вам придет начальство и скажет «а давайте сделаем свой TPM», вы ляжете костьми, но специалиста такого наймете? Ну вот. Людям дали микроконтроллер и библиотеку на С, и сказали, чтобы за полгода-год они сделали из этого TPM, не не простой, а проходящий все сертификации. Они его сделали, выпустили, и продают успешно, а что там они подвержены простейшим атакам — это надо сначала дождаться, чтобы кто-то атаковать пришел, будучи при этом достаточно умелым.
Ну вот к ним и пришли теперь люди, которые там в академической среде имеют и массу времени, и достаточно знаний, и сильное желание сломать и опубликовать результаты (потому что диссертация им нужна намного сильнее, чем ключи какие-то). Реальный же атакующий (который за ключами пришел как раз) раскрывать суть успешной атаки не станет никогда (потому что ее тут же закроют), поэтому любым подобным сообщениям производители должны радоваться (потому что для них бесплатно сделали дорогой аудит).
А проблема в том, если в используемых для генерации ключей затравочных однократно используемых значений (nonce) оказывается много нулей в начале, то генерация такого ключа выполняется быстрее (т.к. при наивной реализации на 0 быстрее умножать, чем на число, и умножение на число с большим количеством ведущих нулей оказывается быстрее, чем с небольшим. Мозг человека тоже уязвим, т.к. умножать в уме на 0007 легче, чем на 0183, а на 0183 легче, чем на 2749.).
В результате авторы, замеряя время генерации ключа, и собирая сгенерированные ключи, смогли накопить достаточно материала для lattice-атаки. По сути атака сводится к решению большой СЛАУ, которую получается составить только если можно каким-то образом отличить «уязвимые» ключи от «обычных». Там где у авторов это получилось, они смогли достать приватные ключи из устройств, специально сделаных для того, чтобы ключи из них достать было максимально непросто.
Разница в таймингах при этом оказалась настолько заметная, что ее можно замерять даже с удаленной машины.
Вот графики зависимости времени генерации ключа от количества ведущих нулей в nonce на уязвимых реализациях:
Intel — зависимость ступенчатая.
STMicro — зависимость линейная.
Приведенный тут график для Infinion — это то, как выглядит неуязвимая к данной атаке реализация.
Короче, и интересующимся, и особенно автору посоветую оригинальную публикацию прочитать все же, а не переводить новости из источников, которые только звон слышали, и то где-то далеко, и картинки прикрепляют почти случайные.
Точнее сказать, были в Германии, теперь в Калифорнии теплые полы не очень нужны, и большую часть года нужен кондиционер.
Автоматизация, на мой взгляд, нужна там, где она либо экономит кучу времени на монотонную, но необходимую работу (стиральная, посудомоечная и кофе-машины, робот-пылесос — прекрасные примеры), либо если работа должна быть выполнена без участия человека по каким-то причинам. А тут автоматизируется действие «встать с дивана три-пять раз в день», которое само по себе полезно для здоровья, и времени отнимает от силы минуты две. Взамен предлагается устройство, за которым надо следить, обновлять ему прошивку, защищать его от атак, бороться с его глюками и зависаниями, и по итогу может оказаться, что потраченное на его выбор, установку, программирование и поддержку время больше, чем сэкономленное им же за весь период эксплуатации. Simplicity that is the ultimate of sophistication plus practicality, и все вот это вот.
Еще можно попробовать брать указатель на указатель первым параметром всех функций, и ставить его в NULL при успехе, т.е. если все сработало, вот вам указатель нового типа, а старый мы вам занулили автоматически, спасибо.
Можно сделать структуру вроде такой:
Т.е. в момент ее создания там есть состояние (структура которого скрыта, и писать в него напрямую тоже не стоит), и функции, которые возвращают указатель на ту же самую структуру, только уже не с reserved_do_not_use_*(...), а с функциями, которые доступны на данный момент.
Получается такой себе фасад, за которым на конкретном этапе доступны только те функции, которые имеют на нем смысл. Понятно, что можно вручную кастовать что угодно к чему угодно, и все порушить, но даже такая защита сильно лучше, чем никакой, потому что случайно уже вызвать не ту функцию не получится.
Т.е. действие «сконфигурировать на запись» возвращает тип, у которого нет функции чтения.
Safety — это отдельная тема, которой я касался не очень сильно, и довольно давно, поэтому разговор предметный по ней не поддержу, прошу пардону.
Я безопасник, и потому мне замена С нужна для того, чтобы среднестатистический код, написанный среднестатистическим обычным разработчиком-мидлом (который мало что понимает во всей этой безопасности ненужной, он по своей предметной области специалист) перестал быть невыносимо отвратительным с точки зрения сопротивления внешним воздействиям. Если такой достаточно-безопасный код при этом еще и нормально переживет нахождение в большом репозитории на несколько десятков проектов, в который каждый день коммитят несколько десятков человек, и его безопасность не деградирует со временем до состояния «след простыл» — моя жизнь станет значительно лучше, и CVE станет значительно меньше.
Опыт при этом показывает, что С в данном случае не помогает ничего, ни тулинг, ни грамотное управление, ни внедрение SDL, ни обучение всех разработчиков основам security mindset, потому что инструмент никогда под безопасность не затачивался, и требует соблюдение железной дисциплины не просто от программиста, а вообще от всех программистов, когда либо трогавших код на нем.
Писать безопасный код на С нечеловечески сложно, медленно, и потому дорого, от этого дырявое нынче абсолютно все, и очень много усилий направлено в итоге на то, чтобы заставить всю эту гору кода на С и его производных, которую мы все уже написали и вынуждены использовать и поддерживать, вести себя хоть в каких то рамках приличия. В железо пришлось затащить и теневой стек (чтобы хоть как-то бороться с ROP), и шифрованную и\или тегированную память, и компартментализацию (многоуровневую), и даже контракты (CHERI), и занесут еще вагон всего, только бы ПО не чинить.
В общем, Раст — это шаг в очень правильном направлении, и я его приветствую всеми фибрами души.
В приличных местах (где за качество результата все таки готовы сколько-нибудь отвечать) говнокодеров рано или поздно либо перевоспитывают, либо изгоняют, и остаются люди, которые хотели бы писать на С хороший, добротный код, решающий их задачи и не отнимающий на написание слишком много времени, но они не могут, даже если хотят, потому что это выше человеческих сил.
На Расте, все же, намного проще писать, потому что нужно меньше вещей держать в голове (управление ресурсами в коде, переполнение буферов отслеживается компилятором, инициализация автоматическая, молчаливых приведений типов нет, молчаливых знаковых расширений нет, за арифметику с указателями бьют по рукам, за накидывание структур на память бьют по рукам, и т.п.), т.е. по итогу писать нормально, стабильно выдавая подходящий результат за разумное время, на нем может большее количество людей, и ошибок в коде получается в среднем меньше, по крайней мере мне так показалось. На С же нужна предельная концентрация внимания, постоянные проверки и перепроверки, вагон всякого тулинга и анализаторов, а в результате все равно имеем вот такое:
Рано или поздно на Раст (или другой более безопасный, но все еще достаточно низкоуровневый ЯП) все равно перейдут (т.к. С для потоковой коммерческой разработки — это все-таки очень плохой инструмент, скальпель в руках коновала), потому что их додавят таки безопасники, но не думаю, что это получится сделать скоро.
NVIDIA, кстати, недавно перешла на ADA/SPARK для своих automotive-проектов.