Общая информация
Утилита Диагностики Рутокен (УДР) предназначена для проверки работы устройств Рутокен. Она позволяет получить полную информацию о работе устройства и его параметрах. На некоторых устройствах также можно выгрузить журнал событий безопасности с информацией об операциях, совершенных на Рутокене.
Утилита реализована в виде консольного приложения, которое необходимо загрузить на компьютер и сохранить в отдельной папке. После запуска утилиты в ее папке появится папка logs
, в которой будут создаваться лог-файлы в формате TXT.
Количество проверок зависит от модели устройства Рутокен и версии микропрограммы (МП). Все проверки и их наличие для разных моделей Рутокенов описаны в Приложении 1.
Поддерживаемые ОС
Утилита работает в следующих операционных системах (ОС):
- Windows 7 и выше;
- macOS 10.15 и выше;
- DEB-based дистрибутивы Linux:
- Ubuntu 18 и выше;
- Debian 10 и выше;
- Astra Linux 1.7, 1.8.
- RPM-based дистрибутивы Linux:
- Centos 7, 8;
- ROSA Linux 7.3 и выше;
- РЕД ОС 7.3, 8;
- Alter OS.
- ALT Linux 8, 9, 10.
Поддерживаемые устройства
При помощи утилиты можно проверить работу следующих устройств:
- Рутокен TLS;
- линейка Рутокен Lite;
- линейка Рутокен ЭЦП 2.0;
- линейка Рутокен ЭЦП 3.0:
- Рутокен ЭЦП 3.0 3220;
- Рутокен ЭЦП 3.0 NFC 3100;
- Рутокен ЭЦП 3.0 3120.
Журнал событий безопасности доступен на следующих устройствах:
Рутокен ЭЦП 3.0 3120.
Работа с утилитой
- Загрузите утилиту на компьютер и сохраните ее в отдельной папке.
Подключите Рутокен к компьютеру.
К компьютеру должно быть подключено только одно устройство Рутокен, иначе произвести диагностику не удастся.
- В зависимости от ОС компьютера, к которому подключено устройство, выполните следующие действия:
- Если работа утилиты завершилась с ошибкой, найдите текст ошибки в таблице ниже, устраните проблему и снова запустите утилиту.
- Если в консоли отобразилось сообщение «Процесс завершен», то диагностика прошла успешно. Чтобы ознакомиться с ее результатами, откройте сохраненный лог-файл.
Диагностика внешних пользователей
Если диагностика проводилась на компьютере внешнего пользователя, после окончания работы удалите УДР, лог-файлы и файлы журнала событий безопасности.
Ошибки диагностики
Текст ошибки | Описание | Решение |
---|---|---|
Не удалось произвести проверку. Проверьте чтобы к компьютеру был подключен только один Рутокен | К компьютеру подключено несколько устройств Рутокен | Отключите все устройства Рутокен кроме того, которое нужно диагностировать, и запустите утилиту снова |
Не удалось сохранить Лог-файл | У утилиты диагностики нет прав на запись файлов в директорию | Убедитесь, что у вас есть права на создание файлов На ОС Windows:
На ОС Linux:
На macOS:
|
some pcsc error acquired: some pcsc error acquired: | Утилита потеряла связь с устройством | Отключите Рутокен от компьютера, подключите снова и перезапустите утилиту |
Не удалось распознать Рутокен | К компьютеру подключено устройство Рутокен, но утилита не может его опознать | Если ошибка возникла при попытке диагностировать:
|
Лог-файл диагностики
Лог-файл диагностики — это файл, в котором содержатся базовые сведения об устройстве и его состоянии, а также информация о проведенных в ходе диагностики проверках и их результатах. Данные из лог-файла диагностики используются для оценки работоспособности устройства.
Параметры лог-файла диагностики
- Сохраняется в папке
logs
в той же директории, где находится утилитаrutoken-diagnostic-tool
. - Сохраняется в формате TXT, кодировка UTF-8.
- В конце каждой строки лог-файла используется символ LF (Line Feed).
- Название лог-файла состоит из: префикса
log
, ID Рутокена, даты и времени его диагностики.
Пример лог-файла диагностики
Содержание лог-файла диагностики
Количество разделов и информация в них могут меняться в зависимости от того, какие проверки может пройти устройство. Полный список этих проверок находится в Приложении 1.
Раздел | Содержание |
---|---|
Проверка целостности ОС устройства | Контрольная сумма ОС Рутокен, которая вычисляется в ходе проверки, Если в результате данной проверки отобразилась ошибка, то результаты остальных проверок могут быть недостоверными, поэтому мы не рекомендуем их использовать |
Получение кратких сведений об устройстве | Информация о подключенном Рутокене:
|
Проверка работы криптоалгоритмов | Информация о работе криптоалгоритмов:
|
Проверка целостности КИ | Информация о состоянии сохраненных на Рутокене объектов:
|
Получение журнала ошибочных операций | Значения счетчиков ошибочных операций |
Получение статуса сектора памяти | Информация об использованной встроенной EEPROM-памяти устройства по секторам |
Проверка работоспособности генератора случайных чисел (ГСЧ) | Информация о состоянии ГСЧ |
Проверка поддержки журнала СБ | Информация о том, поддерживает ли устройство работу с журналом событий безопасности. Если устройство поддерживает журналирование, после этого раздела будет приведен лог выгрузки журнала событий безопасности |
Последняя строка лог-файла | Итог прохождения проверок |
Интерпретация результатов диагностики
Уровни критичности
В результате проверки рядом с каждым перечисленным ниже параметром отображается уровень критичности. Этот уровень помогает оценить работоспособность Рутокена.
В утилите реализовано два уровня критичности:
- critical — означает, что Рутокен можно использовать с ограничениями.
- fatal — означает, что Рутокен нельзя использовать.
Уровень критичности оценивается с некоторыми ограничениями:
- не оцениваются числовые данные;
- не оцениваются ошибки, возникающие при получении информации.
Если проверка прошла успешно, уровень критичности не отображается.
Названия проверок и критичность их влияния на работоспособность Рутокена представлены в таблице ниже.
№ | Название проверки | Влияние на работоспособность |
---|---|---|
1 | Проверка целостности ОС Рутокен | [fatal] |
2 | Проверка работы криптоалгоритмов | [fatal] — если в результате проверки работы всех криптоалгоритмов отобразились ошибки |
2.1 | Тестирование алгоритма ГОСТ 28147-89 | [critical] |
2.2 | Тестирование алгоритма ГОСТ 34.10-2001 | [critical] |
2.3 | Тестирование алгоритма ГОСТ 34.11-1994 | [critical] |
2.4 | Тестирование алгоритма ВКО 2001 | [critical] |
2.5 | Тестирование алгоритма ГОСТ 34.10-2012 | [critical] |
2.6 | Тестирование алгоритма ГОСТ 34.11-2012 | [critical] |
2.7 | Тестирование алгоритма ВКО 2012 | [critical] |
2.8 | Тестирование алгоритма ГОСТ Р 34.12-2015 Магма | [critical] |
2.9 | Тестирование алгоритма ГОСТ Р 34.12-2015 Кузнечик | [critical] |
2.10 | Тестирование алгоритма ECDH | [critical] |
3 | Проверка целостности КИ | [critical] — если в результате проверки целостности всей ключевой информации отобразилась хотя бы одна ошибка рядом с параметром со статусом [critical]. [fatal] — если в результате проверки целостности всей ключевой информации отобразилась хотя бы одна ошибка рядом с параметром со статусом [fatal] |
3.1 | Проверка системной ключевой информации | Если при проверке возникла ошибка, уровень критичности [fatal] присваивается:
В общем заключении проверки уровень [fatal] присваивается, если в результате проверки хотя бы одного из параметров возникла ошибка со статусом [fatal] |
3.2 | Проверка Глобальных PIN-кодов | [fatal] — если в результате проверки глобальных PIN-кодов отобразилась ошибка рядом с параметром Проверка целостности (Администратора/Пользователя) |
3.3 | Проверка RSF файлов | Если при проверке возникла ошибка, уровень критичности [critical] присваивается:
Если проверяемые объекты отсутствуют на Рутокене, уровень критичности [critical] присваивается:
В общем заключении проверки уровень [fatal] присваивается, если:
|
4 | Получение статуса секторов памяти | [critical] — если есть хоть один сектор, который содержит недостоверное число перезаписей. [fatal] — если все секторы содержат недостоверное число перезаписей |
5 | Проверка работоспособности ГСЧ | [fatal] |
Статусы
В лог-файле после каждого параметра диагностики отображаются статусы. Описания значений этих статусов представлены в таблице.
Условие | Вывод статуса |
---|---|
Проверки | |
Проверка прошла успешно | -> Успешно |
Проверяемые файлы отсутствуют | -> ОБЪЕКТЫ НЕ ОБНАРУЖЕНЫ |
Проверка прошла с ошибкой | -> !ОШИБКА [код ошибки] - <текст ошибки> или [критичность ошибки] -> !ОШИБКА [код ошибки] - <текст ошибки> |
Рутокен не поддерживает проверку | Запрошенная функция не поддерживается |
Общее заключение (последняя строка лог-файла) | |
Все проверки завершились успешно | Все проверки прошли успешно |
Хотя бы одна проверка завершилась с ошибкой | При диагностике были выявлены ошибки |
Лог выгрузки журнала событий безопасности
Процесс выгрузки журнала СБ поэтапно записывается в лог-файле диагностики. Если устройство не поддерживает журналирование или в ходе выгрузки журнала СБ возникнет ошибка, запись об этом отобразится в лог-файле.
Этап выгрузки | Результат | |
---|---|---|
Проверка поддержки журнала СБ |
Не удалось проверить, поддерживается ли журналирование на устройстве. Процесс выгрузки прерывается | |
Устройство не поддерживает журналирование. Список устройств, которые поддерживают журналирование, находится в разделе Поддерживаемые устройства. Процесс выгрузки прерывается | ||
Устройство поддерживает журналирование. Утилита переходит к следующему этапу выгрузки | ||
Чтение журнала СБ |
Не удалось прочесть журнал или журналирование не поддерживается. Процесс выгрузки прерывается | |
Журнал удалось прочитать. Утилита переходит к следующему этапу выгрузки | ||
Декодирование журнала СБ |
В журнале нашлись поврежденные TLV-структуры. Журнал СБ выгружается в бинарном формате | |
В журнале встретились неизвестные теги или возникли проблемы при преобразовании известных тегов. Журнал СБ выгружается, операции в нем записываются последовательно два раза:
| ||
Журнал был полностью декодирован. Утилита переходит к следующему этапу выгрузки | ||
Запись журнала СБ в файл |
Чтение и декодирование журнала прошло успешно, но возникла ошибка при выгрузке журнала в файл. Журнал СБ не выгружается | |
Журнал успешно выгрузился в файл. Утилита переходит к следующему этапу выгрузки | ||
Расчет SHA256 файла журнала СБ |
Утилита успешно вычислила хеш-код файла журнала по алгоритму SHA256. Выгрузка журнала завершена |
Журнал событий безопасности
Журнал событий безопасности поддерживается только на устройствах Рутокен ЭЦП 3.0 3120.
Журнал событий безопасности — это функциональность УДР, записывающая операции, происходящие на Рутокене. Данная функциональность требуется для расследования инцидентов. На Рутокене журнал хранится в бинарном формате в режиме «только для чтения». После завершения диагностики УДР автоматически выгружает журнал в человекочитаемом формате на компьютер, к которому подключен Рутокен.
Параметры лог-файла журнала СБ
- Сохраняется в папке
logs
в той же директории, где находится утилитаrutoken-diagnostic-tool.
- Создается одновременно с лог-файлом диагностики, но сохраняется в отдельный лог-файл.
- Сохраняется в формате TXT, кодировка UTF-8.
- В конце каждой строки журнала используется символ LF (Line Feed).
- Название лог-файла журнала состоит из: префикса
security_log
, ID Рутокена, даты и времени его диагностики.
Пример лог-файла журнала событий безопасности
Содержание лог-файла журнала СБ
Если после окончания диагностики лог-файл журнала СБ не появился в папке logs
, выгрузился в бинарном формате или в нем не хватает информации, проверьте, есть ли в лог-файле диагностики ошибки, связанные с обработкой журнала. Подробнее об этих ошибках можно почитать в соответствующем разделе.
Ниже приведен список операций, информация о которых записывается в журнал СБ. В начало журнала записывается его версия, далее записываются операции, относящиеся к этой версии. Если версий две и более, записи выводятся в следующем формате:
- Первая версия журнала.
- Записи операций, относящиеся к первой версии журнала (если такие операции были).
- Вторая версия журнала.
- Записи операций, относящиеся ко второй версии журнала (если такие операции были).
- и т.д.
Каждая запись об операции, кроме записи с версией журнала, сопровождается кодом возврата (SW-кодом), который состоит из двух частей. Код SW1 задает класс ошибки, а код SW2 позволяет конкретизировать данную ошибку в пределах класса. Возможные значения SW-кодов приведены в Приложении 2.
№ | Операция | Отображение |
---|---|---|
1 | Версия журнала |
|
2 | Импорт закрытого ключа |
|
3 | Генерация ключевой пары |
|
4 | Удаление закрытого ключа |
|
5 | Генерация ключевой пары ФКН2 |
|
6 | Удаление контейнера ФКН2 |
|
7 | Смена PIN Пользователя |
|
8 | Импорт локального PIN |
|
9 | Разблокировка PIN-кода |
|
10 | Неуспешная аутентификация |
|
11 | Форматирование |
|
Проверка целостности данных лог-файла журнала СБ
На устройстве Рутокен журнал СБ хранится в режиме «только для чтения» (read only), однако после выгрузки полученный TXT-файл можно изменять. Проверить, вносились ли в лог-файл журнала изменения, можно с помощью сравнения хешей — хеш меняется, если изменяется содержимое файла. Для этого:
- В лог-файле диагностики, который был создан одновременно с лог-файлом журнала, найдите строку SHA256 файла журнала СБ — это хеш лог-файла журнала, который был автоматически вычислен УДР при его создании.
- Вычислите хеш текущей версии лог-файла журнала самостоятельно. Сделать это можно, например, с помощью консольных утилит:
ОС Windows: certutil -hashfile "имя_файла_журнала_СБ.txt" sha256
ОС Linux: sha256sum "имя_файла_журнала_СБ.txt"
macOS: shasum -a 256 "имя_файла_журнала_СБ.txt"
- Сравните полученный хеш с хешем из лог-файла диагностики. Если хеш, сгенерированный с помощью консольной утилиты, не совпадает с хешем в лог-файле диагностики, значит, после выгрузки в файл журнала были внесены изменения.
Определение сертификата с удаленным открытым ключем
Найти в журнале СБ события, связанные с конкретной ключевой парой (например, чтобы определить, от какого сертификата удалили ключевую пару), можно с помощью первых 4 байтов хеша открытого ключа.
Чтобы вычислить хеш открытого ключа:
- Откройте онлайн-утилиту ASN.1 JavaScript Decoder.
- Загрузите сертификат одним из двух способов:
- нажмите Выберите файл и выберите файл сертификата;
- перетащите сертификат на вкладку с утилитой.
- Найдите строку
OCTET STRING
в узлеsubjectPublicKey
. - Нажмите на эту строку и выберите Copy value.
- Перейдите на сайт https://hashing.tools/streebog/streebog-256.
- В выпадающем меню формата входных (1) и выходных (2) данных выберите hex.
- Вставьте скопированное значение в поле Input и удалите длину ключа, а также перенос строки после нее.
Хеш высчитается автоматически, как только сайт обнаружит в поле Input корректные данные. - Скопируйте первые 4 байта (8 символов) высчитанного хеша и найдите их в журнале событий безопасности.
Приложение 1. Список проверок на устройствах с разными микропрограммами
Лог-файл содержит краткие сведения об устройстве, включая модель устройства и версию микропрограммы. Предпоследнее число в этой версии необходимо для поиска проверки, актуальной для устройства с определенной микропрограммой.
Пример
В лог-файле диагностики видно, что модель Рутокена — Рутокен ЭЦП 3.0 3120, а версия микропрограммы — 67.4.32.2.
Чтобы понять, какие проверки актуальны для этого устройства и этой версии микропрограммы, смотрим на Таблицу 3 и столбец МП 32.
Приложение 2. Значения SW-кодов
Рутокен может возвращать следующие сочетания кодов SW1-SW2: