Нажатие на кнопку "Создать проект" повесило сайт на 20 секунд. Не само создание, а просто переход между двумя страничками в визарде. Так что да, железо и правда... стоит своих денег.
Официальная позиция КриптоПро по данной истории.
Исходя из информации, полученной нами от Тензора, главная причина, по которой было использовано подобное решение, — серьезное замедление работы функции перечисления, связанное с большим количеством «неизвлекаемых» ключей на токенах Рутокен ЭЦП, которые используют пользователи.
Каких-либо подтверждений тому, что имел место какой-то злой умысел, подразумевающий неавторизованное копирование и/или передачу ключей, мы обнаружить не смогли.
Ситуация, с которой столкнулся автор статьи, скорее всего, является следствием неудачного стечения обстоятельств и недостатка коммуникации между разработчиками.
Все предположения, сделанные автором статьи, являются исключительно его собственными домыслами, не нашедшими подтверждения в действительности.
> Возьму и напишу тестовую программку, которая будет устанавливать с ключем соединение и просить его подписать тестовый хэш.
Тогда запрашивайте у производителей описание APDU работы с токеном. Нам они передаются обычно под NDA.
> Холмс, но как черт-возьми? Если вы сами даёте в руки этим варварам возможность отключать работу с неизвлекаемым режимом.
Неочевидная аналогия. Сейчас весь мир для платежей использует чиповые EMV-карты, которые устанавливают SecureMessaging, аутентифицируют с помощью RSA и вообще прекрасны. Их проникновение в большинстве стран выше 90%. Кроме одной — США. Почему так? Ответ простой — США мощно развили систему платежей картами с магнитной полосой. Все понимают, что они менее безопасные, но перейти сходу на EMV невозможно — для этого требуются слишком большие затраты. Процесс перехода осторожно движется, но пока далек от завершения.
У нас ровно тоже самое. Криптопровайдер, который хранит ключи в пассивном виде, появился 20 лет назад. Вокруг него построено огромное количество софта. Люди накупили пассивных токенов (других тогда не было!). Взять сейчас и сказать «давайте все переходим на неизвлекаемые ключи и ФКН!» можно, но кто будет-то?
> Выше, по-моему, вы писали, что ФКНы так не объегоришь.
Точно так. ФКН — это мощь. Вот только этих носителей пока единицы. И ошибиться с ними намного сложнее, чем с простыми Рутокен ЭЦП или JaCarta ГОСТ.
На этот вопрос я не ответил, потому что его не понял. Вы предлагаете завести ключ в реестр для отключения функциональности, которая включается ключом в реестре? А если они и о нем узнают?))
> Да нахрен ваши исходиники? ) Формата команд ISO 7816 достаточно. Я же говорю «протокол» — в смысле реализация SESPAKE (довольно абстрактной сущности) в виде конкретных полей команд и структур, а не реализация конретного протокола на языке программирования.
Ничего не понял. Команды реализуют токены, мы их зовем согласно документации. Вам станет легче, если я скажу, что команда 0x00, 0x80, 0x00, 0x01 делает первый шаг SESPAKE, а 0x00, 0x80, 0x00, 0x02 — второй? Как вы это верифицируете? Посмотрите на «похожесть» структур? А с чего вы будете уверены, что токен и провайдер установили именно тот ключ, что указан в протоколе, а не просто константу?
> То есть вы находите, что защита идиотов важнее самой концепции «закрытый ключ знает только владелец»? )))
Я живу в реальном мире, где нашим ПО пользуются в большинстве своем люди, которые не отличают закрытый ключ от открытого и на полном серьезе «подписывают сертификатами». Они относятся к переданному токену и криптопровайдеру не как к серьезному средству защиты, а как к формальности, навязанной «сверху». Для них, по моему мнению, важно максимально упростить переход на новые версии продукта по-максимуму обеспечивая совместимость.
Если же служба безопасности компании или сам пользователь понимают, чего они хотят и к чему это приведет в итоге, пусть выбирают неизвлекаемые режимы.
Повторюсь, вы напрасно считаете, что наличие закрытого ключа в памяти токена спасет от какого-то серьезного взлома. Утром вредонос перехватывает APDU для аутентификации на Рутокене и узнает пароль, вечером предъявляет его и подписывает документ. Это явно лучше обычного пассивного контейнера, т.к. нарушитель должен быть «активным», но я с трудом себе представляю адекватность подобного разделения возможностей в какой-либо худо-бедно близкой к реальности модели.
1) Вообще говоря, большинство софта работает не с ключами, а с сертификатами. Имя провайдера находится в ссылке сертификата на закрытый ключ. Для низкоуровневой работы на уровне CryptoAPI 1.0, действительно, нужно писать другую константу (такое уж API), но пользовательский софт этого может и не знать.
2) SESPAKE — криптографический протокол, который прошел достаточные исследования и имеет доказанную стойкость (см., например, статью на Хабре). Аудит проводят сертифицирующие органы. В целом про исходники странный вопрос — у нас не open-source проект. Открытие реализации даже какой-то части (например, реализации SESPAKE) никак не позволит убедиться в том, что она вообще используется.
3) При большом количестве пользователей даже мера «не давать ошибиться в окне» не помогает.
4) Да, про архивацию полностью согласен. Одно дело, сохранять ключ, когда тебя просят (или когда ты делаешь это всегда, а пользователь в курсе), другое — кидать его втихую по почте.
Добрый день.
У автора, как и написано в заголовке, 100% оценочное суждение и небольшой недостаток информации. Будучи человеком, отвечающим в КриптоПро за работу с токенами, выскажу своё мнение. Думаю, оно не будет сильно отличаться от официального.
1) КриптоПро уже больше 10 лет выпускает провайдеры, работающие с неизвлекаемыми ключами. Они называются ФКН (Рутокен CSP, Jacarta CSP, Magistra CSP и т.д.). Если пользователей волновало именно использование неизвлекаемых ключей, они покупали ФКН. В CSP 5.0 просто объединили ФКН-провайдеры и "базовый".
2) Слухи о безопасности "обычных" неизвлекаемых ключей сильно преувеличены. Может, токен и не даёт ключу утечь, но без защищенного канала вредонос может послать пару команд и подписать на токене сам что-угодно, тк в большинстве случаев пароль предъявляется в "голом" виде и может быть заснифферен проще ключей. Хотите безопасности — используйте токены с защищённом каналом.
3) Не думаю, что у Тензора была какая-то злая воля (хотя, конечно, бесит, что до сих пор нам даже сроков исправления не назвали). Скорее, логика такая: людей с CSP 4.0 (там нет неизвлекаемых ключей) намного больше, поэтому пока, чтобы не получилось ситуации, в которой человек не может пользоваться ключом в старом провайдере, сделаем плавный переход, запретив работу с неизвлекаемыми ключами. О том, что это может мешать, никто не подумал. Собственно, я добавил функциональность, которой они так "злобно" пользуются, по просьбе других клиентов ровно для решения данной задачи.
4) Вообще говоря, возможность архивирования ключей — штатная вещь в интерфейсе криптографии CryptoAPI. Да, нельзя это делать без ведома пользователя, но учитывая низкую надёжность токенов (уж просто поверьте, постоянно отвечаем людям с такими проблемами) при должной защите это может быть неплохо. Например, почему бы не иметь шифрованный архив ключей корпоративного УЦ?
Отвечая на ваш исходный вопрос. Если пользователь заявляет, что он не подписывал ничего, это эквивалентно обвинению в преступлении со стороны сотрудников облачного сервиса. Так что доказательства уходящему в отказ от операции человеку, вроде как, нужно собирать самому.
Могу только фантазировать. А чем этот кейс отличается от, например интернет-банка. Как клиент докажет, что транзакцию с переводом выполнил он, а не админ банка? Кажется, что журналов сервера должно быть достаточно, если есть механизм проверки их подлинности.
Не знаю насчёт конкретно описанной системы, но используемый автором DSS позволяет, во-первых, дополнительно шифровать ключи на ПИНе пользователя, а во-вторых не просто высылать одноразовые коды, а отправлять на телефон непосредственно подписываемые данные. Так что можно быть уверенным, что ни выполнить операцию ни подменить её без участия пользователя нельзя.
Еще раз. Я говорю не о КриптоПро CSP, а о КриптоПро Рутокен CSP и КриптоПро eToken GOST. То, что люди покупают продукт, который не умеет (не умел) в активные ключи — это другой вопрос.
В продуктах КриптоПро поддерживаются активные токены очень давно — в рамках продуктов ФКН: КриптоПро Рутокен CSP 3.6/3.9 работали с Рутокен ЭЦП и Рутокен ЭЦП 2.0, а КриптоПро eToken GOST с, соответственно, еТокен ГОСТ и JaCarta ГОСТ.
В КриптоПро CSP 5.0 появилась одновременная работа как с пассивными, так и с активными токенами.
Нажатие на кнопку "Создать проект" повесило сайт на 20 секунд. Не само создание, а просто переход между двумя страничками в визарде. Так что да, железо и правда... стоит своих денег.
С самого начала текста зрело какое-то смутное подозрение. Но абзац про компетентных менеджеров Сталина и Берию всё расставил по местам.
Весь посыл статьи: "Вот раньше-то были люди! Махины! А сейчас-то что, а? Сидят в этом своем ютубе, читать не хотят!".
На Маке наоборот нет варианта, при котором провайдер работает в службе - только в памяти приложения. Закрываете приложение - выгружается провайдер.
Исходя из информации, полученной нами от Тензора, главная причина, по которой было использовано подобное решение, — серьезное замедление работы функции перечисления, связанное с большим количеством «неизвлекаемых» ключей на токенах Рутокен ЭЦП, которые используют пользователи.
Каких-либо подтверждений тому, что имел место какой-то злой умысел, подразумевающий неавторизованное копирование и/или передачу ключей, мы обнаружить не смогли.
Ситуация, с которой столкнулся автор статьи, скорее всего, является следствием неудачного стечения обстоятельств и недостатка коммуникации между разработчиками.
Все предположения, сделанные автором статьи, являются исключительно его собственными домыслами, не нашедшими подтверждения в действительности.
Тогда запрашивайте у производителей описание APDU работы с токеном. Нам они передаются обычно под NDA.
> Холмс, но как черт-возьми? Если вы сами даёте в руки этим варварам возможность отключать работу с неизвлекаемым режимом.
Неочевидная аналогия. Сейчас весь мир для платежей использует чиповые EMV-карты, которые устанавливают SecureMessaging, аутентифицируют с помощью RSA и вообще прекрасны. Их проникновение в большинстве стран выше 90%. Кроме одной — США. Почему так? Ответ простой — США мощно развили систему платежей картами с магнитной полосой. Все понимают, что они менее безопасные, но перейти сходу на EMV невозможно — для этого требуются слишком большие затраты. Процесс перехода осторожно движется, но пока далек от завершения.
У нас ровно тоже самое. Криптопровайдер, который хранит ключи в пассивном виде, появился 20 лет назад. Вокруг него построено огромное количество софта. Люди накупили пассивных токенов (других тогда не было!). Взять сейчас и сказать «давайте все переходим на неизвлекаемые ключи и ФКН!» можно, но кто будет-то?
> Выше, по-моему, вы писали, что ФКНы так не объегоришь.
Точно так. ФКН — это мощь. Вот только этих носителей пока единицы. И ошибиться с ними намного сложнее, чем с простыми Рутокен ЭЦП или JaCarta ГОСТ.
Ничего не понял. Команды реализуют токены, мы их зовем согласно документации. Вам станет легче, если я скажу, что команда 0x00, 0x80, 0x00, 0x01 делает первый шаг SESPAKE, а 0x00, 0x80, 0x00, 0x02 — второй? Как вы это верифицируете? Посмотрите на «похожесть» структур? А с чего вы будете уверены, что токен и провайдер установили именно тот ключ, что указан в протоколе, а не просто константу?
> То есть вы находите, что защита идиотов важнее самой концепции «закрытый ключ знает только владелец»? )))
Я живу в реальном мире, где нашим ПО пользуются в большинстве своем люди, которые не отличают закрытый ключ от открытого и на полном серьезе «подписывают сертификатами». Они относятся к переданному токену и криптопровайдеру не как к серьезному средству защиты, а как к формальности, навязанной «сверху». Для них, по моему мнению, важно максимально упростить переход на новые версии продукта по-максимуму обеспечивая совместимость.
Если же служба безопасности компании или сам пользователь понимают, чего они хотят и к чему это приведет в итоге, пусть выбирают неизвлекаемые режимы.
Повторюсь, вы напрасно считаете, что наличие закрытого ключа в памяти токена спасет от какого-то серьезного взлома. Утром вредонос перехватывает APDU для аутентификации на Рутокене и узнает пароль, вечером предъявляет его и подписывает документ. Это явно лучше обычного пассивного контейнера, т.к. нарушитель должен быть «активным», но я с трудом себе представляю адекватность подобного разделения возможностей в какой-либо худо-бедно близкой к реальности модели.
2) SESPAKE — криптографический протокол, который прошел достаточные исследования и имеет доказанную стойкость (см., например, статью на Хабре). Аудит проводят сертифицирующие органы. В целом про исходники странный вопрос — у нас не open-source проект. Открытие реализации даже какой-то части (например, реализации SESPAKE) никак не позволит убедиться в том, что она вообще используется.
3) При большом количестве пользователей даже мера «не давать ошибиться в окне» не помогает.
4) Да, про архивацию полностью согласен. Одно дело, сохранять ключ, когда тебя просят (или когда ты делаешь это всегда, а пользователь в курсе), другое — кидать его втихую по почте.
Добрый день.
У автора, как и написано в заголовке, 100% оценочное суждение и небольшой недостаток информации. Будучи человеком, отвечающим в КриптоПро за работу с токенами, выскажу своё мнение. Думаю, оно не будет сильно отличаться от официального.
1) КриптоПро уже больше 10 лет выпускает провайдеры, работающие с неизвлекаемыми ключами. Они называются ФКН (Рутокен CSP, Jacarta CSP, Magistra CSP и т.д.). Если пользователей волновало именно использование неизвлекаемых ключей, они покупали ФКН. В CSP 5.0 просто объединили ФКН-провайдеры и "базовый".
2) Слухи о безопасности "обычных" неизвлекаемых ключей сильно преувеличены. Может, токен и не даёт ключу утечь, но без защищенного канала вредонос может послать пару команд и подписать на токене сам что-угодно, тк в большинстве случаев пароль предъявляется в "голом" виде и может быть заснифферен проще ключей. Хотите безопасности — используйте токены с защищённом каналом.
3) Не думаю, что у Тензора была какая-то злая воля (хотя, конечно, бесит, что до сих пор нам даже сроков исправления не назвали). Скорее, логика такая: людей с CSP 4.0 (там нет неизвлекаемых ключей) намного больше, поэтому пока, чтобы не получилось ситуации, в которой человек не может пользоваться ключом в старом провайдере, сделаем плавный переход, запретив работу с неизвлекаемыми ключами. О том, что это может мешать, никто не подумал. Собственно, я добавил функциональность, которой они так "злобно" пользуются, по просьбе других клиентов ровно для решения данной задачи.
4) Вообще говоря, возможность архивирования ключей — штатная вещь в интерфейсе криптографии CryptoAPI. Да, нельзя это делать без ведома пользователя, но учитывая низкую надёжность токенов (уж просто поверьте, постоянно отвечаем людям с такими проблемами) при должной защите это может быть неплохо. Например, почему бы не иметь шифрованный архив ключей корпоративного УЦ?
Я про идейную сторону. Как в принципе должно выглядеть удалённое совершение операций, чтобы ему поверили?
Могу только фантазировать. А чем этот кейс отличается от, например интернет-банка. Как клиент докажет, что транзакцию с переводом выполнил он, а не админ банка? Кажется, что журналов сервера должно быть достаточно, если есть механизм проверки их подлинности.
Не знаю насчёт конкретно описанной системы, но используемый автором DSS позволяет, во-первых, дополнительно шифровать ключи на ПИНе пользователя, а во-вторых не просто высылать одноразовые коды, а отправлять на телефон непосредственно подписываемые данные. Так что можно быть уверенным, что ни выполнить операцию ни подменить её без участия пользователя нельзя.
В КриптоПро CSP 5.0 появилась одновременная работа как с пассивными, так и с активными токенами.
www.ruscrypto.ru/resource/archive/rc2018/files/07_Agafyin_Borodin.pdf