Продолжительность выполнения инструкции RISC-V стандартизирована ради криптографической безопасности?

Некоторые криптографические функции требуют согласованной продолжительности выполнения, чтобы избежать временных атак. Я читал, что такие функции, ориентированные на x86, трудно писать по причинам, потенциально включающим эмулируемый характер ISA и обработку вне порядка. Поэтому предотвращать временные атаки на x86 непросто, потому что это зависит от сложных и/или неизвестных факторов в любой момент.Продолжительность выполнения инструкции RISC-V стандартизирована ради криптографической безопасности?

В стандартном ядре RISC-V заданы тайминги команд, прогнозируемо последовательные относительно друг друга? Как насчет стандартного ядра с обработкой вне порядка или проприетарными реализациями базовой ISA?

источник

2014-10-16 sudoman

Какая реализация криптографической библиотеки учитывает это? – user2548418

+1 но вопросы к команде «RISC-V», конечно, не по теме, поэтому я удалил последний вопрос. Пожалуйста, не будьте задницей и делайте капитализацию своего вопроса самостоятельно, это не utube. –

@ user2548418: Хорошо написанные библиотеки сравнения хеш-файлов и библиотеки шифрования rsa, вероятно, учитывают временные атаки.Я не знаю, что это такое, но сторонники таких библиотек должны знать ответ на этот вопрос. Другие временные атаки и [побочные атаки канала] (https://en.wikipedia.org/wiki/Side_channel_attack) также могут быть полезны для расследования. – sudoman

«Есть ли стандарт на продолжительность выполнения каждой инструкции для завершения относительно других операций?»

No.

Такое поведение будет соответствовать всем другим основным ИСАС, насколько я знаю.

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

Как команда RISC-V планирует решить потенциальную стандартную или нестандартную сложность, которую разработчик криптографической библиотеки должен найти способ решения?

Я не могу говорить за команду RISC-V, но если я могу опасаться, я подозреваю, что это (и подобные) области будут включать более широкое сообщество для обсуждения и решения таких проблем.

источник

2014-10-17 03:55:29 Chris

Я снял последнюю часть вопроса, я не думаю, что это по теме; как вы сказали: мы не знаем. –

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

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

источник

2014-10-17 16:09:05 user2548418

Можете ли вы пояснить, как такие «последовательно рассчитанные» инструкции будут работать в присутствии кешей? Будет ли требование их использования состоять в том, что память сначала загружается в память блокнота? Будет ли память остановлена в наихудшем случае каждый доступ? Будет ли гарантия применяться только к операциям без памяти? – Chris

Я не уверен, я также не выступаю за постоянные задержки. Я просто хотел указать, что при разработке расширения дизайнер может включать в себя те функции, которые им нужны. Я считаю, что понятие зависимости от определенных латентностей слишком сложно для интерфейса HW/SW для поддержки ряда процессоров/поколений и несколько напоминает VLIW. – user2548418

RISC-V может быть реализован в машине с детерминированными задержками; это должно сделать больше с реализацией, чем с ISA.

Просмотреть этот проект для реализации RISC-V, который поддерживает выполнение прогнозируемой задержки: https://github.com/pretis/flexpret. Он был разработан для встроенного пространства, но, по-видимому, подходит для вашего предлагаемого приложения.

источник

2014-10-17 17:23:47 Ben

Является ли латентность кэширования предсказуемой для flexpret? – osgx

Продолжительность выполнения инструкции RISC-V стандартизирована ради криптографической безопасности?

ответ

Смежные вопросы