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

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

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


security cryptography assembly riscv timing
person andrew-e    schedule 16.10.2014    source источник
comment
Какая реализация криптографической библиотеки учитывает это?   -  person user2548418    schedule 17.10.2014
comment
+1 но вопросы к команде RISC-V здесь конечно не по теме, поэтому последний вопрос я удалил. Пожалуйста, не будьте ослом и напишите свой вопрос самостоятельно, это не ютуб.   -  person Maarten Bodewes    schedule 18.10.2014
comment
@ user2548418: Хорошо написанные библиотеки сравнения хэшей паролей и библиотеки шифрования rsa, вероятно, учитывают атаки по времени. Я не знаю, какие именно, но мейнтейнеры таких библиотек должны знать ответ на этот вопрос. Другие атаки по времени и атаки по сторонним каналам также могут заслуживать изучения.   -  person andrew-e    schedule 18.10.2014

Ответы (3)


arrow_upward
2
arrow_downward

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

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

person user2548418    schedule 17.10.2014
comment
Можете ли вы пояснить, как такие последовательно синхронизированные инструкции будут работать при наличии кешей? Будет ли требование их использования заключаться в том, что память сначала загружается в блокнотную память? Будет ли память останавливаться в худшем случае при каждом доступе? Будет ли гарантия применяться только к операциям, не связанным с памятью? - person Chris; 17.10.2014
comment
Я не уверен, я также не выступаю за постоянные задержки. Я просто хотел указать, что при разработке расширения дизайнер может включать в него любые функции, которые ему нужны. Я считаю, что понятие зависимости от определенных задержек слишком сложно для интерфейса HW/SW для поддержки различных процессоров/поколений и чем-то напоминает VLIW. - person user2548418; 17.10.2014

arrow_upward
2
arrow_downward

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

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

person Ben    schedule 17.10.2014
comment
Можно ли предсказать задержку кэш-промаха для flexpret? - person osgx; 22.02.2015

arrow_upward
0
arrow_downward

«Существует ли стандарт того, сколько времени каждая инструкция должна выполняться по сравнению с другими операциями?»

No.

Насколько мне известно, такое поведение будет соответствовать всем другим основным ISA.

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

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

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

person Chris    schedule 17.10.2014
comment
Я удалил последнюю часть вопроса, я не думаю, что она здесь по теме; как вы сказали: мы не знаем. - person Maarten Bodewes; 18.10.2014