Safenet ikey driver что это

Обновлено: 02.07.2024

Примерно год назад, в статье «eToken жил, eToken жив, eToken будет жить» я упоминал такой продукт как Gemalto Safenet Authentcation Service, пришло время рассказать про него подробнее. Данная статья вводная, но будут и другие, более технические и думаю даже с реальными бизнес кейсами.

IT специалисты часто сталкиваются с вопросом об усилении безопасности того или иного сервиса. И вопрос идентификации пользователя с прохождением аутентификации так же играет ключевую роль в безопасности сервиса.

Использовать связку Login & Password?
Развернуть PKI инфраструктуру и раздать всем сертификаты?
Усилить аутентификацию одноразовыми паролями?

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

Разумеется, использование отчуждаемых носителей в виде смарт-карт или USB-токенов значительно надёжнее, чем использование паролей. Но что делать, когда наступает частный случай, когда пользователю необходимо в данный момент воспользоваться смарт-картой или USB-токеном вне офиса. Не говоря уже о том, что для каждого типа смарт-карт и USB-токенов необходимо наличие специализированного программного обеспечения (ПО) на компьютере. На что в публичной зоне, надеяться не приходится и мало вероятно удастся его установить. Так же нельзя исключать, необходимость наличия свободного USB порта, который может быть заблокирован для подключения USB-токенов или оборудования ПК со считывателем для работы смарт-карт. А с учётом возросшей популярности у пользователей работать за мобильными устройствами, вероятность использования на них отчуждаемых носителей существенно ниже.

Куда легче в использовании одноразовые пароли — OTP — One-Time Password для однократной процедуры аутентификации пользователя. Такой пароль проще и удобней в использовании. Одноразовый пароль нет смысла перехватывать с помощью кейлогера или опасаться, что он будет закэширован на компьютере. Бесполезно подглядывать одноразовый пароль или думать, что его могут перехватить в виде сетевых пакетов. На сегодняшний момент это единственный вид токенов, которые не требуют ни подключения к персональному компьютеру, ни наличия на нём специализированного ПО, работая с любой платформой в любой среде. А большой выбор модельного ряда в виде генераторов одноразовых паролей позволит предприятиям обеспечить усиленную безопасность в предоставлении доступа к корпоративным ресурсам, порталу (-ам) или личному кабинету пользователя, к которым сейчас со стороны бизнеса идет отдельное требование по безопасности.

Что делать, когда мы определились с методом прохождения пользователем аутентификации? Кому передать роль ответственного за управление и поддержку сервисом? Как управлять жизненным циклом OTP-токенов, которые раздали пользователям? Как отслеживать их статусы? Как повысить сервис поддержки пользователей? Эти, а также ещё множество вопросов может возникнуть перед IT менеджерами.

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

Нельзя пройти и мимо решения компании Gemalto-SafeNet – SafeNet Authentication Service, которое ежегодно номинируется на «Лучшее решение по мульти-факторной аутентификации» авторитетными изданиями и исследовательскими компаниями.

Выбор правильного решения для аутентификации имеет большое значение в снижение бизнес рисков. Разумеется, лучшие решения имеют самый большой ряд поддерживаемых моделей токенов, и могут защитить как облачные, так и локальные приложения, и сервисы, а также любой сетевой доступ с любого устройства. Но речь идет не только о безопасности, речь идет так же о том, как легко вы сможете развертывать, управлять и масштабировать решение аутентификации.
Что из себя представляет SafeNet Authentication Service.

