Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 75
Интересный подход, но кажется весьма избыточным. Если банку или интеграторам, которые там развернули СКЗИ, захочется выдавать вам «слабые» ключи или ключи с «бэкдорами», почему бы просто не использовать в качестве ДСЧ тупо константы? Ну или заведомо уязвимый ДСЧ вроде ЛКГ? Если злоумышленник является разработчиком средства защиты, то описанная в статье беда не самая страшная :)
Слабые ГСЧ могут повлиять на качество простых чисел, какую-то корреляцию между ними навести и какой нибудь умный аналитик возьмет и догадается. А тут все честно, все генераторы стойкие, ничего никогда не доказать :)
Не всегда. Вон, посмотрите в сторону ДСЧ от Intel. Мы берем число из множества ничтожной мощности, суём его в AES в качестве ключа шифрования и, вуаля, получаем идеальную со статистической точки зрения последовательность. Ни один аналитик не подкопается. Тем более, если не знает, что именно за исходное множество у нас было, чтобы сузить объем материала для перебора.
Ну в таком случае в выводе ДСЧ повторы будут встречаться намного чаще, чем должны. И это можно заметить просто гоняя ДСЧ, сохраняя начала всех полученных последовательностей в сортированный массив и ища повторы. Причём если у нас, например, мощность этого множества 2^N, то для перебора злоумышленнику придётся сделать 2^(N-1) итераций, а для описанной выше проверки — 2^(N/2).
В том числе и поэтому ключевая пара обычно генерится на стороне клиента, а удостоверяющему центру даётся на подпись только открытая часть.
Есть ли способ обнаружения такой «нагрузки»?
> Вы никогда не докажите, что в ключевых парах, выдаваемых вам банками
> и другими неконтролируемыми вами источниками нет таких закладок.
Объясните для тупых, а? Банк выдает вам приватный ключ, а потом с помощью каких-то хитрых действий этот ключ восстанавливает? А почему бы банку просто не запомнить этот ключ? Или банк выдает вам алгоритм, который похож на генерацию криптографически строгого приватного ключа, но на самом деле таковым не является? Ну, тогда вы сами себе злобный буратино.
> и другими неконтролируемыми вами источниками нет таких закладок.
Объясните для тупых, а? Банк выдает вам приватный ключ, а потом с помощью каких-то хитрых действий этот ключ восстанавливает? А почему бы банку просто не запомнить этот ключ? Или банк выдает вам алгоритм, который похож на генерацию криптографически строгого приватного ключа, но на самом деле таковым не является? Ну, тогда вы сами себе злобный буратино.
Банк договаривается с «органами» и без пересылания им ключей они могут расшифровывать всё, что вы зашифровываете
Банк «органам» по запросу и так всё о вас расскажет. Что вы спрятать то пытаетесь и от кого?
Это лишь пример, ситуаций можно придумать множество
Ждём. А то паранойя, знаете ли, разбушевалась.
Исходники PGP, например, у вас есть? И у меня нет, а штука популярная. Генерация сертификатов средствами винды, это навскидку.
Исходники OpenSSL, PolarSSL и др. реализаций есть в открытом доступе, но где гарантия, что в них нет таких же скрытых закладок или багов в реализации криптоалгоритмов, которые могут привести к раскрытию данных или еще чему то?
Никто не проводил полный аудит открытых библиотек и посему потенциально в них тоже могут быть закладки.
Буквально вчера в PolarSSL нашли критическую уязвимость (https://polarssl.org/tech-updates/security-advisories/polarssl-security-advisory-2014-04), которая потенциально может привести к выполнению кода злоумышленника при обработке средствами библиотеки специально оформленных последовательностей ASN.1 из сертификатов X.509. А PolarSSL используется много где, например в OpenVPN, cURL, FreeRDP, PowerDNS и т.д.
Так что открытость кода != надежность
Никто не проводил полный аудит открытых библиотек и посему потенциально в них тоже могут быть закладки.
Буквально вчера в PolarSSL нашли критическую уязвимость (https://polarssl.org/tech-updates/security-advisories/polarssl-security-advisory-2014-04), которая потенциально может привести к выполнению кода злоумышленника при обработке средствами библиотеки специально оформленных последовательностей ASN.1 из сертификатов X.509. А PolarSSL используется много где, например в OpenVPN, cURL, FreeRDP, PowerDNS и т.д.
Так что открытость кода != надежность
Не путайте ошибку и закладку.
когда серьёзная компания берёт на вооружение какой-либо софт она вполне себе может сделать его аудит и пользоваться ошибкой, как закладкой ;) мне кажется, что криптография просто обязана стать популярной словно р2р сети, просто время ещё не пришло. Не достаточно прецедентов.
При наличии исходного кода я могу различить. Да и для этого есть и берутся в проекты специалисты типа: аудиторы кода, тестеры.
Если пишут для примера:
if user_name == 'root' then
это может быть ошибкой т.к. хотели для примера !=
Если ли же пишут что то типа:
if substing (user_name, 2,2) == 'oo' then
это уже закладка
Если пишут для примера:
if user_name == 'root' then
это может быть ошибкой т.к. хотели для примера !=
Если ли же пишут что то типа:
if substing (user_name, 2,2) == 'oo' then
это уже закладка
следующий вопрос: вы умеете отличать аудиторов кода и тестеров от вражеских шпионов?
Смешно, что мешает писать в стиле ошибок, нечаянных опечаток? Наивно как-то думать что это невозможно или даже слишком трудно.
Замаскировать закладку под ошибку ведь не сильно сложно?
Напомнило конкурс на закладки замаскированные под простые ошибки.
underhanded.xcott.com/
underhanded.xcott.com/
Я всё равно не понимаю, в чем соль.
Отлично, мы можем сделать генератор ключей такой что мы можем по открытому ключу восстановить приватный, а остальные не могут. Чем описанный в статье способ принципиально лучше return (our_private_key, our_public_key);?
Отлично, мы можем сделать генератор ключей такой что мы можем по открытому ключу восстановить приватный, а остальные не могут. Чем описанный в статье способ принципиально лучше return (our_private_key, our_public_key);?
Внешне не будет выглядеть, как выдача зашитого ключа
Вот этим:
Отлично, мы можем сделать генератор ключей такой что мы можем по открытому ключу восстановить приватный, а остальные не могут.
Вот так и надо формулировать, а не «неопределимый бэкдор».
Спасибо.
Спасибо.
ой, да такой генератор ключей сделает первокурсник.
например: privKey = sha1 ( «my_very_secret_constant_salt» + time ( ) )
никто кроме автора не подумает, что ключи брутфорсятся.
А спрятать этот код в сорцах не составит большого труда.
например: privKey = sha1 ( «my_very_secret_constant_salt» + time ( ) )
никто кроме автора не подумает, что ключи брутфорсятся.
А спрятать этот код в сорцах не составит большого труда.
Начнем с того, что если сделать так, то потом мы не сможем найти публичный ключ для вычисленного приватного :)
По поводу же брутфорса… вы правда не видите разницы между брутфорсом и прямым вычислением приватного ключа по открытому?
По поводу же брутфорса… вы правда не видите разницы между брутфорсом и прямым вычислением приватного ключа по открытому?
Описанный в статье вариант, в отличии от вашего, подходит для вполне нормального применения (если публичный ключ не зашивать в софт а выдавать). Вы генерируете pgp ключ на основе моего публичного, теперь вы и я можем читать сообщения, зашифрованные сгенерированным ключом. Но вам для этого не надо предпринимать усилия по посылке мне своего приватного ключа.
Можно даже иерархию запилить (использовав сгенерированный тут ключ для генерации следующих).
Можно даже иерархию запилить (использовав сгенерированный тут ключ для генерации следующих).
Условно — производитель замков не рассылает всем, кому нужно связку с ключами от всех замком, а только алгоритм изготовления ключа «по адресу квартиры» (публичной информации)?
Зачем такие сложности? Если это может расшифровать «банк» (специально беру в кавычки, в общем случае это «вторая сторона») — то что мешает «банку» передать расшифрованный трафик «третьей стороне» (органам), либо передать алгоритм расшифровки третьей стороне?
Ну может потому что будет сам факт передачи, к тому же лишние люди (работники банка) узнают клиента которым интересуются органы. А так слушай кого угодно и без свидетелей!
Предположим, что вы купили банк и поменяли сотрудников.
Вы никому ничего не говорите, и получаете сообщения, и участвуете в переписке с клиентом.
Только уже и вы может не вы, и ли клиент — не клиент, а ни вы ни клиент об этом не в курсе.
Вы никому ничего не говорите, и получаете сообщения, и участвуете в переписке с клиентом.
Только уже и вы может не вы, и ли клиент — не клиент, а ни вы ни клиент об этом не в курсе.
Владея вашим закрытым ключом, «банк» может действовать от вашего имени, и «вы никогда ничего не докажете»
Банк может использовать чужое ПО, разработчик которого вложил туда подобную функциональность, не оповестив при этом сам банк :)
Что вы к банкам пристали?
Для получения квалифицированной ЭЦП подавляющее большинство УЦ использует сертифицированный органами софт, соответственно и клиенты вынуждены его использовать при генерации ключей.
Пальцев одной руки хватит (двух точно), чтобы перечислить сертфицированные СКЗИ, СКАД etc.
Вопрос к их разработчикам, а не к УЦ.
Для получения квалифицированной ЭЦП подавляющее большинство УЦ использует сертифицированный органами софт, соответственно и клиенты вынуждены его использовать при генерации ключей.
Пальцев одной руки хватит (двух точно), чтобы перечислить сертфицированные СКЗИ, СКАД etc.
Вопрос к их разработчикам, а не к УЦ.
Банки я взял для примера, Применить это возможно везде, где пользователь не контролирует процесс генерации ключей
Я обратного давно не встречал.
Симметричное шифрование, при котором закрытый ключ знает и УЦ и клиент, практически перестали использовать после того, как объявили панацеей ассиметричное шифрование.
Другое дело, что клиент при генерации вынужден использовать софт и криптопровайдера, навязанного ему УЦ.
У вас есть доверие к криптопро, вербе, криптоарм etc?
Симметричное шифрование, при котором закрытый ключ знает и УЦ и клиент, практически перестали использовать после того, как объявили панацеей ассиметричное шифрование.
Другое дело, что клиент при генерации вынужден использовать софт и криптопровайдера, навязанного ему УЦ.
У вас есть доверие к криптопро, вербе, криптоарм etc?
del
Я правильно понял, что сценарий такой — генерируя приватный и публичный ключ (т.е. зная приватный ключ) об специализированный секрет можно сгенерить такой публичный ключ, по которому можно восстановить приватный, зная секрет?
Итого, реальный сценарий эксплуатации уязвимости такой — подсунуть в широкий доступ библиотеку, которая генерит ключевые пары об наш зашитый в нее секрет.
Итого, реальный сценарий эксплуатации уязвимости такой — подсунуть в широкий доступ библиотеку, которая генерит ключевые пары об наш зашитый в нее секрет.
«Здесь стоит напомнить, что основа ключей RSA — это всегда два простых числа p и q. Их произведение — открытый ключ.»
Стоит напомнить, что произведение p и q — это модуль, а открытый ключ (публичная экспонента), это выбранное число, взаимно простое с фи(n) (как правило это 0x10001 = 65537), и обозначается оно 'e'.
Будьте корректнее при использование терминов.
ru.wikipedia.org/wiki/RSA
Стоит напомнить, что произведение p и q — это модуль, а открытый ключ (публичная экспонента), это выбранное число, взаимно простое с фи(n) (как правило это 0x10001 = 65537), и обозначается оно 'e'.
Будьте корректнее при использование терминов.
ru.wikipedia.org/wiki/RSA
Я не совсем понимаю, чего тут такого. Еще более веселых вещей можно добиться манипулируя ПГСЧ. Так можно и без открытого ключа закрытый определять )
Для таких задач бывает несколько уровней «палевности»:
* когда ключ можно извлечь без дополнительных знаний (довольно плохой вариант, так как позволяет сразу детектировать открытые ключи с бэкдором)
* когда ключ можно извлечь только зная другой ключ симметричного шифрования (в этом случае человек, обнаруживший бэкдор, может сам получить созданные закрытые ключи)
* когда ключ можно извлечь только зная другой ключ ассиметричного шифрования (получше, так как человек, обнаруживший бэкдор, не может получить закрытые ключи)
* когда после обнаружения бэкдора невозможно отличить хорошие ключи от ключей с бэкдором
Безусловно, можно генерировать ключи с очень слабой энтропией, но тогда они будут соответствовать первому уровню, а в идеале хотелось бы получить что-то более близкое к четвёртому.
* когда ключ можно извлечь без дополнительных знаний (довольно плохой вариант, так как позволяет сразу детектировать открытые ключи с бэкдором)
* когда ключ можно извлечь только зная другой ключ симметричного шифрования (в этом случае человек, обнаруживший бэкдор, может сам получить созданные закрытые ключи)
* когда ключ можно извлечь только зная другой ключ ассиметричного шифрования (получше, так как человек, обнаруживший бэкдор, не может получить закрытые ключи)
* когда после обнаружения бэкдора невозможно отличить хорошие ключи от ключей с бэкдором
Безусловно, можно генерировать ключи с очень слабой энтропией, но тогда они будут соответствовать первому уровню, а в идеале хотелось бы получить что-то более близкое к четвёртому.
Ахтунг не пройдёт.
1) ошибка выбора ГПСЧ: «Нам нужен ГПСЧ, который инициализируется секретным значением»
А почему не платой ГСЧ на мат.плате, или ранодомными нажатиями на клавиатуре-мышке (кто-сталкивался с PGP, поймёт)?
2) ошибка использования криптозащиты: «Для каждой ключевой пары RSA, которую мы будем генерировать, мы так же будем генерировать случайную ключевую пару Curve25519, а потом считать общий секрет от публичного ключа этой пары и нашего приватного»
А такой-уж ли «секретный» будет наш общий секрет? Мне кажется это все напомоинает мне способ поместить публичный и приватный ключ в один контейнер, а потом выдать его за приватный.
1) ошибка выбора ГПСЧ: «Нам нужен ГПСЧ, который инициализируется секретным значением»
А почему не платой ГСЧ на мат.плате, или ранодомными нажатиями на клавиатуре-мышке (кто-сталкивался с PGP, поймёт)?
2) ошибка использования криптозащиты: «Для каждой ключевой пары RSA, которую мы будем генерировать, мы так же будем генерировать случайную ключевую пару Curve25519, а потом считать общий секрет от публичного ключа этой пары и нашего приватного»
А такой-уж ли «секретный» будет наш общий секрет? Мне кажется это все напомоинает мне способ поместить публичный и приватный ключ в один контейнер, а потом выдать его за приватный.
А теперь почти то же самое, но для эллиптических кривых: Kleptographic Attacks on Elliptic Curve Cryptosystems (http://paper.ijcsns.org/07_book/201006/20100628.pdf)
Сдаётся мне, что несмотря на скепсис комментаторов, описанный в статье способ всё же где-то пригодится, точнее «будет использован».
А из сообщения, зашифрованного RSA можно извлечь открытый ключ?
kukuruku.co/hub/infosec/backdoor-in-a-public-rsa-key
― без ссылки на хабр :(
― без ссылки на хабр :(
Там есть Original source, но вообще могли бы и написать, да
Ну тут ещё вопрос кто у кого взял в итоге: www.reddit.com/r/crypto/comments/2ss1v5/rsa_key_generation_backdoored_using_curve25519/
Если в настройках УЦ и так уже можно указать возможность сохранения копии в базе УЦ, то нафига все эти извороты?
По моему система, в которой ключевая пара генерируется не клиентом, а сервером — изначально порочна
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Встраиваем бэкдор в публичный ключ RSA