Атаки по побочным каналам давно перестали относиться к разряду доступных только спецслужбам – регулярно появляются новые и новые открытые публикации как по теоретическим аспектам атак по побочным каналам, так и содержащие отчеты об успешном взломе тех или иных криптосредств по излучению, колебаниям напряжения и даже акустическим побочным каналам.

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

Аспекты стойкости протокола TLS, являющегося одним из повсеместно используемых для защиты информации в сетях, обсуждаются не только в рамках классических моделей безопасности протоколов (см. статьи 1, 2 и 3 нашего блога), но и в контексте обеспечения защиты данных в протоколах более высокого уровня, которые зачастую используют TLS довольно нетипичными (и, полагаем, не рассматривавшимися изначально разработчиками протокола SSL/TLS) способами. В 2009 году была обнаружена уязвимость при использовании TLS одним из таких способов. Данной уязвимости, ставшей причиной введения в RFC 5746 расширения Renegotiation Indication, и посвящена данная статья.

На весеннем заседании технического комитета по стандартизации "Криптографическая защита информации" (ТК 26) был утвержден набор из четырех документов (технических спецификаций и методических рекомендаций), разработанных специалистами нашей компании. В настоящей заметке приводится краткий обзор содержания данных документов, а также рассказывается о целях их создания.

На заседании технического комитета по стандартизации "Криптографическая защита информации" (ТК 26) утвержден проект документа "Методические рекомендации по заданию параметров эллиптических кривых в соответствии с ГОСТ Р 34.10-2012", созданного специалистами нашей компании. В настоящей заметке рассказывается о цели этого документа и о принципах выбора кривых, которыми мы руководствовались.

Результатом очередного крупного этапа работ над нашим новым криптопровайдером, КриптоПро CSP версии 4.0, стал релиз КриптоПро CSP 4.0 Bernoulli. В дополнение к большому числу исправлений и улучшений кода, новый релиз отличает от старого ряд существенных нововведений, о которых мы и расскажем в этой заметке.

Мы выпустили новую версию криптопровайдера – КриптоПро CSP версии 4.0. Выпуск "четверки" является значительной вехой в развитии нашего флагманского продукта. Теперь, в дополнение к функционалу предыдущих версий, наш провайдер обладает полной поддержкой алгоритмов вычисления и проверки подписи по ГОСТ Р 34.10-2012, вычисления хэш-функции по ГОСТ Р 34.11-2012, а также обеспечивает поддержку сопутствующих криптографических алгоритмов.

В последние годы появляется большое количество статей, посвященных анализу российского алгоритма блокового («блочного») шифрования ГОСТ 28147-89 (см. [ГОСТ]). Одновременно с этим в российских СМИ и блогах российских пользователей растет число заметок о данном алгоритме: как освещающих различной степени достоверности результаты атак на российский стандарт, так и содержащих мнения о его эксплуатационных характеристиках. У авторов (а, следовательно, и читателей) данных заметок зачастую складывается впечатление, что отечественный алгоритм шифрования является морально устаревшим, медленным и обладающим уязвимостями, делающими его подверженным атакам в существенной мере больше, чем зарубежные алгоритмы шифрования с аналогичной длиной ключа. Данной серией заметок мы хотели бы в доступной форме рассказать о настоящем положении дел с российским стандартом. В первой части будут освещены все известные международной криптографической общественности атаки на ГОСТ 28147-89, текущие оценки его стойкости. В будущих публикациях мы также подробно рассмотрим свойства стандарта с точки зрения возможности построения эффективных реализаций.

Продолжая традицию, начатую в статьях 1 и 2 нашего блога, предлагаем обсудить еще одну из атак на протокол TLS. В сегодняшней статье будет рассмотрено, как предпринятые в TLS 1.1 и TLS 1.2 контрмеры, направленные на устранение уязвимости протокола к атакам, основанным на методах Барда-Дэя и Воденея, сами привели к возникновению новых уязвимостей и к появлению новых типов атак.

В октябре текущего года правительство осчастливило всех операторов связи Постановлением №1101 от 26 октября 2012 года "О единой автоматизированной информационной системе "Единый реестр доменных имён, указателей страниц сайтов в информационно-телекоммуникационной сети "Интернет" и сетевых адресов, позволяющих идентифицировать сайты в информационно-телекоммуникационной сети "Интернет", содержащие информацию, распространение которой в Российской Федерации запрещено". В связи с этим постановлением, каждый провайдер обязан блокировать доступ к сайтам, находящимся в списке запрещенных. Чтобы получить доступ к реестру оператору требуется сформировать специальный запрос и подписать его квалифицированной подписью. Звучит страшно? На самом деле, всё просто.

Недавно в этом блоге мы открыли тему интеграции со СМЭВ с использованием наших продуктов. Прошлая статья посвящена разработке на платформе .NET.

В продолжение темы мы хотим рассмотреть пример взаимодействия со СМЭВ с использованием платформы Java.

Для запуска примера необходимо: