Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Получить ГОСТ TLS-сертификат для домена (SSL-сертификат)
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

2 Страницы<12
Опции
К последнему сообщению К первому непрочитанному
Offline neigel  
#11 Оставлено : 31 декабря 2019 г. 11:50:33(UTC)
neigel

Статус: Активный участник

Группы: Участники
Зарегистрирован: 23.12.2014(UTC)
Сообщений: 91
Российская Федерация

Сказал(а) «Спасибо»: 5 раз
Поблагодарили: 2 раз в 2 постах
Автор: Агафьин Сергей Перейти к цитате
Автор: neigel Перейти к цитате
Автор: Агафьин Сергей Перейти к цитате
Автор: neigel Перейти к цитате

Да, но теперь хоть понятно куда копать, а после генерации ключа и сноса этого поделия это прекратится, наверняка.

Да, спасибо большое. Воспроизвел. Будем просить разработчиков плагина исправлять поведение.



Лопатами! Лопатами их просите))) Вот ещё мода: на клиентской машине настройки чужого программного продукта менять.


Связались. Они нашли, где пишут в реестр. Обещали поправить.


Отличная новость! С Новым Годом!
Offline neigel  
#12 Оставлено : 6 февраля 2020 г. 12:53:33(UTC)
neigel

Статус: Активный участник

Группы: Участники
Зарегистрирован: 23.12.2014(UTC)
Сообщений: 91
Российская Федерация

Сказал(а) «Спасибо»: 5 раз
Поблагодарили: 2 раз в 2 постах
Коллеги, и вновь продолжается бой!

Теперь Тензор научил свой СБИС-плагин не шалить в реестре (но это не точно). Тем не менее, когда дело доходит до выработки ключевой пары в их личном кабинете юзера, то предлагаемое окно по выбору ключевого носителя предлагает только реестр, диск и что-то ещё (такое же "тупое"). Если вставить "тупой" носитель, то предлагает его. Если вставить Рутокен ЭЦП 2.0 - даёт его выбрать, но комбобокс с выбором режима даёт выбрать только тупой режим. Рутокен ЭЦП 2.0 3000 (ФКН) не даёт выбрать вообще.

Вопросы:
1) Существует возможность программно указать Крите Пре какие носители он может использовать, а какие нет?
2) Есть ли возможность проигнорировать это дело?

Их поддержка включает человека-робота и говорит о том, что они ФКНы не поддерживают, но если бы они тупо про них забыли - оно бы работало: на лицо именно злонамеренное умышленное отключение возможности использовать ФКН.

ЗЫ: Похоже сотрудничество с этими борцами против ФКН нужно кончать, но уже оплаченные заявки надо довыполнить.
Offline villy21  
#13 Оставлено : 9 февраля 2020 г. 22:28:13(UTC)
villy21

Статус: Новичок

Группы: Участники
Зарегистрирован: 09.02.2020(UTC)
Сообщений: 1
Российская Федерация

Менеджер Тензора может поставить в заявке на ЭП флаг "Рутокен ЭЦП 2.0", тогда при генерации будет использоваться аппаратная СКЗИ. Видимо много раз клиенты ошибались выбирая не тот носитель и ключи для торгов, например, превращались в обычные квалифицированные эцпшки.
Если заявка была создана вручную (не продление, не платная заявка, а созданная из кабинета), то после подтверждения документов перед выбором типа носителя появится окно "с помощью какого криптопровайдера вы хотите сгенерировать запрос" с выбором КриптоПро или Рутокен ЭЦП.
Offline neigel  
#14 Оставлено : 10 февраля 2020 г. 19:08:37(UTC)
neigel

Статус: Активный участник

Группы: Участники
Зарегистрирован: 23.12.2014(UTC)
Сообщений: 91
Российская Федерация

Сказал(а) «Спасибо»: 5 раз
Поблагодарили: 2 раз в 2 постах
Странно, вроде ответил, но не отображается мой ответ. Попробую ещё раз.

Автор: villy21 Перейти к цитате
Менеджер Тензора может поставить в заявке на ЭП флаг "Рутокен ЭЦП 2.0", тогда при генерации будет использоваться аппаратная СКЗИ. Видимо много раз клиенты ошибались выбирая не тот носитель и ключи для торгов, например, превращались в обычные квалифицированные эцпшки.
Если заявка была создана вручную (не продление, не платная заявка, а созданная из кабинета), то после подтверждения документов перед выбором типа носителя появится окно "с помощью какого криптопровайдера вы хотите сгенерировать запрос" с выбором КриптоПро или Рутокен ЭЦП.


Указанный флаг приведет к тому, что будет использован криптопровайдер компании Aktiv (если такой установлен в системе). Это не даст возможность использовать Крипто Про для генерации Рутокен ЭЦП 2.0. Но что ещё хуже - это не даст возможности использовать ФКН (Рутокен ЭЦП 2.0 3000), т.к. последний не является режимом PKSC#11 и не может работать с криптопровайдером Aktiv'а.

Таким образом, это не решает проблему.
Offline Агафьин Сергей  
#15 Оставлено : 11 февраля 2020 г. 12:32:36(UTC)
Grey

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 12.08.2013(UTC)
Сообщений: 834
Мужчина
Российская Федерация
Откуда: Москва

Сказал «Спасибо»: 5 раз
Поблагодарили: 215 раз в 174 постах
Добрый день.
Да, есть разные программные способы ограничить используемые носители. Отключать их - борьба с ветряными мельницами. Если разработчик приложения очень захочет, он может перечислить режимы работы, получить из каждого из них признак "аппаратная криптография" и холодно отрубить.

На данный момент главное, что не нравится Тензору - возможность использовать в CSP ключи на Рутокен ЭЦП 2.0, которые были сгенерированы через PKCS#11. Их у пользователей много - это приводит к замедлению какого-то базового кейса работы с плагином. Они пробовали решить проблему через настройку в реестре - она отрубила вообще все активные носители всем. Сейчас мы подсказали им менее вредящий путь - в следующей сборке плагина будет исправление, которое починит работу остальных приложений. Дополнительно попросил Тензор не отключать ФКН.

Чтобы отключать более выборочно режимы работы носителей (в данном случае - не всю неизвлекаемую криптографию, а только PKCS#11) мы добавили в провайдере поддержку точных фильтров по уникальным именам. К сожалению, она появилась уже после выпуска сертифицированной версии, так что её встраивание в плагин будет после выпуска следующего провайдера.
С уважением,
Сергей
Техническую поддержку оказываем здесь.
Наша база знаний.
Offline neigel  
#16 Оставлено : 11 февраля 2020 г. 18:51:52(UTC)
neigel

Статус: Активный участник

Группы: Участники
Зарегистрирован: 23.12.2014(UTC)
Сообщений: 91
Российская Федерация

Сказал(а) «Спасибо»: 5 раз
Поблагодарили: 2 раз в 2 постах
Сергей, спасибо за информативный ответ.

Автор: Агафьин Сергей Перейти к цитате
Добрый день.
На данный момент главное, что не нравится Тензору - возможность использовать в CSP ключи на Рутокен ЭЦП 2.0, которые были сгенерированы через PKCS#11. Их у пользователей много - это приводит к замедлению какого-то базового кейса работы с плагином.


Такая проблема действительно есть и ловится не только при работе с ресурсами Тензора. В целом когда приложению через криптопровайдер нужно получить список имеющихся сертификатов с ключами, или выбрать один из них для совершения операции, в случае с PKCS#11 это может занимать до минуты, если таких ключей на одном носителе много. При 8 ключах (было во времена перехода на 2012-е ГОСТы) - уже около минуты.

Автор: Агафьин Сергей Перейти к цитате
Они пробовали решить проблему через настройку в реестре - она отрубила вообще все активные носители всем. Сейчас мы подсказали им менее вредящий путь - в следующей сборке плагина будет исправление, которое починит работу остальных приложений. Дополнительно попросил Тензор не отключать ФКН.

Чтобы отключать более выборочно режимы работы носителей (в данном случае - не всю неизвлекаемую криптографию, а только PKCS#11) мы добавили в провайдере поддержку точных фильтров по уникальным именам. К сожалению, она появилась уже после выпуска сертифицированной версии, так что её встраивание в плагин будет после выпуска следующего провайдера.


Надеюсь, что "неотключение" ФКН быстро прорастет в их СБИС-плагин. А, в связи с написанным вами, ещё один вопрос: можете ли вы подтвердить или опровергнуть, что ФКНы не подвержены проблеме долгого перечисления ключей? Это был бы дополнительный плюс в копилку знаний о преимуществах перехода на ФКН.

P.S.: пока накопал старую версию дистрибутива СБИС-плагина и сгенерировал пару ей.

Отредактировано пользователем 11 февраля 2020 г. 18:57:55(UTC)  | Причина: Не указана

Offline Агафьин Сергей  
#17 Оставлено : 11 февраля 2020 г. 19:47:23(UTC)
Grey

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 12.08.2013(UTC)
Сообщений: 834
Мужчина
Российская Федерация
Откуда: Москва

Сказал «Спасибо»: 5 раз
Поблагодарили: 215 раз в 174 постах
Автор: neigel Перейти к цитате

Такая проблема действительно есть и ловится не только при работе с ресурсами Тензора. В целом когда приложению через криптопровайдер нужно получить список имеющихся сертификатов с ключами, или выбрать один из них для совершения операции, в случае с PKCS#11 это может занимать до минуты, если таких ключей на одном носителе много. При 8 ключах (было во времена перехода на 2012-е ГОСТы) - уже около минуты.

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

Автор: neigel Перейти к цитате

Надеюсь, что "неотключение" ФКН быстро прорастет в их СБИС-плагин.

Тензор подтвердил, что в коде новой версии будет отключен только "активный" режим, но не ФКН.
Автор: neigel Перейти к цитате

А, в связи с написанным вами, ещё один вопрос: можете ли вы подтвердить или опровергнуть, что ФКНы не подвержены проблеме долгого перечисления ключей? Это был бы дополнительный плюс в копилку знаний о преимуществах перехода на ФКН.

Для ФКН все разработчики токенов делали вообще новый набор команд. Так что в отличие от PKCS#11, где на перечислении контейнера читается сертификат (иначе мы работать в этом режиме не можем), в ФКН-токенах просто перечисляются папки в конкретной ФКН-директории.

Проверил на своей машине. Перечисление 8 контейнеров на Рутокен 3000 занимает 1.5 секунды. Перечисление их же с запросом сертификатов около 3-4 секунд. СмартПарк ФКН (Форос-2) и Gemalto ФКН работают на том же порядке производительности. Инфокрипт Токен++ в несколько раз быстрее.
С уважением,
Сергей
Техническую поддержку оказываем здесь.
Наша база знаний.
Offline two_oceans  
#18 Оставлено : 12 февраля 2020 г. 6:26:41(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,602
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Цитата:
При 8 ключах (было во времена перехода на 2012-е ГОСТы) - уже около минуты.
Причем не обязательно 8 ключей должны быть на токене, у меня был случай с 9 ключами на локальном диске и 1 ключе на токене, задержка секунд 10-15 пока не подключен токен, как только токен подключался сразу задержка около 100 секунд. То есть зависимость времени почти квадратичная от количества контейнеров/сертификатов.

Очень рад, что замаячил такой рост производительности при работе с токенами. Для ручного подписания конечно перечисление менее чем за 5 секунд - замечательно. Психологически конечно лучше укладываться в 3 секунды (или сколько там мгновенная память у человека), при более длительном ожидании появляется ощущение зависания программ.

Наверно это немного не в тему, но не могу не спросить.
Вопрос: есть ли какое-то продвижение в плане производительности массового подписания ключами на токенах? Если в режиме ФКН, то вообще идеально.

Не знаю, например, какое-нибудь кэширование доступа к определенному контейнеру на токене минут на 15. Чтобы без лишних перечислений, переустановок защищенного канала к токену и т.д. просто передавать новые данные на вычисление подписи. Конечно, полагаю, есть предел аппаратных возможностей в случае режима ФКН, но и программную часть наверно можно "разогнать" (как со стороны криптопровайдера-драйвера, так и со стороны прикладного ПО)?

Отредактировано пользователем 12 февраля 2020 г. 6:39:46(UTC)  | Причина: Не указана

Offline Агафьин Сергей  
#19 Оставлено : 12 февраля 2020 г. 12:32:07(UTC)
Grey

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 12.08.2013(UTC)
Сообщений: 834
Мужчина
Российская Федерация
Откуда: Москва

Сказал «Спасибо»: 5 раз
Поблагодарили: 215 раз в 174 постах
Автор: two_oceans Перейти к цитате
На ИС областного уровня временами может достигаться поток сообщений в СМЭВ порядка 1500 сообщений в секунду, при этом требуется наложение на них ЭП-ОВ. До сих пор не было возможности (из-за низкой производительности режима PKCS11, полагаю) использовать токены для таких массовых операций и приходилось хранить ключи в реестре (что не очень согласуется с требованиями КС2 для ИС) или эмулировать диск в памяти (тоже не так безопасно) или использовать несколько копий контейнера на разных носителях (а то и разных серверах что финансово накладно). И даже так в "часы пик" запросы могут висеть неотправленными несколько минут пока до них дойдет очередь подписания. Для СМЭВ 3 ждать секунды нормально, но доводить до минут не хотелось бы. Вопрос: есть ли какое-то продвижение в плане производительности массового подписания ключами на токенах? Если в режиме ФКН, то вообще идеально.

Не знаю, например, какое-нибудь кэширование доступа к определенному контейнеру на токене минут на 15. Чтобы без лишних перечислений, переустановок защищенного канала к токену и т.д. просто передавать новые данные на вычисление подписи. Конечно, полагаю, есть предел аппаратных возможностей в случае режима ФКН, но и программную часть наверно можно "разогнать" (как со стороны криптопровайдера-драйвера, так и со стороны прикладного ПО)?

Тут ответ состоит из двух частей.

Во-первых, оптимизация самого вызывающего кода. Если для каждой подписи происходит перечисление контейнеров, затем открытие по короткому имени и закрытие после одной подписи, конечно, тормоза будут жуткие.
1) Если изначально получить полное имя контейнера (FQCN | UNIQUE) и по нему открывать, то большого влияния на работу перечисление оказывать не будет.
2) Закрывать контекст тоже не нужно. Если большой поток SignHash-ей не будет прерываться "паразитными" обращениями к токену, но они все будут подписываться под одним защищенным каналом.
3) Поскольку CSP - это библиотека, мы не можем блокировать на себя токен между CryptoAPI вызовами. Всегда должны учитывать, что другое приложение сбросить его состояние. У меня была мысль сделать "камикадзе-mode", в котором будут отключены все предварительные доведения до требуемого состояния (перевыборы приложения, переоткрытия папок), но пока не было мотивации. Может, теперь попробуем.

Во-вторых, есть и физические ограничения от самого вычислителя в токене. Например, для Рутокен ЭЦП (в т.ч. и ФКН) в наших тестах предел - 3 подписи/секунду. Если не масштабировать задачу до "фермы" из токенов, каждая секунда трафика, где 1500 сообщений, будет обрабатываться 500 секунд (~8 минут).
Самые быстрые токены, что у нас были в тестах, - Инфокрипт Токен++ (ФКН). У них время подписи - 6 оп/сек. Всего в два раза быстрее. Каких-то фантастических результатов тут, к сожалению, не достичь.

Если нужна производительность и уровень защиты выше КС1, может, стоит рассмотреть "большой токен" - HSM?

С уважением,
Сергей
Техническую поддержку оказываем здесь.
Наша база знаний.
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
2 Страницы<12
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.