SafeNet Authentication Service — это полностью автоматизированный сервис многофакторной аутентификации, целью которого является обслуживание пользователей с токенами. SafeNet Authentication Service распространяется в 2-х видах редакций. Локальная версия, которую можно самостоятельно развернуть в собственной инфраструктуре предприятии. А также в виде облачной редакции — такой сервис уже развернут и не надо задаваться вопросом: «где найти ресурсы на его разворачивание?». Управление SafeNet Authentication Service осуществляется в браузерной консоли администратора. В консоли оптимальные условия управления процессов: автоматическая подготовка пользователей и репозитария пользователей, скажем, если у вас за основу пользователей берётся LDAP-каталог или СУБД; настройка пользователей самообслуживания; широчайшие настройки механизмов проверки подлинности и защита для всех ваших самых ценных корпоративных ресурсов, как локальных, так и веб-ресурсов или ресурсов в «облаке».

SafeNet Authentication Service поддерживает следующие методы аутентификации и форм-факторы:

Одноразовый пароль (OTP)
OOB с помощью получения уведомления, по SMS и/или на электронную почту
— Аутентификации на основе матрицы шаблонов (GrIDsure)

Аппаратные токены (OTP-токен)
Программные токены (OTP приложения)
— Телефон-как-токен

Аппаратные OTP-токены используются для создания высокозащищённых одноразовых паролей. Большой выбор модельного ряда аппаратных токенов eToken PASS, eToken GOLD, KT-4, RB-1 позволяет авторизовываться пользователям к критически важным приложениям и данным.

SafeNet iKey

SafeNet iKey - портативные устройства, обеспечивающие аутентификацию пользователя и хранение конфиденциальной информации.

Применение iKey повышает уровень защищенности информации на компьютере без дополнительных затрат на приобретение и установку специального программного обеспечения.

Комплект iKey включает аппаратный электронный ключ, выполненный в форм-факторе USB-ключа, набор драйверов и прикладных программ для обеспечения доступа к защищаемым объектам.

iKey - первый в своем роде персональный идентификатор, выполненный для стандарта USB, который объединил функции обеспечения контроля физического доступа в здания и контроля доступа к критически важным для бизнеса данным и приложениям.

На индивидуальном рабочем месте пользователь вставляет iKey в USB-порт персонального компьютера и входит в корпоративную сеть, используя Персональный Идентификационный Номер (ПИН). Для перемещения по офису и доступа в закрытые внутренние помещения сотрудники компании должны носить iKey с собой. Если извлечь персональный идентификатор из USB-порта, сессия прерывается и блокирует попытки получить доступ к критически важной корпоративной информации.

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

Идентификация и строгая двухфакторная аутентификация пользователя
Аутентификация пользователя при доступе к защищенным корпоративным данным через SSL
Аутентификация пользователя при доступе к защищенным веб-ресурсам
Хранение цифровых сертификатов и закрытых ключей пользователя
Обеспечение безопасного входа в сеть предприятия с любой рабочей станции
Автоматическая блокировка рабочей станции при извлечении iKey
Поддержка аутентификации в VPN-клиентах
Защита электронной почты

iKey поддерживают наиболее распространенные операционные системы MS Windows, Linux, Mac, работают в составе программного обеспечения Axis Single Sign-On и SafeNet Card Managment System.

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

После установки токена JaCarta PKI в USB порт сервера и запуска системы проверяем, что новое устройство обнаружено и появилось в списке:

В нашем случае это Bus 004 Device 003: ID 24dc:0101

Пока не установлены все необходимые пакеты, информация о токене не отобразится.

Установка драйверов и ПО для работы с JaCarta PKI

Согласно Руководству по внедрению «JaCarta для Linux» пункт 4.2., первым делом требуется установить пакеты pcsc-lite, ccid и libusb.

Для работы утилиты управления JaCarta необходимо установить следующие компоненты:

PC/SC Lite — промежуточный слой для обеспечения доступа к смарт-картам по стандарту PC/SC, пакет pcsc-lite.
Библиотеки ccid и libusb для работы с USB-ключами, смарт-картами и считывателями смарт-карт.

Выполняем проверку наличия этих пакетов и установку:

zypper search pcsc-lite

zypper search libusb

zypper install pcsc-lite

zypper search CCID

zypper install pcsc-ccid

zypper search CCID

