Копия:

http://www.freezepage.com/1605256578ISUQYDSSHP

https://www.cryptopro.ru/forum2/default … #post92583

sanyo пишет:

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

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

Павел, добрый день,

Пожалуйста, уточните, работал ли ранее защищенный режим  ФКН v1 в старом токене eToken совместно с SafeTouch?

https://www.cryptopro.ru/news/2012/07/t … -apparatno

Это 2012 год, копия:
http://www.freezepage.com/1604852219COBVSBWTVG

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Верно.

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

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

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

Аладдин рекламирует наличие в их смарткартах JaCarta 2 защиты канала обмена данными с помощью так называемого secure messaging, но как выяснилось из переписки с ними, с SafeTouch PRO их secure messaging тоже не работает как и ваш ФКН2.

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

Что мешает передавать необходимые для авторизации в SafeTouch PRO данные открыто без шифрования или хотя бы открыто дублировать их, а остальные данные шифровать с помощью ФКН2 или secure messaging как это и происходит уже сейчас при использовании соответствующих моделей Рутокен ЭЦП 3.0 NFC и JaCarta 2 в обычных считывателях (НЕ SafeTouch PRO)?

Хотя с другой стороны получается, что ФКН2 при отсутствии активных троянов на компьютере пользователя полезен с точки зрения безопасности только для шифровани/дешифрования строк, например, как раз по данной теме форума изначально для открытия слотов LUKS2, а для подписания документов бесполезен?

И смысла авторизовать кнопкой транзакции шифрования/дешифрования наверно меньше особенно при кратковременном подключении смарткарты в preboot environment для открытия слота LUKS2 системного root раздела Linux, чем для подписания документов после загрузки системы, когда смарткарта подолгу не вынимается из считывателя? SafeTouch PRO вообще умеет сейчас без дополнительной интеграции авторизовать что-либо кроме транзакций на подпись ГОСТ алгоритмами смарткат поколения Rutoken 2100 и аналогичных от Аладдин?

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

Впрочем без шифрования дисков по SATA шине также все передается в открытую, да еще добавьте закладки в прошивках дисков, вероятно даже для удаленного управления компьютером через закладки в драйверах дисков, причем возможно по интегрированным в современные дорогие диски модемам на гармониках в сети 220В либо радиочипы. Предположительно от таких закладок можно избавиться хотя бы частично (кроме внезапной полной потери данных по сигналу извне) от их активного влияния на рабочую станцию (вплоть до воздействия на файлы через VFS) огораживанием дисков на отдельном выделенном хосте (например одноплатнике с подключенным SATA хабом на несколько устройств) и проброса с него данных через iSCSI.

Т.е. примерно так:
Доверенная рабочая станция Libreboot+Libre Kernel(без обфусцированных модулей ядра) + Devuan (без systemD): ZFS-> LUKS2-> iSCSI client ->
Выделенный хост для дисков: iSCSI target -> виртуальное блочное устройство на каком-нибудь массиве LVM2/ZFS -> собственно диски (с проприетарными закладками).

после чего прямой контакт (связь) между закладками ядра рабочей станции и закладками в прошивках дисков теряется.

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

Например, если я правильно понимаю, то прошлый ГОСТ 2001 прожил с 2004 года около 15 лет до 2019 года?
Без учета форс мажоров от развития квантовых компьютеров наверно можно ожидать использования ГОСТ 2012 до примерно 2030 года, если по аналогии со старым ГОСТ-ом?

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

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

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

Интересно, есть ли какие-либо преимущества у токенов с защитой канала обмена данными типа ФКН2 или SCP, secure messaging и т.п. при использовании таких токенов для хранения неизвлекаемых ключей коммуникационных туннелей?

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

Тогда возможные оптимальные use cases получаются такие:

1) Для подписания документов:    КриптоАРМ_или_Диадок + SafeTouch_PRO+Rutoken_ECP2_2100.
2) Для шифрования и дешифрования секретных данных типа ключей слотов LUKS2:  Rutoken ECP2 3000 или Rutoken ECP3 NFC со включенным протоколом ФКН2.
3) Для туннельных сессий типа OpenSSH RSA:     Rutoken ECP2 Touch (с кнопкой).

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

Согласны?

1. ФКН2 есть только в Смарт-карта Рутокен ЭЦП 3.0 NFC. Пока доступна продажа только крупными партиями.

2. Safetouch  PRO не поддерживает SESPAKE и работа с ФКН ключами с подтверждением не получится.

3. Нужно будет проверить. Не обещаю быстро.

4. Мы предполагаем, что нужно будет прошивать.  Детали известны только производителю.

5. Верно.

Пока ГОСТ-2012 не собирается устаревать.
Про сертификат ответила вам в соседней ветке. Будет произведено продление сертификата.

Совсем скоро появятся новые смарт-карты, поддерживающие ФКН2. Они будут поддерживать RSA-2048 и 4096

Подразумевается "Смарт-карта Рутокен ЭЦП 3.0 NFC"
https://www.rutoken.ru/products/catalogue/id_114.html

или какая-то другая новая карта?

Не помешает ли ФКН2 работе SafeTouch PRO?

ФКН2 не помешает, но сам SefeTouch на текущий момент не имеет реализации ФКН2. Это значит, что команды, связанные с визуализацией и подтверждением на устройстве, будут идти по открытому каналу.

Добрый день Павел,

Вопросы:

1) Сейчас ведь у вас пока нет плоских смарткарт с поддержкой ФКН2?

2) На данный момент существует какая-то рабочая комбинация SafeTouch PRO и вашего токена с ФКН2 наверно USB Rutoken  3000, которые могут работать вместе, причем, чтобы пользовательские данные для шифрования/дешифрования передавались к/от токена по закрытому каналу ФКН2? А чтобы какой-то минимум управляющих данных передавался без шифрования ФКН2, чтобы SafeTouch PRO мог подтверждать транзакции своей кнопкой, так возможно?

3) Например, будет ли работать связка USB Rutoken 3000 + SafeTouch PRO + КриптоАРМ при условии, если КриптоАРМ нормально работает с SafeTouch PRO + Rutoken 2000/2100?
Или с ФКН2 токенами с включенным режимом ФКН2  SafeTouch PRO будет работать только как обычный считыватель смарткарт без подтверждения транзакций?

4) Как думаете (без гарантий и обещаний), возможно ли будет прошить SafeTouch PRO для поддержки ваших будущих смарткарт? Ограничения для такой возможности - это только доступность прошивок только для банковских работников или может быть какая-то аппаратная несовместимость экземпляра устройства SafeTouch PRO 2018 с прошивкой SafeTouch PRO 2022?

5) Получается, на данный момент гарантированно точно работают с SafeTouch PRO ваши плоские смарткарты  Rutoken ECP2 2100 (это полный аналог USB Rutoken ECP2 2000?).

Как долго существующие ГОСТ-ы РФ для генерации квалифицированной ЭЦП будут позволять использовать алгоритмы ГОСТ 2012?  Когда планируется устаревание токенов с алгоритмами ГОСТ 2012 для использования с ЭЦП, УЦ и т.п.? Т.е. когда Rutoken ECP2 станет таким же устаревшим, как Rutoken ECP(1) или как eToken (современная модель - это ведь JaCarta 2).

Сертификат Rutoken 2100 заканчивается примерно через полгода?
Будет продление этого сертификата для Rutoken 2100 или через полгода Rutoken 2100 с точки зрения пригодности для генерации юридически значимой ЭЦП превратится в тыкву, а вместе с ним и считыватели
SafeTouch PRO 2018?

К сожалению, нет. Вы верно предположили, что SafeTouch работает с устройствами из белого списка

Верно

ФКН2 не помешает, но сам SefeTouch на текущий момент не имеет реализации ФКН2. Это значит, что команды, связанные с визуализацией и подтверждением на устройстве, будут идти по открытому каналу.

Да, обычные смарт-карты. В Linux тоже будет работать.
SESPAKE (ФКН2) использует ГОСТ алгоритмы.

Пожалуйста, уточните, будут ли работать такие ваши новые смарткарты по ФКН2 со считывателями SafeTouch PRO 2018-2019 годов выпусков (те которые сейчас продаются в банках) без дополнительной прошивки считывателя?

Насколько я понял, SafeTouch PRO работает только с ГОСТовыми алгоритмами и только для тех смарткарт, которые в его белом списке, в т.ч. как минимум с Rutoken ECP2 2000 и 2100?
Не помешает ли ФКН2 работе SafeTouch PRO? Не потеряется ли совместимость или SafeTouch PRO просто не признает более новую карту, чем его прошивка и работать с ней не будет вне зависимости от использования протокола ФКН2?

Была бы также полезна и совместимость с современной версией v3.4 стандарта OpenPGP Card :)

Для смарт-карт, поддерживающих интерфейс PKCS#11, есть решение, заключающееся в использовании PKCS#11 демона смарт-карт. Данный демон эмулирует работу со смарт-картами, работающими через интерфейс PKCS#11 так, как будто они поддерживают интерфейс OpenPGP.

Как это сделать подробно описано в статье: https://m.habr.com/ru/company/aktiv-com … og/491054/

Это ведь работает только с ключами RSA? А хотелось бы еще и ключи EC и даже Ed25519,

желательно все, что есть в Nitrokey Start:
https://shop.nitrokey.com/shop/product/ … ey-start-6

только на более безопасной и вероятно более производительной платформе типа ваших смарткарт Rutoken ECP2 да еще и с шифрованием обмена данными ФКН2 по интерфейсу PKCS11 -  было бы вообще шикарно.

Внутренности Nitrokey Start (кроме SoC) полностью опенсорсны и его можно повторить на копеечном железе:

https://blog.danman.eu/2-usb-crypto-tok … g-and-ssh/
https://habr.com/ru/post/496946/
https://habr.com/ru/post/487748/

Вы правы, не нужно. Для ФКН2 контейнеров шифрование прозрачно для пользователя.

Магма и Кузнечик уже будут в ближайших продуктах.

Для смарт-карт, поддерживающих интерфейс PKCS#11, есть решение, заключающееся в использовании PKCS#11 демона смарт-карт. Данный демон эмулирует работу со смарт-картами, работающими через интерфейс PKCS#11 так, как будто они поддерживают интерфейс OpenPGP.

Как это сделать подробно описано в статье: https://m.habr.com/ru/company/aktiv-com … og/491054/

Про остальное - спасибо, будем думать.