Носители удостоверений

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

Выбор носителя связан с выбором процесса выпуска — см. issuance-workflows.md.

Сводка

Носитель	Что хранит	Ключ извлекаем	Секреты	Режим проверки
Флешка	контейнер certs/user.p12 на разделе	да	пароль контейнера	pkcs12
Пассивный токен	контейнер приватным объектом данных	да	PIN и пароль контейнера	pkcs12
Комбинированный токен	обе роли, в зависимости от того, чем пользуются	да	как у выбранной роли	pkcs12
Активный токен	ключ и сертификат объектами устройства	нет	PIN	pkcs11

Флешка

Обычный USB-накопитель. Проверка на устройстве ищет контейнер по точному пути certs/user.p12 (путь настраивается ключом pkcs12_path_pattern), цепочку — по certs/chain.pem. Поиска по маске нет: файл с другим именем найден не будет.

Метка и имя носителя ничего не решают — доверие даёт расшифровка контейнера и проверка цепочки. Флешку можно скопировать целиком: клон с известным паролем пройдёт проверку. Это свойство процесса с извлекаемым ключом, а не дефект.

Файловая система — vfat, exfat, ext4 или ntfs; носитель монтируется только для чтения. Неверный пароль ничего не блокирует: счётчика попыток у флешки нет.

Пассивный токен

Устройство с интерфейсом смарт-карты, но без криптографии: C_GetMechanismList у него пуст, импорт закрытого ключа отвергается. Пример — Рутокен Lite.

Такой токен работает как флешка в форм-факторе токена: контейнер лежит на нём объектом данных, а PIN закрывает доступ к объекту. Подпись при входе выполняет хост, а не устройство.

Три особенности, о которых нужно знать:

• Секретов два. PIN токена и пароль контейнера — разные вещи, и путать их в инструкциях нельзя.
• Объект обязан быть приватным. Контейнер, записанный публичным объектом, читается без PIN. Проверка на устройстве такие объекты отвергает.
• Размер объекта ограничен, и превышение не диагностируется. На проверенном экземпляре запись объекта больше ~32 КБ завершалась «успешно», а читалось усечённое содержимое или ничего. Поэтому запись всегда проверяется обратным чтением. Лимит измерен на одном экземпляре одной модели и не является общим правилом.

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

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

Как записать конверт

Записывает конверт та же команда, что и для флешки, — меняются только аргументы носителя:

issuer prepare-carrier --p12 ivanov.p12 \
    --module /usr/lib/librtpkcs11ecp.so \
    --object-label tessera-credential \
    --token-label "Rutoken lite" \
    --pinentry

PIN значением аргумента не передаётся: аргументы видны в списке процессов. Источник PIN задаётся флагом — --pinentry, --pin-file или --pin-stdin (см. issuer.md).

--token-label — не формальность. У выпускающего обычно подключён и токен подписи, и токен-носитель; без метки «первый слот» с равной вероятностью окажется не тем устройством. Метку токена печатает pkcs11-tool -L.

Записанный объект приватный, и это не настраивается: публичный объект читался бы без PIN. После записи объект перечитывается поиском по метке — так же, как его будет искать устройство при входе, — и сверяется с исходником побайтово. Если прочитанное расходится с исходником, запись считается несостоявшейся и объект стирается: обломок на носителе устройство прочитает как повреждённое удостоверение, то есть как плохую выдачу, а не как отсутствие записи.

Занятая метка не перезаписывается молча — требуется --force, и тогда уничтожаются все объекты с этой меткой: два объекта под одним именем оставили бы выбор между старым и новым удостоверением самому устройству.

Цепочка на токен не пишется: --chain вместе с токеном отвергается. На токене лежит только конверт.

Как настроить устройство

По умолчанию проверка ищет конверт на разделе съёмного носителя. Чтение с токена включается в конфигурации устройства:

mode = "pkcs12"
pkcs12_source = "token_object"
pkcs12_token_object_label = "tessera-credential"
pkcs11_module = "/usr/lib/librtpkcs11ecp.so"
pkcs11_token_label = "Rutoken lite"

Метка объекта обязательна: устройство находит конверт по ней и больше ни по чему, поэтому угаданное значение по умолчанию отправило бы вход искать объект, которого инструмент выпуска никогда не писал. Путь к модулю PKCS#11 при этом источнике тоже обязателен — без него до токена не добраться. Обе проверки срабатывают при чтении конфигурации, а не при входе: оператор узнаёт об ошибке, когда пишет конфигурацию, а не когда инженер стоит у заблокированного экрана.

Метку токена стоит задавать и здесь. Если её нет, а подключено несколько подходящих токенов, вход прерывается, а не выбирает сам: чтение приватного объекта требует входа по PIN, и перебор предъявлял бы PIN устройствам, которым он не предназначен, расходуя их счётчики попыток.

Раздел съёмного носителя при этом источнике не используется вовсе — устройство не ждёт носитель и не монтирует его. Всё, что происходит после получения конверта, одинаково для обоих носителей: тот же ввод PIN, та же проверка владения ключом, та же цепочка, те же роли.

С одной оговоркой: промежуточные удостоверяющие центры должны быть в доверии устройства. На флешке цепочку можно было положить рядом с контейнером (certs/chain.pem), и устройство достраивало путь из неё; на токене такого файла нет, поэтому путь строится только из того, что перечислено в разделе [trust] конфигурации. Установка, где цепочка держалась на файле с флешки, после переключения на токен перестанет собирать путь и будет отказывать во входе, пока промежуточные не окажутся в доверии.

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

Отсюда задержка, которой у флешки нет. Носитель признаётся пропавшим не с первого опроса: пропажу должны подтвердить три опроса подряд — иначе кратковременный сбой службы смарт-карт гасил бы сессию инженера, у которого токен на месте. Поэтому при исправном опросе реакция наступает не позже, чем через три интервала плюс выдержку: при настройках по умолчанию и нулевой выдержке — около 6 секунд. Речь именно об обнаружении: само действие — блокировка сессии — занимает своё время сверх этого.

Интервал задаётся ключом token_poll_interval_seconds (по умолчанию 2 секунды). Меньший интервал ускоряет обнаружение и учащает обращения к устройству.

Опрос может и сам перестать отвечать — если пропал считыватель или зависла библиотека производителя. Три неудачных опроса подряд считаются потерей наблюдения, и что это значит, зависит от режима мониторинга: strict обещает непрерывное присутствие носителя, поэтому потерю наблюдения приравнивает к извлечению; permissive такого обещания не даёт и только пишет ошибку в журнал.

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

Комбинированный токен

Устройство, совмещающее раздел mass storage и смарт-карту. Работает как флешка или как токен — в зависимости от того, что настроено в конфигурации устройства. Отдельного режима проверки для него нет.

Активный токен

Устройство с криптографией на борту: ключевая пара порождается внутри и закрытая часть не покидает устройство. Подпись при входе выполняет само устройство. Примеры — Рутокен ЭЦП 2.0 и 3.0, JaCarta-2 ГОСТ, ESMART.

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

Сертификат ищется среди объектов устройства, закрытый ключ — по идентификатору этого сертификата. Поэтому сертификат записывается с тем же идентификатором, что у ключа, которым подписывался запрос.

Про ГОСТ. Устройство с ГОСТ-механизмами подключается как носитель, но подпись ключом ГОСТ на входе сейчас не поддерживается. Поддерживаются RSA и эллиптические кривые P-256 и P-384.

Пути к модулю PKCS#11

Работа с токеном требует библиотеки PKCS#11 от производителя устройства. Путь к ней указывается ключом pkcs11_module в конфигурации устройства и флагом --module в инструментах выпуска.

Производитель	Операционная система	Типичный путь
Актив (Рутокен)	Linux	/usr/lib/librtpkcs11ecp.so
Актив (Рутокен)	macOS	/Applications/Рутокен для macOS.app/Contents/PlugIns/RutokenCTK.appex/Contents/Frameworks/rtpkcs11ecp.framework/rtpkcs11ecp
Актив (Рутокен)	Windows	rtPKCS11ECP.dll в системном каталоге
Аладдин (JaCarta)	Linux	/usr/lib/libjcPKCS11-2.so
Аладдин (JaCarta)	Windows	jcPKCS11-2.dll в системном каталоге
OpenSC	Linux	/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
OpenSC	macOS	/Library/OpenSC/lib/opensc-pkcs11.so

Пути зависят от версии пакета производителя — при расхождении смотрите документацию производителя. Путь для macOS выше проверен на версии 2.14.1.

На macOS драйвер чтения смарт-карт встроен в систему; отдельно устанавливать его не требуется.

Если носителя нет вовсе

Когда выдавать носители инженерам нецелесообразно — подрядчики, разовые выезды, парк без логистики токенов, — вторым фактором может быть телефон инженера: QR с экрана устройства, подтверждение через корпоративный вход, короткий код. Это отдельный продукт — Tessera Codes; устройство при этом по-прежнему проверяет вход само.

См. также

• issuance-workflows.md — какой процесс выпуска выбрать
• configuration.md — ключи pkcs12_path_pattern, pkcs11_module, usb_allowed_devices и остальные
• troubleshooting.md — разбор отказов на входе
• Tessera Access — обзор продукта: вход по удостоверениям, делегирование, отзыв