zypper install libusb

В итоге пакет pcsc-lite был обновлен, CCID установлен, libusb никаких действия не требовалось.

Следующими двумя командами выполняем установку пакета с драйверами и программным обеспечением непосредственно для работы с JaCarta PKI:

zypper install idprotectclientlib-637.03-0.x86_64.rpm

zypper install idprotectclient-637.03-0.x86_64.rpm

Проверяем, что драйверы и ПО для JaCarta PKI установились:

zypper search idprotectclient

При попытках заставить работать SafeNet eToken PRO я нашел информацию, что предустановленный в SLES пакет openct — Library for Smart Card Readers может конфликтовать с pcsc-lite — PCSC Smart Cards Library, установку которого требует руководство Аладдин Р.Д.

zypper search openct

Поэтому пакет openct удаляем:

Теперь все необходимые драйверы и ПО для работы с токеном установлены.

Выполняем диагностику с помощью утилиты pcsc-tools и убеждаемся, что JaCarta определяется в операционной системе:

Установка пакетов КриптоПро CSP

При установке КриптоПро CSP по умолчанию нужные пакеты для работы с токенами и смарт-картами отсутствуют.

zypper search cprocsp

Выполняем установку в CSP компонента поддержки JaCarta components for CryptoPro CSP

zypper install cprocsp-rdr-jacarta-64-3.6.408.683-4.x86_64.rpm

Устанавливаем базовые пакеты поддержки считывателей и ключевых носителей:

zypper install cprocsp-rdr-pcsc-64-4.0.9944-5.x86_64.rpm

zypper install lsb-cprocsp-pkcs11-64-4.0.9944-5.x86_64.rpm

Теперь можно установить модули для работы с остальными видами носителей и компонент GUI:

zypper install cprocsp-rdr-emv-64-4.0.9944-5.x86_64.rpm

Проверяем итоговую конфигурацию КриптоПро CSP:

Чтобы применить изменения, выполняем перезапуск службы криптографического провайдера и проверяем ее статус:

Настройка и диагностика КриптоПро CSP

Проверим, видит ли криптографический провайдер наш токен и другие доступные типы носителей следующими командами:

/opt/cprocsp/bin/amd64/csptest -card -enum -v –v

/opt/cprocsp/bin/amd64/csptest -enum -info -type PP_ENUMREADERS | iconv -f cp1251

/opt/cprocsp/sbin/amd64/cpconfig -hardware reader -view -f cp1251

Aladdin R.D. JaCarta [SCR Interface] (000000000000) 00 00 — это наш носитель.

Следуя инструкции КриптоПро CSP для Linux. Настройка, выполняем его регистрацию в криптографическом провайдере:

В результате выполнения в конфигурационный файл /etc/opt/cprocsp/config64.ini
в раздел Safenet ikey driver что это будет добавлена запись:

Safenet ikey driver что это (000000000000) 00 00"\Default]

Чтобы выполнить требования Формуляра, Правил пользования и Руководства администратора безопасности КриптоПро CSP:

Использование СКЗИ «КриптоПро CSP» версии 4.0 с выключенным режимом усиленного контроля использования ключей не допускается. Включение данного режима описано в документах ЖТЯИ.00087-01 91 02. Руководство администратора безопасности.

Необходимо включить режим усиленного контроля использования ключей:

Проверяем, что режим включен:

cat /etc/opt/cprocsp/config64.ini | grep StrengthenedKeyUsageControl

Выполняем перезапуск службы криптографического провайдера:

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

/opt/cprocsp/bin/amd64/csptest -keyset –verifycontext

/opt/cprocsp/bin/amd64/csptest -keyset -verifycontext -enum –unique

Работа с токеном JaCarta PKI

Запустим программу Xming (X11 forwarding) на своей станции, чтобы по SSH иметь возможность открывать и работать с графическими интерфейсами нужных утилит.

