Re: Rutoken ECP2 3000 - ФКН2 под Linux для открытия слотов LUKS2

sanyo пишет:

На сайте Аладдин на странице описания JaCarta 2 упоминается опасность утечки хэш кода при подписании.
В чем суть такой опасности?  Наверно, если подписание со штампами времени используется для доказательства авторства (защиты интеллектуальной собственности на исходники своих программ, например) и нотаризации документов, то при возможности перехвата хэш кодов подписываемых исходников они смогут генерировать свои подписи со штампом времени почти одновременно с оригинальным автором, откуда идет утечка?

Но ведь перехваченный хэш код будет для исходника, в котором уже написано Copyright (c) Вася Пупкин. А с юридической точки зрения для доказательства авторства неважно, кто освидетельствует факт существования такого исходника на определенный момент времени, сам Вася Пупкин или перехватившие хэш код.
С моей точки зрения такой перехват хэша неопасен для подписания исходников для облегчения доказательства их авторства.

А какие еще угрозы могут быть? Например при подписании несекретного договора, в котором нет отклонений от права РФ,  разве есть опасность от утечки такого подписываемого документа (хэш кода документа и/или его в целом)? Подразумевается только readonly считывание (например, удаленное по побочным каналам ПЭМИ) утечки данных без активного вмешательства (манипуляций) в протокол обмена для подмены чего-либо в цепочке подписания на компьютере оригинального автора.

Хеш - это по сути свертка документа. По нему невозможно восстановить исходный документ. Если есть возможность подмены хеша - то можно навязать подпись другого документ.

sanyo пишет:

Планируется ли хотя бы попытка сделать совместимым режим работы токенов типа Рутокен ЭЦП 3.0 NFC с защитой канала данных SESPAKE ФКН2 и SafeTouch PRO каких-нибудь будущих релизов, например в 2021-2022 годах и т.п.?

Прогнозы на текущий момент сложно давать. Всех планов производителя SafeTouch мы не знаем.

sanyo пишет:

Еще Аладдин рекламирует быстрое вычисление хэш кода документа на компьютере вместо слабого микроконтроллера смарткарты, где у вас рассчитываются хэш коды подписываемых документов при использовании для подписания документов Диадок через PKCS11? А в случае использования КриптоПРО v5?
В смарткарту по USB в открытую пересылается весь исходный документ, подписываемый аппаратным СКЗИ на борту Рутокена ЭЦП2 2100?

.
Зависит от того как реализована конкретная система. Мы предоставляем возможность подсчета хеша, как аппаратно, так и программно через сертифицированной PKCS#11. СКЗИ КриптоПро сам считает хеш от подписывамего документа и передает его устройству на подпись.

А нововведения ГОСТ 2015 не собираются сделать обязательными для сертифицированных СКЗИ?

Эти ГОСТы для симметричного шифрования.


Какой ваш предположительный прогноз (без гарантий и обещаний) по длительности жизненного цикла ГОСТ 2012 для юридически значимой ру криптографии?

Такое может знать только ФСБ.

Подводя итог, для открытия слотов LUKS2 ключом без юридически значимого сертификата намного важнее для безопасности именно шифрование канала обмена типа ФКН2, чем авторизация такого шифрования кнопкой на считывателе типа SafeTouch PRO?

Зависит от чего вы защищаетесь. Если говорить про перехват трафика, то: если расшифровывать аппаратно (что медленно) -- траффик будет идти в открытом вид; если расшифровать программно -- то ключ. И то и то, лучше защищать.

А для подписания несекретных юридически значимых документов квалифицированным сертификатом ключа, расположенного на смарткарте, наборот намного важнее для безопасности авторизация кнопкой на считывателе типа SafeTouch PRO, чем шифрование протокола обмена с чипом смарткарты? В том смысле, чтобы злоумышленники не наподписывали чего-нибудь лишнего, чего не хочет подписывать владелец сертификата ЭЦП.

Обычно да, важно убедиться что вы подписываете.

Пункты 1) и 3) почти не отличаются друг от друга, кроме поддержки авторизации по кнопке алгоритма RSA в последнем.

Верно.

Re: Rutoken ECP2 3000 - ФКН2 под Linux для открытия слотов LUKS2

sanyo пишет:

Какие вредоносные манипуляции возможны над туннелем типа OpenSSH и OpenVPN при возможности считывать (например удаленно по побочке ПЭМИ) открытый протокол обмена например с Rutoken ECP2 Touch?
Смогут ли атакующие повторить аутентификацию подключения? Устроить MITM? Или только расшифровать передаваемые через туннель данные и только в текущей перехваченной сессии?

OpenVPN использует TLS. TLS в наши дни использует эфемерные ключи для выработки симметричного ключа. Ключевая пара на токене используется только для аутентификации. Подпись, используемая при аутентификации, генерируется от открытых данных хендшейка. Их может получить пассивный наблюдатель интернет-трафика. Ничего секретного в этих данных нет. Использовать их для расшифрования трафика нельзя, как и сделать MITM.

В SSH ситуация аналогична. Токен используется для challenge-response аутентификации. Challenge уникален, повторно его использовать нельзя.

Так что основной риск -- это перехват PIN-кода самого токена как одного из шагов в атаке, включающей в себя активное взаимодействие атакующего со смарт-картой.

Защита канала взаимодействия со смарт-картой шифрованием актуальна, когда атакующий может не только прослушивать, но и подменять трафик в канале.