Token consumed что это в реестре

Извлечение ключа из токена с неизвлекаемым ключом

Довольно часто при оформлении сертификатов ключей электронной подписи можно наблюдать навязчивый пиар токенов с неизвлекаемым ключом. Продавцы из удостоверяющих центров уверяют, что, купив у них СКЗИ КриптоПРО CSP и токен с неизвлекаемым ключом (Рутокен ЭЦП или JaCarta ГОСТ), мы получим сертифицированные СКЗИ, обеспечивающие 100%-ную защиту от кражи ключей с токена. Но так ли это на самом деле? Для ответа на этот вопрос проведем простой эксперимент…

Конфигурация тестового стенда

1. ОС MS Windows 7 SP1
2. СКЗИ КриптоПРО CSP 3.9.8423
3. Драйверы Рутокен для Windows (x86 и x64). Версия: v.4.1.0.0 от 20.06.2016, WHQL-certified
4. Единый Клиент JaCarta и JaCarta SecurLogon. Версия 2.9.0 сборка 1531
5. КриптоАРМ Стандарт Плюс 5. Версия 5.2.0.8847.

1. Рутокен ЭЦП. Версия 19.02.14.00 (02)
2. JaCarta ГОСТ. Номер модели JC001-2.F09 v2.1

Методика тестирования

1. генерируется контейнер закрытого ключа и запрос на сертификат открытого ключа;
2. после прохождения в удостоверяющем центре процедуры сертификации из запроса получается сертификат;
3. сертификат в совокупности с контейнером закрытого ключа образует готовую для использования ключевую информацию. Данную ключевую информацию, записанную на носителе, будем называть исходным ключевым документом;
4. с исходного ключевого документа изготавливаются копии, которые записываются на отчуждаемые носители (далее будем называть их рабочими ключевыми документами) и передаются уполномоченным пользователям;
5. после изготовления необходимого количества рабочих ключевых документовисходный ключевой документ уничтожается или депонируется на хранение в орган криптографической защиты информации.

Проведение тестирования

1. Создадим исходный ключевой документ.
Описание

Для этого с помощью КриптоАРМ создадим в реестре контейнер закрытого ключа test-key-reestr, содержащий самоподписанный сертификат (CN=test)

2.Сформируем рабочие ключевые документы.
Описание

С помощью штатных средств СКЗИ КриптоПРО CSP (Пуск—>Панель управления—>КриптоПро CSP) скопируем ключевой контейнер test-key-reestr на ключевые носители Рутокен ЭЦП и JaCarta ГОСТ. Ключевым контейнерам на ключевых носителях присвоим имена test-key-rutoken и test-key-jacarta соответственно.
Описание приведено применительно к JaCarta ГОСТ (для Рутокен ЭЦП действия аналогичны):





Таким образом получили рабочие ключевые документы на JaCarta ГОСТ (контейнер test-key-jacarta) и Рутокен ЭЦП (контейнер test-key-rutoken).

3.Уничтожим исходный ключевой документ
Описание
Штатными средствами СКЗИ КриптоПРО CSP удалим из реестра ключевой контейнер test-key-reestr.

4. Скопируем ключевую информацию из рабочих ключевых документов
Описание

Попробуем скопировать ключевые контейнеры test-key-rutoken и test-key-jacarta обратно в реестр.
Описание приведено для JaCarta ГОСТ (для Рутокен ЭЦП действия аналогичны).

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

Матчасть

То, что на рынке принято называть токеном с неизвлекаемым ключом, правильно называется функциональным ключевым носителем (ФКН) (доп. инфо).

Главным отличием ФКН от обычных токенов (Рутокен S, JaCarta PKI, …) в том, что при выполнении криптографических преобразований (например, формирование электронной подписи) закрытый ключ не покидает устройство. В то время как при использовании обычных токенов закрытый ключ копируется с токена в память комптьютера.

Использование ФКН требует особой организации взаимодействия между прикладным криптографическим ПО и библиотекой СКЗИ (криптопровайдером или, по-другому, CSP).

Здесь важно увидеть, что программная часть библиотеки СКЗИ должна знать о существовании на токене апплета, реализующего криптографический функционал (например, генерация ключа, подпись данных и т.д.) и уметь с ним работать.

По-новому взглянем на наш тестовый стенд

В качестве одного из ключевых носителей использовался Рутокен ЭЦП. Через «Панель управления Рутокен» о нем можно получить следующую информацию:

В последней строке указана фраза «Поддержка КриптоПРО ФКН: Нет», а это значит, что на токене нет апплета, с которым умеет работать СКЗИ КриптоПРО CSP. Таким образом, реализация технологии ФКН с использованием СКЗИ и токенов, описанных в конфигурации тестового стенда, невозможна.

Аналогичная ситуация и с JaCarta ГОСТ. Более того, СКЗИ КриптоПРО CSP, по крайней мере та версия, которая использовалась в тестовом стенде, использует данные ключевые носители как «обычные токены», которые, в свою очередь, являются просто носителями ключа.

Это утверждение очень просто подтвердить. Для этого надо поставить СКЗИ КриптоПРО CSP на чистую машину без драйверов от токенов и подключить токен JaCarta ГОСТ. ОС Windows 7 обнаружит токен JaCarta ГОСТ как «Устройство чтения смарт-карт Microsoft Usbccid (WUDF)». теперь можно попробовать создать ключ на токене и скопировать его в реестр компьютера. Весь функционал СКЗИ успешно отработает.

Как сделать, чтобы все было хорошо?

Чтобы с помощью продуктов ООО “КРИПТО-ПРО” реализовать технологию ФКН, необходимо:

1. Купить специальную версию библиотеки СКЗИ:
— для Рутокен ЭЦП — СКЗИ КриптоПРО Рутокен CSP.
— для JaCarta ГОСТ – СКЗИ КриптоПро ФКН CSP.

2. Одновременно с библиотекой СКЗИ необходимо приобрести специально подготовленные токены, содержащие в себе программные части (апплеты), с которыми умеет работать КриптоПРО Рутокен CSP или КриптоПро ФКН CSP соответственно.