После установки IDProtectClient — программного обеспечения для работы с JaCarta PKI, на сервере в папке /usr/share/applications появились два файла:

Это ярлыки, в которых можно посмотреть параметры запуска утилит Exec=/usr/bin/SACTools

Запустим утилиту IDProtectPINTool.

С помощью нее задаются и меняются PIN-коды доступа к токену.

При первой инициализации токена будет полезна ссылка, содержащая PIN-коды (пароли) ключевых носителей по умолчанию

Программа IDProtect_Manager позволяет просматривать информацию о токене и контейнере с ключами и сертификатом:

Для доступа к контейнеру с ключами нужно ввести пароль:

Для работы с SafeNet Authentication Client eToken PRO существуют аналогичные программы — SafeNet Authentication Client Monitor и SafeNet Authentication Client Tools, которые запускаются так:

Выполнять операции непосредственно с ключевыми контейнерами удобнее в интерфейсе криптографического провайдера КриптоПро JavaCSP:

Для отображения информации о содержимом контейнера с ключами можно выполнить команду:

Для диагностики контейнера используется эта же команда с ключом –check

Потребуется ввести пароль от контейнера:

Программное извлечение ключей

В общем виде пример извлечения закрытого ключа и сертификата открытого ключа из контейнера на токене с помощью КриптоПро Java CSP следующий:

Если действовать так:

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

Результаты

Отторгаемый ключевой носитель-токен установлен во внутренний USB-порт сервера.

Само серверное оборудование опломбировано и размещается в помещении с ограниченным доступом.

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

С другой стороны, можно воспользоваться навесной защитой. Это потребует гораздо меньше времени на реализацию, квалификации разработчика может бть не столь высока (не нужны знание других языков программирования, владение CIL, …). Однако здесь тоже не всё безоблачно, полной автоматизации процесса установки защиты достичь трудно. Сначала мы подробно рассмотрим использование навесной защиты при обычном применении, после чего подумаем, как все это максимально автоматизировать. Предположим, что мы создаем изначально незащищенное приложение, не используя Sentinel LDK API, после чего обработаем сборку при помощи Envelope. Технологический цикл создания защищенного приложения в данном случае будет выглядеть так:
1) Построение незащищенной сборки в среде разработки, например в Visual Studio.
2) Защита построенной сборки в процессе интерактивной работы с Envelope.
Рассмотрим более подробно второй этап и разберемся, какие способы защиты может нам предоставить Envelope. Процесс защиты состоит из следующих операций:
1. Загрузив первый раз Envelope, мы увидим пустой проект. Сразу же укажем, с какой серией ключей будет работать наша защищенная сборка (см. рис. 1):

Рис. 1 – Выбор кода серии ключей

2. Установим общие параметры защиты, которые будут применяться ко всем входящим в проект сборкам, подлежащим защите (см. рис. 2):

Рис. 2 – Установка общих параметров защиты

3. Включим одну или несколько готовых сборок в проект утилиты Envelope (см. рис. 3).

Рис. 3 – Добавление целевых файлов в проект

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

Рис. 4 – Установка параметров сборки

5. При необходимости для каждой конкретной сборки можно установить свои параметры защиты, перекрывающие общие (см. рис. 5), и более тонко настроить работу защитных механизмов (см. рис. 6):

Рис. 5

Рис. 6

Параметры на рис. 5 уже рассматривались в п.2. Из представляющих интерес параметров (с точки зрения защиты) на рис. 6 можно отметить следующие:
• LOCKING_TYPE – определяет типы ключей, с которыми будет работать защита данной сборки. Возможные варианты:

где:
— HL – аппаратный ключ
— SL-UserMode – программный ключ, умеющий работать без драйвера
— SL-AdminMode – программный ключ, работающий совместно с драйвером
— SL – SL-UserMode + SL-AdminMode

• MIN_CODE_SIZE – минимальный размер CIL-кода метода в байтах, начиная с которого он будет защищаться Envelope в случае групповой операции, например, когда для защиты отмечается весь класс целиком.

6. Осталась самая трудоёмкая часть работы – определить классы и методы, подлежащие защите (рис. 7-1), и для каждого выбранного класса/метода задать параметры защитных механизмов (рис. 7-2):

Рис. 7 – Управление защитой методов и классов

Чтобы выбрать для защиты класс или метод, просто поставьте галочку напротив его имени в окне 1. При этом в окне 2 отобразятся текущие параметры защиты для выбранного объекта. Назначение параметров защиты:

• Feature ID – номер лицензии из ключа. Для разных классов/методов может различаться в случае их раздельного лицензирования.
• Frequency – как часто будет проверяться ключ для защищенного класса/метода. Возможные варианты:

где:
— Once per program – один раз за все время работы приложения
— Once per class instance – каждый раз при создании экземпляра класса
— Every time – при каждом проходе управления через защищенный код

• Symbol obfuscation – обфускация символьной информации, может быть применена к методу, даже если он не отмечен, как подлежащий защите, т.к. не связана с ключом. Возможные варианты:

где:
— Use global definition – используется текущее значение параметра Obfuscate Symbols, см. п. 2 и п. 5.
— Enabled – обфускация производится всегда, независимо от глобальных установок.
— Disabled – обфускация никогда не выполняется, независимо от глобальных установок.

• Code obfuscation – control_flow-обфускация CIL-кода, может быть применена к методу, даже если он не отмечен, как подлежащий защите, т.к. не связана с ключом. Так выглядит в IDA фрагмент кода функции после обфускации:

А это – граф передачи управления в функции после обфускации:

Чётко видно, что обфускация заключается в том, что код буквально разрывается по одной инструкции, и все они перемешиваются, а чтобы сохранился прежний порядок их выполнения, после каждой инструкции дополнительно вставляется инструкция перехода (опкод br) на нужный адрес. Очевидно, что скорость работы функции, защищенной таким образом, может сильно упасть, а код – значительно увеличиться в размерах. Поэтому, применять данный метод защиты следует с осторожностью.

• Code encryption – зашифрование CIL-кода выбранного метода через ключ, с использованием алгоритма AES. При этом способе защиты оригинальный CIL-код извлекается из тела метода, зашифровывается через ключ, и помещается в ресурсы сборки в зашифрованном виде. На его место вставляется короткий переходник, обеспечивающий загрузку, расшифрование, динамическую компиляцию и передачу управления на код защищенного метода. После окончания выполнения метода, его код удаляется из памяти. Вот так выглядит фрагмент тела защищенного метода в IDA:

Инструкция call class [mscorlib]System.Reflection.Emit.DynamicMethod определяет и представляет динамический метод, который будет скомпилирован в памяти, выполнен и впоследствии удален. Инструкция callvirt instance object [mscorlib]System.Reflection.MethodBase::Invoke осуществляет передачу управления на метод в случае его успешной компиляции. Данный способ защиты практически не влияет на быстродействие защищаемого кода, обеспечивая вполне приличную стойкость.

7. После того, как все необходимые классы/методы помечены как предназначенные к защите, осталось только сохранить результаты работы в виде файла проекта и нажать кнопку Protect. В результате мы получим защищенную сборку. Конец работы.

Будем использовать утилиту с ключом –p на этапе «событие после построения» в Visual Studio. Можно сделать, например, так:

Работу утилиты можно проверить по логу в окне вывода Visual Studio:

После окончания процесса создания сборки в среде Visual Studio, мы сразу получаем защищенное приложение без лишних телодвижений.
Вроде бы, все получилось неплохо, но как быть, если в исходный код приложения вносятся значительные изменения? Например, если появляются новые классы/методы, подлежащие защите, удаляются старые или планируется изменить способ защиты существующих классов/методов? При традиционном подходе придется открывать проект защиты в Envelope и вносить все накопившиеся изменения, как ранее описывалось в п. 6, что печально, поскольку это ставит крест на автоматизации процесса защиты при любых сколько-нибудь серьёзных изменениях в исходном коде приложения.
Однако, есть возможность автоматизировать актуализацию таких изменений в исходном коде. Сделать это можно посредством использования пользовательских атрибутов в исходном коде приложения. Объектом защиты при помощи пользовательских атрибутов может быть метод, класс или вся сборка — в зависимости от того, где размещается тот или иной набор атрибутов. Список доступных атрибутов для защиты объекта полностью повторяет набор параметров защиты для классов/методов, описанный в п. 6. Вот список доступных атрибутов:
• Protect — тип BOOL, возможные значения — TRUE/FALSE, указывает нужно ли защищать объект с использованием ключа.
• FeatureId — тип int, возможные значения — [0;65535], указывает номер лицензии (Feature ID), которая будет использована при защите объекта. Принимается к исполнению, только если Protect == TRUE.
• Encrypt — тип BOOL, возможные значения — TRUE/FALSE, указывает нужно ли зашифровывать CIL-код объекта. Принимается к исполнению, только если Protect == TRUE.
• CodeObfuscation — тип BOOL, возможные значения — TRUE/FALSE, указывает нужно ли выполнять control_flow-обфускацию CIL-кода объекта. Принимается к исполнению независимо от значения Protect. Данный метод защиты приводит к снижению скорости работы защищенного кода.
• Frequency — перечисляемый тип EnvelopeMethodProtectionFrequency, указывает, как часто будет проверяться лицензия для защищаемого объекта. Принимается к исполнению, только если Protect == TRUE. Возможные значения:
— CheckOncePerApplicaton — однократная проверка в процессе работы приложения.
— CheckOncePerInstance — однократная проверка для каждого экземпляра объекта.
— CheckEveryTime — проверка при каждом проходе управления через код объекта.
• SymbolObfuscation — перечисляемый тип EnvelopeSymbolObfuscation, указывает на метод обфускации символьной информации в защищаемом объекте. Принимается к исполнению независимо от значения Protect. Возможные значения:
— ObfuscateSkip — полный запрет на обфускацию всей символьной информации.
— ObfuscateForce — принудительное выполнение обфускации для всей символьной информации.
— ObfuscateDefault — выполнять обфускацию для всей символьной информации, кроме public-имен, а так же, объектов с модификаторами virtual и protected.

Для того, чтобы Envelope мог получить атрибуты из исходного кода, необходимо при помощи директивы using включить в него пространства имен Aladdin.HASP.Envelope и Aladdin.HASP.EnvelopeRuntime. Естественно, перед этим необходимо добавить файлы Aladdin.HASP.Envelope.DLL и Aladdin.HASP.EnvelopeRuntime.DLL в ссылки проекта Visual Studio. Распространять эти файлы с защищенным приложением не нужно, они требуются только на этапе установки защиты на сборку. Ниже приведен пример защиты из исходного кода с помощью пользовательских атрибутов:

Вообще говоря, все изменения, связанные с защитой сборки можно условно разделить на две категории:
1. Глобальные изменения, которые происходят довольно редко. Описаны в п. 1 – 5, управлять ими из исходного кода нельзя.
2. Изменения в исходном коде, связанные с появлением или удалением классов/методов, подлежащих защите, происходят значительно чаще. Описаны в п. 6. Теперь можно полностью актуализировать такие изменения из исходного кода, не занимаясь правкой проекта защиты в Envelope.

И вот теперь, подытожив все вышеизложенное, можно сказать, что разработчик полностью управляет защитой из исходного кода, также как и в случае использования Sentinel LDK API. Загружать проект защиты в Envelope и исправлять её параметры придется только в случае каких-либо глобальных изменений, например, смены серии ключей, изменения имени сборки или установки другой величины интервала фонового опроса ключа, что происходит несравнимо реже.

Работа с СКЗИ и аппаратными ключевыми носителями в Linux

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

Сегодня я расскажу, как мы защищаем ключи шифрования и электронной подписи в наших информационных системах, и сделаю это в подробном, хорошо проиллюстрированном руководстве по настройке SUSE Linux Enterprise Server 12 SP3 для работы с токеном Aladdin JaCarta PKI и КриптоПро CSP KC2 4.0.9944.

Опубликовать данное руководство побудило несколько причин:

Причина 1

Официальная документация на Aladdin-RD JaCarta больше адаптирована под операционные системы Astra Linux и ALT Linux, сертифицированные в Минобороны, ФСТЭК и ФСБ как средства защиты информации.

Причина 2

Причина 3

UPD 16.04.2019: В процессе настройки среды и оборудования выяснилось, что носитель, первым оказавшийся в распоряжении, был вовсе не JaCarta PKI Nano, как ожидалось, а устройство работающее в режиме SafeNet Authentication Client eToken PRO.

UPD 16.04.2019: Некогда Банку требовалось устройство, которое могло бы работать в той же инфраструктуре, что и eToken PRO (Java). В качестве такого устройства компания “ЗАО Аладдин Р.Д.” предложила токен JaCarta PRO, который был выбран банком. Однако на этапе формирования артикула и отгрузочных документов сотрудником компании была допущена ошибка. Вместо модели JaCarta PRO в артикул и отгрузочные документы случайно вписали JaCarta PKI.

UPD 16.04.2019: Благодарю компанию Аладдин Р.Д., за то что помогли разобраться и установить истину.

В этой ошибке нет никаких политических и скрытых смыслов, а только техническая ошибка сотрудника при подготовке документов. Токен JaCarta PRO является продуктом компании ЗАО “Аладдин Р.Д.”. Апплет, выполняющий функциональную часть, разработан компанией “ЗАО Аладдин Р.Д”.

Этот eToken PRO относился к партии, выпущенной до 1 декабря 2017 года.
После этой даты компания «Аладдин Р.Д.» прекратила продажу устройств eToken PRO (Java).

Забегая немного вперед, нужно сказать, что работа с ним настраивалась через соответствующие драйверы — SafenetAuthenticationClient-10.0.32-0.x86_64, которые можно получить только в поддержке Аладдин Р.Д. по отдельной online заявке.

В КриптоПро CSP для работы с этим токеном требовалось установить пакет cprocsp-rdr-emv-64 | EMV/Gemalto support module.

Данный токен определялся и откликался. При помощи утилиты SACTools из пакета SafenetAuthenticationClient можно было выполнить его инициализацию. Но при работе с СКЗИ он вел себя крайне странно и непредсказуемо.

Проявлялось это следующим образом, на команду:

Выдавался ответ, что все хорошо:

Но сразу после попытки зачитать ключи программно эта же проверка начинала выдавать ошибку:

Согласно перечню кодов ошибок объектной модели компонентов Microsoft COM Error Codes (Security and Setup)

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

Справедливости ради требуется отметить, что SafeNet eToken PRO корректно работал с ключами ГОСТ Р 34.10-2001 в ОС Windows 7 и 10.

Можно было бы попробовать установить СКЗИ КриптоПро CSP 4.0 ФКН (Gemalto), но целевая задача — защитить наши ключи ЭП и шифрования с помощью сертифицированных ФСБ и ФСТЭК изделий семейства JaCarta, в которых поддерживаются новые стандарты.

Проблему удалось решить, взяв настоящий токен JaCarta PKI в (XL) обычном корпусе.

Но на попытки заставить работать Safenet eToken PRO времени было потрачено немало. Хотелось обратить на это внимание и, возможно, кого-то оградить от подобного.

Причина 4

Иногда самому требуется вернуться к старым статьям и инструкциям. Это удобно, когда информация размещена во внешнем источнике. Так что спасибо Хабру за предоставленную возможность.

Читайте также: