Блог КриптоПро

Квалифицированная электронная подпись в облаке как она есть

 

Cloud signature

В традиционном, привычном для подавляющего большинства пользователей понимании электронной подписи (ЭП) ключ этой самой подписи хранится у её владельца. Чаще всего для этого используется некий защищённый ключевой носитель в формате USB-токена или смарт-карты, который пользователь может носить с собой. Этот ключевой носитель тщательно оберегается владельцем от посторонних лиц, поскольку попадание ключа в чужие руки означает его компрометацию. Для использования ключа на устройстве владельца устанавливается специализированное программное обеспечение (СКЗИ), предназначенное для вычисления ЭП.

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

Немного об атаках по побочным каналам

 

Head: side channel

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

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

Зачем нужен Renegotiation Indication в TLS

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

Методические рекомендации ТК 26: алгоритмы, сертификаты, CMS, TLS

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

Свой или чужой УЦ?

В свете все более широкого применения квалифицированной электронной подписи перед каждой организацией встает вопрос: "Стоит ли создавать свой удостоверяющий центр (здесь и далее "свой УЦ") или проще и выгоднее воспользоваться услугами одного из существующих аккредитованных УЦ ("чужой УЦ)". Сегодня мы попробуем ответить на этот вопрос с помощью сухих цифр.

Эллиптические кривые для нового стандарта электронной подписи

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

 

Второй релиз КриптоПро CSP 4.0: чем Бернулли лучше Архимеда?

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

Пара слов о КриптоПро CSP 4.0

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

ГОСТ 28147-89: «Не спеши его хоронить». Часть 1. Стойкость алгоритма.

Isobe

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

КриптоПро TLS против счастливого числа 13

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

Купить

Форма заказа

Вход

Подписка на обновления