Получается, что Рутокен ЭЦП и JaCarta ГОСТ не являются токенами с неизвлекаемым ключом?

Опять нет. Данные устройства могут реализовывать функционал ФКН (но, возможно, в меньшем объеме, чем при использовании их совместно с СКЗИ КриптоПРО), но для этого нужен софт, который умеет работать с апплетами размещенными на токенах. Таким софтом может быть КриптоАРМ Стандарт 5 Плюс. Он это умеет. При генерации ключевой пары в мастере КриптоАРМ можно выбрать криптопровайдер, который будет использоваться, например, Rutoken ECP или eToken GOST. Это и позволит использовать токен как ФКН.

Выводы

• Не верьте продавцам, чушь вам городящим. Использование обычных версий криптопровайдера КриптоПРО CSP и обычных Рутокен ЭЦП или JaCarta ГОСт не позволяют реализовать технологию ФКН.
• Для использования технологии ФКН совместно с продуктами ООО «КРИПТО-ПРО» необходимы как специально подготовленные токены, содержащие апплет, с которым умеет работать СКЗИ, так и специальные версии криптопровайдера КриптоПРО CSP, которые умеют работать с апплетом на токенах.
• Рутокен ЭЦП и JaCarta ГОСТ умеет самостоятельно реализовывать технологию ФКН, но для этого необходим специальный софт.

Контейнер, токен для сертификатов и ключей openssh

В очередной раз разобрался с токенами и возможностями их использования для обеспечения безопасности ssh и опять приуныл.

Беда с токенами в том, что они заточены только под работу с x509 сертификатами и ключами rsa, да еще и с 1024 и иногда 2048.

А хотелось бы использовать ключи rsa 4k, ekdsa или ed25519 и сертификаты openssh, а не x509.

Видел кто нибудь токены, работающие с сертификатами openssh? Или софтовые реализации наподобие контейнеров криптопро?

Пока что ничего лучше файлика с контейнером luks не придумал. А хотелось бы, чтобы наподобие pks11 библиотека в ssh-add цепляла ключи и сертификаты openssh из своего контейнера или токена и вперед…

AVL ★
13.01.22 14:54:07 MSK

Или софтовые реализации наподобие контейнеров криптопро?

«Софтовая реализация» это когда ты файл ключа с passphrase сгенерил. Ничего другого от софтовых реализаций в принципе не получишь, разница только в украшательствах.

firkax ★★★★★
( 13.01.22 15:32:15 MSK )
Ответ на: комментарий от firkax 13.01.22 15:32:15 MSK

Нет, софтовая реализация, это когда у тебя есть контейнер, в котором лежит ключ и сертификат openssh. Контейнер защищен парольной фразой. Сам контейнер может располагаться в файле или на токене (тот же файл, по сути, просто в токене).

Доступ ssh к сертификату и ключу осуществляет библиотека через ssh-agent.

По сравнению с ~/.ssh/* , во первых, нет нужды отдельно таскать с собой все эти файлы, достаточно иметь один файл-контейнер, да еще в токене, вместе с другими x509 сертификатами. Во вторых, нет нужды держать файлы ключа и сертификата на компьютере. Воткнул токен — есть контейнер. Вытащил — нет.

AVL ★
( 13.01.22 15:40:25 MSK ) автор топика
Ответ на: комментарий от AVL 13.01.22 15:40:25 MSK

А, ну я это всё и обобщил как украшательства — удобства/неудобства доставки файла в нужное место, но почти никакой связи с безопасностью. Никакой защиты от кражи ключа через скомпрометированный комп.

Существенная же разница по-моему может быть только одна — когда токен хранит ключ внутри себя, делает с его помощью нужные вычисления и даёт результаты, но сам ключ наружу вообще не выпускает ни при каких обстоятельствах.

firkax ★★★★★
( 13.01.22 15:48:59 MSK )
Последнее исправление: firkax 13.01.22 15:50:31 MSK (всего исправлений: 1)

Ответ на: комментарий от firkax 13.01.22 15:48:59 MSK

В большинстве случаев компьютер во время работы никто и не компрометирует во время работы. Просто если ключи все время лежат в директории ~./ssh, рано или поздно их можно скопировать или забыть где-то вместе с компьютером.

Хотелось бы иметь токен — воткнул и есть, вытащил и нет. В том же криптопро есть контейнеры, в том числе и некопируемые с токена. И в этих контейнерах внутри полная свобода — гостовые ключи, например, о которых токен даже не догадывается. Так почему бы не сделать нечто подобное для сертификатов и ключей openssh?

AVL ★
( 13.01.22 16:40:40 MSK ) автор топика

Юбикей банальный? Вроде всё умеет, что только можно хотеть.

Legioner ★★★★★
( 13.01.22 17:06:08 MSK )
Ответ на: комментарий от Legioner 13.01.22 17:06:08 MSK

Ну, да. Полтосик денежных знаков страны двух падающих небоскрёбов и дело в шляпе. Немного непонятно: а почему нужен именно токен? Не, ну когда дело на устройстве налажено, то — это хорошо. Присунул и наши в дамках. Но тут же речь немножко о другом. Тут речь о том, что «комп. может быть утрачен». Результат — снова геморрой и мучительное напряжение очень дальних уголков памяти в лейтмотиве «когда-то я это делал, но разрази меня гром не помню как». Ключи-то есть, на утраченном девайсе «враг не пройдёт», но и самому проблем и занятий поднасыпало. Да ещё если для примастыривания этого эксклюзивного токена надо использовать не менее эксклюзивные подходцы. Так и всё же, откройте тайну: чем тот же, упомянутый выше контейнер luks на обыкновенной флешке хуже? Уж тут-то и вспоминать ничего не надо даже при полной амнезии. В гугел глянул как с тем luks-ом обращаться и за пяток минут вспомнил.

anonymous
( 13.01.22 17:19:43 MSK )
Ответ на: комментарий от AVL 13.01.22 16:40:40 MSK

В большинстве случаев компьютер во время работы никто и не компрометирует во время работы. Просто если ключи все время лежат в директории ~./ssh, рано или поздно их можно скопировать или забыть где-то вместе с компьютером.

Хорошо, это чуточку повышает защиту от разных неосторожностей, каждый сам решает насколько это ему существенно.

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

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

firkax ★★★★★
( 13.01.22 17:22:22 MSK )
Ответ на: комментарий от anonymous 13.01.22 17:19:43 MSK

Ну, да. Полтосик денежных знаков страны двух падающих небоскрёбов и дело в шляпе.

Ну токен дело такое, лучше взять качественное оборудование. Тем более, что не каждый день берёшь.

Кстати не полтосик, а два полтосика по-хорошему. А то и три. Запасные в сейфе на случай порчи/потери используемого.

Немного непонятно: а почему нужен именно токен?

Чтобы не пришлось спешно отзывать и менять все ключи, если появилось подозрение на то, что на твоём компе побывал троян. И вообще

Да ещё если для примастыривания этого эксклюзивного токена надо использовать не менее эксклюзивные подходцы.

Да вроде никаких подходцев не надо, всё стандартными средствами настраивается.

Так и всё же, откройте тайну: чем тот же, упомянутый выше контейнер luks на обыкновенной флешке хуже? Уж тут-то и вспоминать ничего не надо даже при полной амнезии. В гугел глянул как с тем luks-ом обращаться и за пяток минут вспомнил.

Главное отличие в том, что вирус, хозяйствующий на твоём компьютере, может вытащить любые твои файлы и любые пароли, которые ты нажимаешь на своей клавиатуре. А с криптотокена он ничего вытащить не может. В худшем случае он может подписать что-нибудь, пока крипто-токен вставлен и если крипто-токен не требует физичекого нажатия кнопки для каждой подписи. Но ключ твой в любом случае не утечёт и отзывать его не нужно будет.

Ну и ещё отличие так сказать управленческое. Если ты это делаешь не для себя, а для сотрудников. В юбикее ты можешь быть уверен. А в том, что сотрудник будет грамотно пользоваться всеми этими люксами, а не поставит туда пароль 123 и вообще не скопирует ключ для удобства куда-нибудь поближе, уверенным быть сложней.

Legioner ★★★★★
( 13.01.22 17:43:50 MSK )
Последнее исправление: Legioner 13.01.22 17:45:08 MSK (всего исправлений: 1)

Ну во первых нет сертификатов openssh, насчёт токенов всё что на openpgp умеет чисто в ключи rsa и пр и дружит с OpenSSH через gpg из коробки

sparks ★★★
( 13.01.22 17:47:54 MSK )
Ответ на: комментарий от Legioner 13.01.22 17:06:08 MSK

Юбикей банальный? Вроде всё умеет, что только можно хотеть.

Ну во первых, не банальный, а полноценный. Есть такой, протестировал.

А во вторых, ничего он не умеет, кроме как хранить rsa ключи до 2048 бит.

Сертификаты openssh? нет known-host? нет

ключи ecdsa или ed25519? нет

AVL ★
( 13.01.22 19:27:02 MSK ) автор топика
Ответ на: комментарий от anonymous 13.01.22 17:19:43 MSK

Немного непонятно: а почему нужен именно токен?

1. защита от копирования ключа (контейнера). Токен/флешку ведь тоже можно потерять. Мне очень нравится система трижды пин-код введен неверно — прощай контейнер.
2. нет нужды в монтировании/отмонтировании девайса. Вставил и пользуйся. Вытащил токен в любой момент и доступ пропал.

Тут речь о том, что «комп. может быть утрачен».

Да, но это рабочий комп(ы).

Ключи-то есть, на утраченном девайсе «враг не пройдёт», но и самому проблем и занятий поднасыпало.

никаких проблем. pki есть, просто выписал новый сертификат и записал в новый токен.

От забывчивости спасает скриптование операций. Я просто вызываю скрипт с логином и он сам мне все делает. Забыл, ну посмотри в скрипт.

Так и всё же, откройте тайну: чем тот же, упомянутый выше контейнер luks на обыкновенной флешке хуже?

1. Плохо защищает от копирования во время работы.
2. Требует рута.

Частично я это решил, создав банальный зашифрованный зип и скриптик, который его через archivemount монтирует, добавляет в ssh-agent и сразу отмонтирует. Теперь не нужно рута и в рабочем режиме ключи недоступны. Но раздражает кривизна archivemount (не работает с p7zip зашифрованными архивами, не отрабатывает неправильный пароль).

В гугел глянул как с тем luks-ом обращаться и за пяток минут вспомнил.

лукс хорош, но именно в этой задачи он не совсем удобен.

AVL ★
( 13.01.22 19:38:19 MSK ) автор топика
Ответ на: комментарий от firkax 13.01.22 17:22:22 MSK

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

Криптопро работает со своим контейнером. Ему что токен, что реестр, что файл.

Есть програмный контейнер, его всегда можно програмно скопировать, эта возможность тут принципиально не может быть ограничена.

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

AVL ★
( 13.01.22 19:42:22 MSK ) автор топика
Ответ на: комментарий от Legioner 13.01.22 17:43:50 MSK

Ну и ещё отличие так сказать управленческое. Если ты это делаешь не для себя, а для сотрудников. В юбикее ты можешь быть уверен. А в том, что сотрудник будет грамотно пользоваться всеми этими люксами, а не поставит туда пароль 123 и вообще не скопирует ключ для удобства куда-нибудь поближе, уверенным быть сложней.

AVL ★
( 13.01.22 19:44:04 MSK ) автор топика
Ответ на: комментарий от AVL 13.01.22 19:27:02 MSK

Тебе надо использовать OpenPGP интерфейс.

Legioner ★★★★★
( 13.01.22 19:47:28 MSK )
Ответ на: комментарий от sparks 13.01.22 17:47:54 MSK

Ну во первых нет сертификатов openssh

man sshd_config HostCertificate Specifies a file containing a public host certificate. The cer‐ tificate's public key must match a private host key already spec‐ ified by HostKey. The default behaviour of sshd(8) is not to load any certificates. man ssh-keygen CERTIFICATES ssh-keygen supports signing of keys to produce certificates that may be used for user or host authentication. Certificates consist of a public key, some identity information, zero or more principal (user or host) names and a set of options that are signed by a Certification Authority (CA) key. Clients or servers may then trust only the CA key and verify its signature on a certificate rather than trusting many user/host keys. Note that OpenSSH certificates are a different, and much simpler, format to the X.509 certificates used in ssl(8). ssh-keygen supports two types of certificates: user and host. User certificates authenticate users to servers, whereas host certificates authenticate server hosts to users. To generate a user certificate: 

AVL ★
( 13.01.22 19:48:16 MSK ) автор топика
Ответ на: комментарий от Legioner 13.01.22 19:47:28 MSK

Тебе надо использовать OpenPGP интерфейс.

AVL ★
( 13.01.22 19:49:06 MSK ) автор топика
Ответ на: комментарий от AVL 13.01.22 19:49:06 MSK
Legioner ★★★★★
( 13.01.22 19:50:31 MSK )
Ответ на: комментарий от Legioner 13.01.22 19:50:31 MSK

Там только rsa ключи. Да, до 4k, но, например, в федоре вообще их отключили из хостов.

А еще есть сертификаты openssh иони там свои, не X509. Их использование позволяет настроить доступ целиком в системе, без троганий ~/.ssh плю можно вдавать урезанные по правам сертификаты.

ed25519 таки есть. Я просто настраивал PIV и там их нет.

ed25519 (sign / auth only)

AVL ★
( 13.01.22 20:07:26 MSK ) автор топика
Последнее исправление: AVL 13.01.22 20:09:34 MSK (всего исправлений: 2)

Ответ на: комментарий от AVL 13.01.22 19:42:22 MSK

У меня совершенно нет желания ставить себе всё это и реверсить как оно работает. Но комп это не магическое устройство, поэтому апеллции к чудесным программам я отклоняю. Если контейнер представлен чем-то, записанным на обычный компьютерный диск или флешку — то воспрепятствовать его копированию программой, запущеной на том же компе и имеющей доступ к этому носителю информации — принципиально невозможно. Максимум, что они могли сделать — это запутать способ хранения контейнера (security through obscurity), но это не настоящее препятствие, а только преграда от ленивых, которым будет влом изучать как оно там устроено.

Мне вот в налоговой ЭЦП так сделали,

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

firkax ★★★★★
( 13.01.22 20:38:10 MSK )
Последнее исправление: firkax 13.01.22 20:40:44 MSK (всего исправлений: 2)

Ответ на: комментарий от firkax 13.01.22 20:38:10 MSK

Если контейнер представлен чем-то, записанным на обычный компьютерный диск или флешку

контейнер записан в токен с установленным битом неизвлекаемости.

Возможно тебе таки выдали аппаратный токен

я его сам принес, рутокен ecp. но внутри токена теперь контейнер криптопро.

AVL ★
( 13.01.22 20:47:28 MSK ) автор топика
Ответ на: комментарий от AVL 13.01.22 20:47:28 MSK

контейнер записан в токен с установленным битом неизвлекаемости

Это называется запретом на экспорт. КриптоПРО позволяет перемещать сертификаты или запрещает их перемещать. Но только средствами самой КриптоПРО — запрет на экспорт распространяется только на программное обеспечение от КриптоПРО. Это совершенно не значит, что экспорт содержимого не может быть осуществлён. Сродни связки ключей. Они есть, но при переносе на другое устройство в исходном состоянии они по идее будут непригодными. В этом случае, когда «хозяйский софтец» не может помочь, сертификаты извлекаются в рабочем процессе. Об этом вам и рассказывают. Словосочетание «бит неизвлекаемости» — это «быстрый уровень вхождения в проблему», как бубунта после виндовсы.

anonymous
( 13.01.22 22:07:16 MSK )
Ответ на: комментарий от Legioner 13.01.22 17:43:50 MSK

Ну и ещё отличие так сказать управленческое. Если ты это делаешь не для себя, а для сотрудников. В юбикее ты можешь быть уверен. А в том, что сотрудник будет грамотно пользоваться всеми этими люксами, а не поставит туда пароль 123 и вообще не скопирует ключ для удобства куда-нибудь поближе, уверенным быть сложней.

Не очень-то понятно со стороны реализатора этого всего мероприятия. Со стороны не управленца, а того, кто всё это будет делать. Вот у вас получается, что конечный пользователь и сам себе контейнеры создаёт, и пароли на них назначает. А ключики для ssh этот пользователь тоже сам себе генерирует? Или вот возьмём, например, токен. И возьмём какой-нибудь дистрибутив. Debian-а или его производных, или там что-то из RedHat и тоже его производных. Установим на подходящее железо и радостно всунем этот токен в подходящий порт. И вот с этого токена вдруг и неожиданно сертификаты взяли и обслужили некую попытку соединения. Вы какой дистрибутив порекомендуете взять, чтоб его без всякого допиляжа и присовывания всевозможных дров можно было бы использовать для всевозможных токенов? Ну, например, для rutoken lite дров добавлять не надо. Ан, всё равно при присовывании этого токена сертификаты всё равно придётся чем-то читать и как-то и кому-то всё это дело настраивать. Пользователю? Ну, если пользователь сам себе luks-овые контейнеры мастырит, то ему и с токенов инфу почитать — это как два пальца об асфальт. вы не могли бы объяснить от кого вы собственно секретутности усиливаете? Я этого момента не понял.

anonymous
( 13.01.22 22:24:39 MSK )
Ответ на: комментарий от anonymous 13.01.22 22:24:39 MSK

Не знаю, что там с rutoken lite, но вообще для токенов есть стандартные интерфейсы и протоколы и ничего там пилить не надо, обычный ssh и gpg поддерживают. Российские криптотокены вероятно нужны для русской посконной гостовской криптографии, с ней, конечно, будут проблемы, но то такое.

Legioner ★★★★★
( 13.01.22 23:00:54 MSK )
Ответ на: комментарий от Legioner 13.01.22 23:00:54 MSK

для токенов есть стандартные интерфейсы и протоколы и ничего там пилить не надо

А вы не могли бы в конкретных числах озвучить количество этих самых «стандартных» интерфейсов для токенов?

anonymous
( 14.01.22 01:09:06 MSK )
Ответ на: комментарий от anonymous 14.01.22 01:09:06 MSK

Я не Legioner, но подскажу.

Есть библиотека с интерфейсом pkcs11 , которую используют ssh, gpg, браузеры и т.д. В рутокен лайт она тоже есть, но рутокен лайт не поддерживает rsa, а только госты, так что в большинстве случаев мимо. Рутокен эцп держит и Rsa и гост, что выглядит предпочтительней.

И еще есть java интерфейс. Он обычно используется в банках, но они в последнее время тоже перешли на криптопро.

AVL ★
( 14.01.22 11:39:18 MSK ) автор топика
Ответ на: комментарий от anonymous 13.01.22 22:24:39 MSK

Не очень-то понятно со стороны реализатора этого всего мероприятия. Со стороны не управленца, а того, кто всё это будет делать.

Да как обычно реализуется pki. Есть сотрудник, который выписывает сертификаты и ключи. Иногда ключ на токене создает пользователь. В случае с ssh это плохая идея. В ssh весь процесс создания ключа и сертификата должен по идее проходить в отделе безопасности. Пользователю просто выдают токен.

Вот у вас получается, что конечный пользователь и сам себе контейнеры создаёт, и пароли на них назначает.

Не создает, а копирует, если может. Мне вот в тендерной площадке создали контейнер криптопро на токене, а я взял и скопировал его в реестр и вертел ваш токен…

А ключики для ssh этот пользователь тоже сам себе генерирует?

Нет. Пользователь получает или приносит токен, на котором генерируется ключ и сертификат.

Или вот возьмём, например, токен. И возьмём какой-нибудь дистрибутив. Debian-а или его производных, или там что-то из RedHat и тоже его производных. Установим на подходящее железо и радостно всунем этот токен в подходящий порт. И вот с этого токена вдруг и неожиданно сертификаты взяли и обслужили некую попытку соединения.

А пинкод на токен они тоже сами ввели?

Вы какой дистрибутив порекомендуете взять, чтоб его без всякого допиляжа и присовывания всевозможных дров можно было бы использовать для всевозможных токенов? Ну, например, для rutoken lite дров добавлять не надо. Ан, всё равно при присовывании этого токена сертификаты всё равно придётся чем-то читать и как-то и кому-то всё это дело настраивать. Пользователю? Настраивает служба техподдержки, как обычно. Драйверы на большинство токенов уже есть в дистре. Библиотека pks11 на рутокен или другие токены, это просто один файл, который бросают в /usr/lib64

Все остальное есть в дистрибутиве.

Ну, если пользователь сам себе luks-овые контейнеры мастырит, то ему и с токенов инфу почитать — это как два пальца об асфальт. вы не могли бы объяснить от кого вы собственно секретутности усиливаете? Я этого момента не понял.

Секурность заключается в том, что нет средств извлечь/скопировать ключ с токена. Поэтому если я пришел и ушел с токеном, то значит и ключ со мной ушел. Уволился, сдал токен — ну значит и подпись отдал.

А с луксом это просто файлы, которые во время работы никак не защищены.

AVL ★
( 14.01.22 11:50:28 MSK ) автор топика
Ответ на: комментарий от anonymous 13.01.22 22:07:16 MSK

Это называется запретом на экспорт. КриптоПРО позволяет перемещать сертификаты или запрещает их перемещать. Но только средствами самой КриптоПРО — запрет на экспорт распространяется только на программное обеспечение от КриптоПРО. Это совершенно не значит, что экспорт содержимого не может быть осуществлён. Сродни связки ключей. Они есть, но при переносе на другое устройство в исходном состоянии они по идее будут непригодными. В этом случае, когда «хозяйский софтец» не может помочь, сертификаты извлекаются в рабочем процессе. Об этом вам и рассказывают. Словосочетание «бит неизвлекаемости» — это «быстрый уровень вхождения в проблему», как бубунта после виндовсы.

Это все замечательно, но это лучше, чем ничего. В принципе и токен, это тоже по сути эфемерный «бит неизвлекаемости». Кто мешает попилить чип и прочитать его послойно? А можно взломать прошивку. Хрен знает, сколько там дыр. Да и сами алгоритмы взламывают со временем. Но в настоящий момент нет (широко)известных способов скопировать контейнер криптопро, как нет (широко)известных способов вытащить ключи из токена. Поэтому, это лучше, чем лукс-контейнер, который можно скопировать командой dd. Вот что я хотел сказать.

AVL ★
( 14.01.22 11:55:32 MSK ) автор топика
Ответ на: комментарий от AVL 13.01.22 19:48:16 MSK

действительно, прикольно, я всегда в контексте certificate подставлял x509. openpgp работает через gpg, там нет x509 оно эмулируется через opensc

Руководства

Руководство пользователя для ESMART PKI Client, который предназначен для работы со смарт-картами или USB- ключами ESMART Token и ESMART Token ГОСТ. Программа позволяет выполнить все необходимые операции со смарт-картами или USB-ключами в удобном графическом интерфейсе
СКАЧАТЬ

ESMART PKI Client — Руководство администратора

Руководство администратора для ESMART PKI Client, который предназначен для работы со смарт-картами или USB- ключами ESMART Token и ESMART Token ГОСТ. Программа позволяет выполнить все необходимые операции со смарт-картами или USB-ключами в удобном графическом интерфейсе
СКАЧАТЬ

Общие вопросы
Я купил новый USB-токен или смарт-карту ESMART Token и не знаю PIN-код

По умолчанию на устройствах ESMART Token заданы следующие значения:
— PIN-код пользователя — 12345678
— SO-PIN (PIN-код администратора) — 12345678

Я забыл PIN-код

При наличии SO-PIN (PIN-кода администратора) Вы можете разблокировать PIN-код пользователя при помощи программного обеспечения ESMART PKI Client.
Если утерян SO-PIN (PIN-код администратора), но имеется PIN-код пользователя, Вы можете продолжить использование ESMART Token как пользователь (удаление, запись, просмотр).
При утере SO-PIN и PIN-кода пользователя, использование или возврат к заводским настройкам невозможны!

На токене/смарт-карте имеются контейнеры, созданные при помощи СКЗИ «КриптоПРО CSP», они отображаются в ESMART PKI Client, но я ничего не могу подписать

СКЗИ «КриптоПРО CSP» использует для хранения информации на токенах и смарт-картах отдельные области и работает с ними через собственные библиотеки. В последних версиях ESMART PKI Client реализована возможность отображения контейнеров, созданных при помощи СКЗИ «КриптоПРО CSP» (в имени таких контейнеров стоит отметка [CRYPTO-PRO]), однако эта функция имеет лишь информационный характер. Произвести какие-либо операции с такими контейнерами с помощью ESMART PKI Client или приложений, работающих через PKCS#11, не представляется возможным.

Решения для Windows
Записанный в УЦ ФНС России контейнер с сертификатом не отображается в КриптоПро CSP

Данная особенность связана с переводом поддержки носителей с неизвлекаемыми ключами ESMART Token ГОСТ с интерфейса READER на PKCS#11. Для регистрации поддержки PKCS#11 необходимо переподключить модуль PKCS#11:
Панель управления — КриптоПро CSP — Запустить с правами администратора — Оборудование — Настроить считыватели — Считыватель смарт-карт PKCS#11 — Удалить — Добавить — Считыватель смарт-карт PKCS#11.
Рекомендуем отмечать галочками только те носители, которые Вы действительно планируете использовать на данной рабочей станции, иначе в системном журнале будут множество ошибок загрузки библиотек.
Краткая видеоинструкция по добавлению считывателя в КриптоПро CSP 5.0.
Более подробная инструкция приведена на сайте компании КриптоПро

При попытке записать контейнер КриптоПро на ESMART Token 64K в КриптПро CSP возникает ошибка: «Ошибка 0х80090023: Токен безопасности не имеет доступного места для хранения дополнительного контейнера.»

Данная ошибка может возникнуть при записи на токен контейнера, содержащего цепочку из трёх и более сертификатов. Сначала убедитесь, что на токене отсутствуют контейнеры КриптоПро, при необходимости инициализируйте токен. Запустите от имени Администратора (обязательно!) КриптоПро CSP. Во вкладке «Оборудование» нажмите «Настроить типы носителей. «, найдите в списке «ESMART Token 64K». Нажмите «Свойства» и перейдите во вкладку «Свойства». Установите параметр «Максимальное число контейнеров» — 4. Данная настройка уменьшит максимальное количество контейнеров, хранимых на токене, но пропорционально увеличит их возможный размер.

При установке ESMART PKI Client возникает ошибка 26352

Для решения проблемы запустите оснастку «Сертификаты пользователя» (certmgr). Перейдите в «Доверенные издатели» -> «Сертификаты». Удалите все сертификаты «ISBC Ltd». Запустите setup.x64.exe (либо setup.exe в зависимости от вашей системы) от имени администратора. Программа установки автоматически добавит корректные сертификаты.

При запуске ESMART PKI Client появляется сообщение «The requested security protocol is not supported»

Данная ошибка может проявиться на ОС Windows Vista SP2 и Windows Server 2008 SP2. Для решения проблемы установите соответствующий патч из статьи на сайте Microsoft

При запуске ПО ESMART PKI Client появляется сообщение: «Ошибка при инициализации PKCS #11. Возможно, в системе не установлены соответствующие библиотеки». ESMART PKI Client запускается, но не определяются смарт-карты и ESMART Token

Переустановите ESMART PKI Client, запустив установщик от имени администратора или установите библиотеки вручную.
Также возможно возникновение данной ошибки при установке PKI Client посредством Windows Remote Desktop (RDP). Для установки PKI Client рекомендуем использовать иное ПО для удалённого доступа к компьютеру

На удаленном рабочем столе не отображаются ESMART Token и смарт-карты. КриптоПРО CSP не определяет сертификаты на ESMART Token. В запущенном ESMART PKI Client не отображаются подключенные ESMART Token

Особенность работы со смарт-картами в терминальной сессии заключается в том, что использовать можно только смарт-карты, подключенные к клиентской станции. Смарт-карты, подключенные непосредственно к терминальному серверу в терминальной сессии использовать нельзя. Это ограничение службы терминалов.
ESMART Token, подключенный к удаленной машине при работе через RDP, работать не будет. Необходимо или подключать его к машине, с которой заходит клиент, или воспользоваться иным ПО для удалённого доступа к компьютеру

При подключении ESMART Token в ПО КриптоПро CSP не отображаются установленные на этом ESMART Token сертификаты. При работе с ESMART Token отображается предупреждение: «Некорректный тип носителя или носитель не отформатирован.»

Необходимо зайти в КриптоПро CSP на вкладку «Оборудование» — строка «Типы ключевых носителей», нажать на кнопку «Настроить типы носителей». В ключевых носителях должны быть установлены следующие носители: ESMART Token 64K, ESMART Token GOST (3 шт.). При отсутствии данных об этих ESMART Tokenах работать с КриптоПро CSP будет невозможно.
Поддержка ESMART Token 64K в КриптоПро начинается с версии 3.6 R2, ESMART Token ГОСТ с версии 3.9. Если версия старше, то следует установить «Модуль поддержки КриптоПро CSP для Windows» для ESMART Token 64K и/или ESMART Token GOST. В ином случае следует переустановить КриптоПро CSP. Если переустановка не помогает, то следует установить «Модуль поддержки КриптоПро CSP для Windows»

Не удается записать контейнеры VipNet на ESMART Token при использовании профиля «По умолчанию»
Необходимо установить профиль VipNet, VipNet2 или VipNet3
На компьютерах с ОС Windows XP не удается авторизоваться при помощи смарт-карт

Необходимо установить Microsoft Base Smart Card Cryptographic Service Provider Package (KB909520). А также драйвера для устройств чтения смарт-карт.
Если неработающее устройство это ESMART Token, а не смарт-карта (то есть ридер и смарт-карта в одной сборке), то необходимо установить обновление с драйверами — Microsoft Usbccid (WUDF).
Так как поддержка Windows XP прекращена, необходимое для работы ESMART Token ПО не устанавливается в автоматическом режиме

Kaspersky Free блокирует окна ввода PIN и выбора сертификата
Перевести Kaspersky Free в неактивный режим
При запуске *.exe файла, не находится файл*.msi, хотя оба помещены в одну папку

Убедиться, что архив с файлами распакован и запуск установки осуществляется не из этого архива.
Возможно, потребуется отключение SmartScreen для файлов в панели настроек.

При переключении режима работы Службы смарт-карт (на авто или ручной режим) возникает ошибка: «Невозможно создать файл, т.к. он уже существует»

Необходимо вручную изменить значения в реестре, выполняющие ту же функцию: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SCardSvr для параметра Start поменять с 4 на 2
Примечание:
Automatic (Delayed Start) — 2
Manual — 3
Disabled — 4

При извлечении карты не блокируется АРМ

Необходимо включить политику блокировки при извлечении локально в gpedit.msc (Конфигурация компьютера — Конфигурация Windows — Параметры безопасности — Локальные политики — Параметры безопасности — Интерактивный вход в систему: поведение при извлечении смарт-карты — выставить опцию «Блокировка рабочей станции»). Также необходимо убедиться, что служба «Политика удаления смарт-карт» запущена, тип запуска установлен Автоматический

После установки ПО на Windows XP ESMART Token не определяется клиентом, а также в разделе «Оборудование» отображается как неверно установленный

Установить обновление безопасности KB909520 и, если требуется, стандартный драйвер для считывателей
При перенаправлении ESMART через RDP. Ошибка библиотек PKCS #11
Проблема заключается в одном из обновлений Windows. Решение на сайте Microsoft
При работе через RDP из внешней сети возникает ошибка Kerberos

Особенность заключается в том, что аутентификация по смарт-картам является надстройкой (расширением) аутентификации Kerberos, но никак не заменяет его. Т.е. аутентификация по смарт-карте без Kerberos невозможна. Когда вбивается IP адрес (\\192.168.1.1\share) используется NTLM, а не Kerberos. Описание на сайте Microsoft.
Решение: использовать VPN-соединение.

При попытке обратиться к контейнеру КриптоПро через ACR3901U мигает окно, соединение сбрасывается
Проявляется с прошивкой v.110, необходимо обновить прошивку до v.111

Ошибка: «Данная реализация не является частью протестированных криптографических алгоритмов Windows Platform FIPS»

Необходимо отключить политику «Системная криптография: использовать FIPS совместимые алгоритмы для шифрования, хеширования и подписывания»

Ручная установка драйверов

Скачайте и распакуйте архив.
Для ридера драйвера не требуются — используются стандартные драйвера CCID в составе ОС. Драйвера смарт-карты находятся в директориях ESMART CSP и ESMART GOST CSP для ESMART Token 64K и ESMART Token ГОСТ соответственно, устанавливаются стандартным образом.
Добавление библиотек на x86 системе:
— скопировать библиотеки из SystemFolder в C:\Windows\System32
Добавление библиотек на x64 системе:
— скопировать библиотеки из System64Folder в C:\Windows\System32
— скопировать библиотеки из SystemFolder в C:\Windows\SysWow64
Внесите изменения в реестр.
Для этого скачайте и распакуйте архив. Запустите файлы изменения реестра из архива (с названием remove — для удаления).
Перезагрузите компьютер.

Решения для Linux / MacOS
ESMART PKI Client не запускается

Должна быть установлена среда Mono.
В Linux для запуска программы из командной строки необходимо набрать команду, указав действительный путь к исполняемому файлу:
> sudo mono ESMARTPkiClient.exe
В некоторых ОС, в т.ч. с установленным Mono, PKI Client может не запускаться, или не будут отображаться все графические элементы. Это связано с индивидуальными особенностями ОС Linux и работы в них программ. В таком случае следует сообщать разработчикам

При запуске ПО ESMART PKI Client появляется сообщение: «Ошибка при инициализации PKCS#11. Возможно в системе не установлены соответствующие библиотеки»

Проверить, установлены ли пакеты для работы со смарт-картами (pcsclite, usb-ccid), проверить, запущена ли служба pcscd.
Установить библиотеки. Это можно сделать с помощью .rpm пакета командой:
> rpm -Uvh isbc_pkcs11-****.rpm (или подобной).
Выяснить значение DISPLAY для суперпользователя (> sudo -i) командой:
> echo $DISPLAY
Если значение пусто, то задать его самостоятельно командой:
> export DISPLAY=»*»
Вместо «*» должно быть некое значение, выяснить которое можно у других пользователей системы

При запуске ПО ESMART PKI Client появляется окно с сообщением: «Unable to load library: libisbc_pkcs11_main.so»

Установить/обновить соответствующие пакеты: pcsc-lite, CCID драйвер, ISBC PKCS#11, mono, libgdiplus.
Дополнительно убедиться, что в нужных папках есть символьные ссылки на следующие библиотеки: libdl.so, libgdiplus.so. Как правило, после установки пакетов есть только библиотеки с номером версии, например: /usr/lib64/libgdiplus.so.0, но ссылки /usr/lib64/libgdiplus.so нет. Её необходимо создать командой
> sudo ln -s /usr/lib64/libgdiplus.so.0 /usr/lib64/libgdiplus.so

ПО ESMART PKI Client не запускается. В терминале отображается ошибка с текстом «System.DllNotFoundException: libgdiplus.so»

В папке /usr/lib64 или /usr/lib (в зависимости от разрядности ОС) нет файла libgdiplus.so
Установить пакет libgdiplus необходимой разрядности. Создать символьную ссылку libgdiplus.so в папке /usr/lib64 или /usr/lib (в зависимости от разрядности ОС).
Как правило, после установки пакетов есть только библиотеки с номером версии, например /usr/lib64/libgdiplus.so.0, но ссылки /usr/lib64/libgdiplus.so нет. Её необходимо создать командой
> sudo ln -s /usr/lib64/libgdiplus.so.0 /usr/lib64/libgdiplus.so

На удаленном рабочем столе не отображаются ESMART Token и смарт-карты. КриптоПРО CSP не определяет сертификаты на ESMART Token. В запущенном ESMART PKI Client не отображаются подключенные ESMART Token

Особенность работы со смарт-картами в терминальной сессии заключается в том, что использовать можно только смарт-карты, подключенные к клиентской станции. Смарт-карты, подключенные непосредственно к терминальному серверу в терминальной сессии использовать нельзя. Это ограничение службы терминалов.
ESMART Token, подключенный к удаленной машине при работе через RDP, работать не будет. Необходимо или подключать его к машине, с которой заходит клиент, или воспользоваться другим ПО для подключения к машине (TeamViewer и др.)

Не удается записать контейнеры VipNet на ESMART Token при использовании профиля «По умолчанию»
Необходимо установить профиль для ESMART Token VipNet, VipNet2 или VipNet3
В VirtualBox на MacOS не определяется ESMART Token, возникает ошибка: «Used by someone else»

Привязать ESMART Token в настройках виртуальной машины (если есть запись с этим устройством, удалить её и привязать заново). Извлечь ESMART Token, выключить виртуальную машину, включить заново, подключить ESMART Token

При установке модулей поддержки КриптоПро возникает ошибка: «Error Code: -2146435049»

Ошибка возникает при установке модулей поддержки ESMART Token для КриптоПро в случае, если данные модули не соответствуют установленной версии КриптоПро.
Необходимо установить модули, соответствующие версии КриптоПро.

Если Вам не удалось найти описание и решение Вашей проблемы, Вы можете направить её подробное описание в адрес нашей технической поддержки:
E-mail: help@esmart.ru

Зачем нужен Refresh Token, если есть Access Token?

Недавно мы в Voximplant улучшали авторизацию в SDK. Посмотрев на результаты, я несколько опечалился, что вместо простого и понятного токена их стало две штуки: access token и refresh token. Которые мало того что надо регулярно обновлять, так еще документировать и объяснять в обучающих материалах. Помня, что в OAuth два токена нужны в основном из-за разных сервисов, на которых они используются (даже вопрос на stackoverflow есть), а у нас такой сервис один, я несколько офигел и пошел на второй этаж вытрясать души из разработчиков. Ответ получился неожиданным. Его нет на stackoverflow. Зато он есть под катом.

Зачем вообще нужны токены

При разработке приложений, общающихся с сервером, обычно вылезают следующие этапы:

Приложение разрабатывает один разработчик, нет ни идентификации, ни аутентификации, ни авторизации (кстати, рекомендую замечательную хабрастатью на эту тему от DataArt), запросы напрямую ходят к эндпоинтам сервера, разработчик счастлив.

Зачем нужен первый токен

Есть много разных токенов. Обычные, криптографические, «access key», «session token», разные схемы получения, использования и revoke. При этом одна из ключевых идей заключается в том, что если кто нехороший получит чужой токен, то самое неприятное, что случится — это доступ похитителя к сервису, от которого токен похищен. Пароль, тот самый, который один на все сервисы, похититель не получит. А пользователь, если поймет, что кроме него к сервису получил доступ кто-то другой, может токен отозвать. После чего получить себе новый, имея логин и пароль.

Зачем нужен второй токен

В OAuth 2 и некоторых других схемах авторизации (например, у нас) есть не один, а целых два токена. Первый, access token, используется при запросах к серверу (например, при логине). У него есть два свойства: он многоразовый и короткоживущий. Наш, к примеру, живет 48 часов, а у кого-то 30 минут. Время выбирается на основании того, как используется сервис. Второй, refresh token, используется для обновления пары access и refresh токенов. У него тоже есть два свойства, обратные первому токену: он одноразовый и долгоживущий. Совсем долгоживуший, наш живет месяц.

Схема использования у токенов следующая:

• Пользователь логинится в приложении, передавая логин и пароль на сервер. Они не сохраняются на устройстве, а сервер возвращает два токена и время их жизни
• Приложение сохраняет токены и использует access token для последующих запросов
• Когда время жизни access token подходит к концу (приложение может само проверять время жизни, или дождаться пока во время очередного использования сервер ответит «ой, всё»), приложение используетrefresh token, чтобы обновить оба токена и продолжить использовать новый access token

Примерно так это все объяснено в документации OAuth, на Википедии, в нашей документации. И такое объяснение не отвечает на вопрос нафига. Зачем нужны два токена, если можно обойтись одним? В вопросе на stackoverflow даны несколько объяснений уровня «ну, access token можно менее надежно хранить чем refresh token и не бояться использовать вне HTTPS соединений. Например, хранить access token на frontend, а refresh token на backend» или «refresh token используется для доступа к заведомо безопасному сервису, а access token’ом потом можно тыкать во всякие подозрительные места и не очень бояться, что его сольют». Это может быть разумно для авторизации через Facebook и последующего использования без HTTPS. Но у нас-то везде HTTPS! И сервис у нас тоже один, наш. Зачем нам второй токен?

Зачем на самом деле нужен второй токен

Все оказалось и проще, и сложнее чем я думал. Следите за руками:

Случай 1: Боб узнал оба токена Алисы и не воспользовался refresh

В этом случае Боб получит доступ к сервису на время жизни access token. Как только оно истечет и приложение, которым пользуется Алиса, воспользуется refresh token, сервер вернет новую пару токенов, а те, что узнал Боб, превратятся в тыкву.

Случай 2: Боб узнал оба токена Алисы и воспользовался refresh

В этом случае оба токена Алисы превращаются в тыкву, приложение предлагает ей авторизоваться логином и паролем, сервер возвращает новую пару токенов, а те, что узнал Боб, снова превратятся в тыкву (тут есть нюанс с device id, может вернуть ту же пару что и у Боба. В таком случае следующее использование refresh токена превратит токены Боба в то, что изображено справа).

Таким образом, схема refresh + access токен ограничивает время, на которое атакующий может получить доступ к сервису. По сравнению с одним токеном, которым злоумышленник может пользоваться неделями и никто об этом не узнает.

• Блог компании Voximplant
• Информационная безопасность
• Веб-разработка
• Программирование
• Разработка мобильных приложений