Comments 19
А где правило номер 0?
«Не используйте самостоятельно имплементированые алгоритмы в продакшене». Ну или более строгий вариант: «Не нужно имплементировать криптоалгоритмы самостоятельно».
«Не используйте самостоятельно имплементированые алгоритмы в продакшене». Ну или более строгий вариант: «Не нужно имплементировать криптоалгоритмы самостоятельно».
Указанные подходы не дают никаких гарантий: C и C++ используют правило “как если бы”, которое позволяет компилятору реализовывать операции произвольным образом, в случае если наблюдаемое поведение программы (время выполнения не считается наблюдаемым поведением в обоих языках) остается неизменным.У меня резонный (возможно) вопрос: а почему не организовывать сравнение таких переменных как если бы это был просто буффер из 2-4-8 байтов? Стандартная memcmp() возвращает значения <, == или > в зависимости от того «больше», равен или «меньше» буффера переданные для сравнения. Повторить подобное поведение в time-const реализации, думаю, возможно. Или где я не прав?
Годнота, наконец хоть что-то новое
Не мог не загрузить
Главное правило: доверьте криптографию профессионалам. Допустить ошибку легко, а найти — очень сложно…
доверьте криптографию профессионалам
Эту фразу можно сравнить с диагностическим сообщением: «Обратитесь к системному администратору». Особенно доставляет, когда ты сам администратор и пытаешься получить хоть какую-то информацию о проблеме.
Профессионалы-то в криптографии не Свыше к нам нисходят. Они тоже люди, им надо где-то учиться, обмениваться опытом.
Найти бекдор, оставленный профессионалом, ещё сложнее.
Интересно, почему редко используются комбинации шифров. Например, AES в реализации Microsoft + ГОСТ в какой-то рекомендованной реализации.
Интересно, почему редко используются комбинации шифров. Например, AES в реализации Microsoft + ГОСТ в какой-то рекомендованной реализации.
Выступление «Crypto coding v2» от Жана-Филиппа на ZeroNights 2014 www.youtube.com/watch?v=Ekju_HyytFE
UFO just landed and posted this here
Здравствуйте, Иван!
«А в остальном, большая дилемма: сделать чтобы код выполнялся за 0,001 секунды но вот с такими тайминг особенностями или сделать чтобы он выполнялся за постоянное время, пусть даже 1 секунду.»
Во-первых, боюсь, Вы все же существенно преувеличиваете. Как Вы понимаете, аспекты реализации ГОСТ Р 34.10-2001/ГОСТ Р 34.10-2012 и ECDSA практически не отличаются, а вопросы быстродействия в обоих случаях сводятся, в первую очередь, к грамотному выбору методов вычисления кратной точки.
Так вот я не могу привести пример адекватного метода защиты от атак по побочному каналу по времени, которые бы замедляли время работы в тысячу раз. Вопросы построения безопасных реализаций российских криптоалгоритмов регулярно обсуждаются на РусКрипто и CTCrypt, о разнице в три десятичных порядка, к счастью, речь никогда не заходит.
Если Вам подобные методы известны, будем благодарны, если расскажете.
Во-вторых, описанная Вами дилемма может возникать исключительно в двух случаях: написания криптобиблиотечки «для себя»/студентом для сдачи практикума либо в случае написания специальной реализации криптографии для специфичной задачи внутри закрытой со всех сторон системы. В случае же, когда криптографические механизмы планируется применять в широком спектре реальных систем (для которых нельзя раз и навсегда дать гарантии отсутствия нарушителя, имеющего доступ к информации о времени работы), пренебрегать побочкой по времени совершенно недопустимо. И я говорю даже не о сертификации криптосредств (не суть важно по чему — по требованиям ФСБ или по FIPS), а об элементарной ответственности за свой код.
«Про атаки на RSA в деталях не читал, думаю там тоже была заранее известная реализация (те исследователи знали как она шумит и как это интерпретировать) и контроль на входные данные.»
Разумеется, всё противодействие атакам по побочным каналам обязано производиться в предположении, что код реализации нарушителю известен.
«А в остальном, большая дилемма: сделать чтобы код выполнялся за 0,001 секунды но вот с такими тайминг особенностями или сделать чтобы он выполнялся за постоянное время, пусть даже 1 секунду.»
Во-первых, боюсь, Вы все же существенно преувеличиваете. Как Вы понимаете, аспекты реализации ГОСТ Р 34.10-2001/ГОСТ Р 34.10-2012 и ECDSA практически не отличаются, а вопросы быстродействия в обоих случаях сводятся, в первую очередь, к грамотному выбору методов вычисления кратной точки.
Так вот я не могу привести пример адекватного метода защиты от атак по побочному каналу по времени, которые бы замедляли время работы в тысячу раз. Вопросы построения безопасных реализаций российских криптоалгоритмов регулярно обсуждаются на РусКрипто и CTCrypt, о разнице в три десятичных порядка, к счастью, речь никогда не заходит.
Если Вам подобные методы известны, будем благодарны, если расскажете.
Во-вторых, описанная Вами дилемма может возникать исключительно в двух случаях: написания криптобиблиотечки «для себя»/студентом для сдачи практикума либо в случае написания специальной реализации криптографии для специфичной задачи внутри закрытой со всех сторон системы. В случае же, когда криптографические механизмы планируется применять в широком спектре реальных систем (для которых нельзя раз и навсегда дать гарантии отсутствия нарушителя, имеющего доступ к информации о времени работы), пренебрегать побочкой по времени совершенно недопустимо. И я говорю даже не о сертификации криптосредств (не суть важно по чему — по требованиям ФСБ или по FIPS), а об элементарной ответственности за свой код.
«Про атаки на RSA в деталях не читал, думаю там тоже была заранее известная реализация (те исследователи знали как она шумит и как это интерпретировать) и контроль на входные данные.»
Разумеется, всё противодействие атакам по побочным каналам обязано производиться в предположении, что код реализации нарушителю известен.
А есть ли в открытом доступе требования ФСБ к стойкости по второстепенным каналам?
Мне кажется, что ни FIPS, ни Common Criteria четко не определяют требования встраиваемых систем к стойкости по второстепенным каналам (кроме смарт-карт, но они не совсем встраиваемые системы). Такие стандарты еще только пишутся (опять же, по моему опыту).
Мне кажется, что ни FIPS, ни Common Criteria четко не определяют требования встраиваемых систем к стойкости по второстепенным каналам (кроме смарт-карт, но они не совсем встраиваемые системы). Такие стандарты еще только пишутся (опять же, по моему опыту).
В открытом доступе таких требований ФСБ, конечно, нет.
Четкость требований в таких вопросах в принципе невозможна – как и четкость формулировок свыше общих «стойкость к атакам по побочным каналам».
Я говорил о том, что сертифицировать криптосредство, время операции с ключом в котором будет давать существенную информацию о ключе, вы не сможете. Надеюсь, и не захотите.
Но и здесь от размытости формулировок («существенную») не уйти.
Четкость требований в таких вопросах в принципе невозможна – как и четкость формулировок свыше общих «стойкость к атакам по побочным каналам».
Я говорил о том, что сертифицировать криптосредство, время операции с ключом в котором будет давать существенную информацию о ключе, вы не сможете. Надеюсь, и не захотите.
Но и здесь от размытости формулировок («существенную») не уйти.
2 Ivan_83
Я с вами соглашусь в некоторой части рассужденй о сложности атак по второстепенным каналам, но мне кажется, вы фактически приходите к выводу, что такие атаки в реальности не страшны (хотя это вечный спор). Это не совсем так. Даже к OpenSSL периодически прикручивают защиту от атак по времени (CVE CAN-2003-0147). Всегда можно придумать модель, в которой вы знаете код, но не знаете ключ. Поэтому изначально протестировав на собственных примерах, можно найти уязвимость.
Реальные атаки по второстепенным каналам практически не встречаются в открытых источниках, возможно, потому что их авторы хотят сохранить анонимность. Обнаружить такие атаки сложно — это же не DDoS.
В Kudelski Security просто так не дают должность Principal Cryptographer, поэтому Jean-Philippe без сомнения хорош.
Как и в любом деле, реализовав крипто алгоритм вы не станете спецом по криптографии, но вы определенно чему-то научитесь. Я не до конца понял, к чему адресованы последние два предложения.
Я с вами соглашусь в некоторой части рассужденй о сложности атак по второстепенным каналам, но мне кажется, вы фактически приходите к выводу, что такие атаки в реальности не страшны (хотя это вечный спор). Это не совсем так. Даже к OpenSSL периодически прикручивают защиту от атак по времени (CVE CAN-2003-0147). Всегда можно придумать модель, в которой вы знаете код, но не знаете ключ. Поэтому изначально протестировав на собственных примерах, можно найти уязвимость.
Реальные атаки по второстепенным каналам практически не встречаются в открытых источниках, возможно, потому что их авторы хотят сохранить анонимность. Обнаружить такие атаки сложно — это же не DDoS.
В Kudelski Security просто так не дают должность Principal Cryptographer, поэтому Jean-Philippe без сомнения хорош.
Как и в любом деле, реализовав крипто алгоритм вы не станете спецом по криптографии, но вы определенно чему-то научитесь. Я не до конца понял, к чему адресованы последние два предложения.
Sign up to leave a comment.
Безопасное криптопрограммирование. Часть 1