Vladimir Ivanov пишет:

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

Про математически -  всё понятно. Могу ля где-то в SDK увидеть, как передать на подпись внешний хэш?

Например, в PKCS#11 можно вызывать C_Sign с использованием механизма CKM_GOSTR3410 для подписи хеша. При подписи данных с хешированием на борту используется механизм CKM_GOSTR3410_WITH_GOSTR3411. Или, соответственно, аналогичные механизмы для ГОСТ 2012

https://dev.rutoken.ru/pages/viewpage.a … Id=3178538

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

Про математически -  всё понятно. Могу ля где-то в SDK увидеть, как передать на подпись внешний хэш?

В этом-то и вся соль.
В моём понимании токен подписывает тот хэш, который посчитался у него в ячейках памяти (именно железная защищённость вмешательства в процесс).
Если есть способ передать посчитанный где-то во внешней среде хэш и его подписать его, взамен "железного" хеша, то это, конечно снимает вопрос. Вопрос про функции как раз был связан с тем, как именно этот хэш передать на подпись.

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

А если в оперативной памяти подменить не хеш, а данные, передаваемые на подпись?

netlink пишет:

т.е. результаты в первом и втором случае явно не совпадут.

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

В этом-то и вся соль.
В моём понимании токен подписывает тот хэш, который посчитался у него в ячейках памяти (именно железная защищённость вмешательства в процесс).
Если есть способ передать посчитанный где-то во внешней среде хэш и его подписать его, взамен "железного" хеша, то это, конечно снимает вопрос. Вопрос про функции как раз был связан с тем, как именно этот хэш передать на подпись.

Принцип нарушается тем, что если я не использую посчитанный в железе хэш, то могу в оперативной памяти ПК подменить значение и подпишется непонятно что.

Насколько реально (на уровне доработок существующих устройств (изменение техпроцесса производства, увеличение частоты и любой другой способ)) увеличить характеристики устройств для достижения желаемых результатов? Пусть это будет 1 МБ/с для начала.

Технически такое реально вполне. Нужно только разработать, запустить в производство и сертифицировать новое устройство. Сколько устройств с такими характеристиками и по какой цене Вы готовы заказать? Сколько времени Вы готовы ждать сертифицированного устройства?

Как такое решение согласуется с 63-ФЗ, где не идёт речи о подписи хэша файла вместо аппаратного получения хэша?

В 63-ФЗ нет ни слова о том, как и где должен вычисляться хеш. Важно то, что реализация должна пройти процедуру оценки соответствия в виде сертификации.
Иначе, как же работают программные СКЗИ и средства ЭП? Они ведь вычисляют хеш на ЦП

Где можно найти описание низкоуровневых функций по хэшированию и подписи, чтобы проанализировать передаваемые параметры?

Для этого нужно заключить соглашение о технологическом партнерстве и подписать NDA

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

Принцип не нарушается. Ключ подписи (приватный ключ) не принимает участия в процессе вычисления хеша. Ключом подписывается вычисленный хеш. Где он вычислялся не так важно

т.е. результаты в первом и втором случае явно не совпадут.

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

И сама подпись будет содержать хэш хэша?

В моём понимании сам процесс подписания - это расчёт хэша подписываемых данных, а уже затем "наложение" на результат расчёта "сертификата", который нам говорит, кто этот хэш подсчитал.

Т.е. это Hash_Гост2012(Данные) = abcdefd_hash_result + cert

а в случае с подписанием рассчитанного на ЦП хэша мы получаем следующиую формулу:

Hash_Гост2012(CPU_HASH(Данные)) = ebcadf_hash_result + cert

т.е. результаты в первом и втором случае явно не совпадут.

Какой документ (закон) регламентирует легитимность такого подхода?

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

Насколько реально (на уровне доработок существующих устройств (изменение техпроцесса производства, увеличение частоты и любой другой способ)) увеличить характеристики устройств для достижения желаемых результатов? Пусть это будет 1 МБ/с для начала.

Где можно найти описание низкоуровневых функций по хэшированию и подписи, чтобы проанализировать передаваемые параметры?

В случае предварительного хэширования в библиотеке мы, получается, подписываем, уже не сам файл на токене, а его хеш?

Да

Нет

Не нужно накладывать подпись на подписанный хэш. Хеширование и подпись - это независимые операции, которые могут быть разделены по времени и месту.

Для автоматических средств ЭП такое поведение допускается.

Да, частота процессора это один из параметров который влияет на скорость хеширования. Модель с более быстрым процессором мы советовали вам уже ранее - это Рутокен ЭЦП 2.0 128 Кб.

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

netlink, да, именно столько это займет если хеширование выполнять на токене.
Это самый безопасный, но довольно медленный режим.
Если это слишком долго, то можно либо хешировать в библиотеке PKCS#11, тогда 10Мб будет хешироваться всего 1-2 секунды, либо можно использовать Рутокен ЭЦП 2.0 128Кб - в котором скорость хеширования более чем в 2 раза выше.

Добрый день!

В случае предварительного хэширования в библиотеке мы, получается, подписываем, уже не сам файл на токене, а его хеш? И сама подпись будет содержать хэш хэша? Насколько я понимаю нет способа положить подписанный хэш в токен и уже наложить подпись на него, тем самым съэмулировав подпись на токене.
Как такое решение согласуется с 63-ФЗ, где не идёт речи о подписи хэша файла вместо аппаратного получения хэша?

Какие аппаратные свойства токена влияют на скорость обработки информации? Частота работы микропроцессора токена?
Возможно ли её увеличить?

Насколько узабельный вообще будет такой режим использования токена, если скорость обработки всего 22КБ /с, а на дворе 21 век?

Спасибо!

Коллеги, добрый день!

Интересует скорость работы Рутокена ЭЦП 2.0.

В характеристиках написано:
Электронная подпись ГОСТ 34.10-2012(256): 0,3 сек.

Скорость хеширования ГОСТ Р 34.11-2012: до 22 КБ/сек.

Как я понимаю, сначала надо хэш посчитать, а потом уже его подписать?
Сколько займёт по времени подпись 10 МБ файла? Неужели 465 секунд?
Спасибо!