Jump to content
skysilver

Ошибка 58 При Выполнении Инициализации (Неправильный Ключ)

Recommended Posts

Доброго времени суток!

Возвращаюсь к проблеме, возникающей в ходе первичной инициализации клиента. Злополучная ошибка 58! ))

Слишком уж часто она стала меня преследовать в последнее время. Надо как-то решать вопрос. Помогайте, коллеги.

Вводная следующая.

Имеем ViPNet Administrator 3.2(9.11881) KC3 (Windows XP SP3). Работает без нареканий, ничего подозрительного за ним не замечал. Два ПАКа Coordinator HW1000G2 в кластере (версию точно не помню, при необходимости уточню) работают круглые сутки, проблем с ними нет. Ну и многострадальные клиенты ViPNet Client 3.1(1.6238) KC3. Большинство клиентов - удаленные пользователи.

На клиентских машинах повсеместно ОС Windows 7 Pro x32 (бывают и х64), установленные с нуля. На каждом сетевом узле регистрируется по два пользователя с правом подписи, полномочия у всех минимальные. Каждому присваивается свой ruToken32 S. При копировании dst-файлов из УКЦ в качестве контейнера ключей шифрования, сертификата и закрытого ключа сертификата указывается токен, авторизация соответственно "Устройство". Контейнеры на токене создаются без ошибок, dst-файлы копируются как положено. Сам клиент устанавливается без проблем (на всякий случай добавлен в исключения антивируса). А вот инициализация заканчивается ошибкой.

Если теми же токенами и dst-файлами проинициализировать ViPNet Client 3.2(9.11495), то все гладко и превосходно. Также выявил интересный момент - если при копировании дистрибутивов из УКЦ не использовать токены и использовать авторизацию по паролю, то инициализация пролетает без ошибок и все работает корректно.

Вроде бы, вот оно решение! Но, увы нам оно не подходит. Версия 3.2 не подходит категорически, т.к. не сертифицирована ни ФСТЭК, ни ФСБ. Тем более, что дистрибутива клиента 3.2 на класс КС3 в природе нет (так сказали в тех. поддержке). А использовать авторизацию по паролю и, главное, хранить ключи шифрования и закрытый ключ подписи в каталоге на HDD не позволяет модель угроз и политика безопасности. ((

Как быть, коллеги? Куда копать? Проблема катастрофически актуальная.

P.S.: в тех. поддержку обращался, тикет завели, внятного ничего не сказали.

Share this post


Link to post
Share on other sites

Доброго времени суток!

Возвращаюсь к проблеме, возникающей в ходе первичной инициализации клиента. Злополучная ошибка 58! ))

Слишком уж часто она стала меня преследовать в последнее время. Надо как-то решать вопрос. Помогайте, коллеги.

Вводная следующая.

Имеем ViPNet Administrator 3.2(9.11881) KC3 (Windows XP SP3). Работает без нареканий, ничего подозрительного за ним не замечал. Два ПАКа Coordinator HW1000G2 в кластере (версию точно не помню, при необходимости уточню) работают круглые сутки, проблем с ними нет. Ну и многострадальные клиенты ViPNet Client 3.1(1.6238) KC3. Большинство клиентов - удаленные пользователи.

На клиентских машинах повсеместно ОС Windows 7 Pro x32 (бывают и х64), установленные с нуля. На каждом сетевом узле регистрируется по два пользователя с правом подписи, полномочия у всех минимальные. Каждому присваивается свой ruToken32 S. При копировании dst-файлов из УКЦ в качестве контейнера ключей шифрования, сертификата и закрытого ключа сертификата указывается токен, авторизация соответственно "Устройство". Контейнеры на токене создаются без ошибок, dst-файлы копируются как положено. Сам клиент устанавливается без проблем (на всякий случай добавлен в исключения антивируса). А вот инициализация заканчивается ошибкой.

Если теми же токенами и dst-файлами проинициализировать ViPNet Client 3.2(9.11495), то все гладко и превосходно. Также выявил интересный момент - если при копировании дистрибутивов из УКЦ не использовать токены и использовать авторизацию по паролю, то инициализация пролетает без ошибок и все работает корректно.

Вроде бы, вот оно решение! Но, увы нам оно не подходит. Версия 3.2 не подходит категорически, т.к. не сертифицирована ни ФСТЭК, ни ФСБ. Тем более, что дистрибутива клиента 3.2 на класс КС3 в природе нет (так сказали в тех. поддержке). А использовать авторизацию по паролю и, главное, хранить ключи шифрования и закрытый ключ подписи в каталоге на HDD не позволяет модель угроз и политика безопасности. ((

Как быть, коллеги? Куда копать? Проблема катастрофически актуальная.

P.S.: в тех. поддержку обращался, тикет завели, внятного ничего не сказали.

А кто мешает создавать DST файлы с закрытым ключём ЭП и личными ключами?! А после инициализации ключи перенести на токен. Правда, для этого потребуется временное повышение полномочий, так как с минимальными полномочиями пользователь этого сделать не сможет. В качестве альтернативы можно просто сделать им временный пароль администратора сетевого узла, который следует менять сразу после инициализации. Регламент безопасности это не возбраняет. Хотя, стоит перечитать его ещё разок.

Share this post


Link to post
Share on other sites

А кто мешает создавать DST файлы с закрытым ключём ЭП и личными ключами?! А после инициализации ключи перенести на токен. Правда, для этого потребуется временное повышение полномочий, так как с минимальными полномочиями пользователь этого сделать не сможет. В качестве альтернативы можно просто сделать им временный пароль администратора сетевого узла, который следует менять сразу после инициализации. Регламент безопасности это не возбраняет. Хотя, стоит перечитать его ещё разок.

Я прорабатывал такой сценарий. Результат, увы не самый оптимистичный. После переноса ключевой информации пользователей на их персональные токены до перезагрузки ОС клиент работает корректно, а пользователи сменяются между собой без проблем. Но вот после перезагрузки не удается авторизоваться в клиенте - ошибка "Не найден ключевой диск". Если в окне авторизации вручную указывать каталог ключей пользователя, то снова "Не найден ключевой диск". Причем по-умолчанию в качестве каталога ключей пользователя почему-то стоит папка System32. Откуда он ее вообще взял такую? ))

В целом же хочется избежать ручного переноса ключей на токен на каждом клиенте, потому что удаленные пользователи не будут с этим заморачиваться и будут хранить все ключи на HDD, а авторизоваться по паролю. Им так проще. А с учетом того, что они и орг. мероприятия толком не выполняют, и режим в здании не могут обеспечить, то это дело принимает совсем печальный оборот. А мне удаленно это никак не проконтролировать. Кататься самому тоже не вариант - целая область как никак. А ФСБ при первой проверке такое предписание накатает, что мало не покажется.

Я, ведь, не хочу ничего сверхъестественного от ViPNet`a. Только его штатные функции, все согласно документации. Только вот продукт свои заявленные функции почему-то не выполняет.

Какие будут соображения, коллеги? Как выходить из ситуации?

Share this post


Link to post
Share on other sites

Я прорабатывал такой сценарий. Результат, увы не самый оптимистичный. После переноса ключевой информации пользователей на их персональные токены до перезагрузки ОС клиент работает корректно, а пользователи сменяются между собой без проблем. Но вот после перезагрузки не удается авторизоваться в клиенте - ошибка "Не найден ключевой диск". Если в окне авторизации вручную указывать каталог ключей пользователя, то снова "Не найден ключевой диск". Причем по-умолчанию в качестве каталога ключей пользователя почему-то стоит папка System32. Откуда он ее вообще взял такую? ))

В целом же хочется избежать ручного переноса ключей на токен на каждом клиенте, потому что удаленные пользователи не будут с этим заморачиваться и будут хранить все ключи на HDD, а авторизоваться по паролю. Им так проще. А с учетом того, что они и орг. мероприятия толком не выполняют, и режим в здании не могут обеспечить, то это дело принимает совсем печальный оборот. А мне удаленно это никак не проконтролировать. Кататься самому тоже не вариант - целая область как никак. А ФСБ при первой проверке такое предписание накатает, что мало не покажется.

Я, ведь, не хочу ничего сверхъестественного от ViPNet`a. Только его штатные функции, все согласно документации. Только вот продукт свои заявленные функции почему-то не выполняет.

Какие будут соображения, коллеги? Как выходить из ситуации?

К сожалению, сертифицированные версии выходят довольно сырые, со многим приходится мириться. Давайте попробуем разобраться. Что у Вас ещё на компьютере стоит? Какое-то средство защиты от НСД? Или что-то подобное?

Share this post


Link to post
Share on other sites

К сожалению, сертифицированные версии выходят довольно сырые, со многим приходится мириться. Давайте попробуем разобраться. Что у Вас ещё на компьютере стоит? Какое-то средство защиты от НСД? Или что-то подобное?

Рабочий АРМ на базе ОС Windows 7 Pro x32, MS Office 2010 Pro, Adobe Acrobat 8.0, системные драйвера устройств и драйвера ruToken (v.2.85.00.0453). Из прикладного и системного ПО больше нет ничего.

По СЗИ имеем следующее - Антивирус Касперского 6.0 WS (либо Dr. Web Enterprise Suite 6.0), СЗИ от НСД "Secret Net 6.5 К" (автономный вариант), ПАК "Соболь 3.0" (PCI-E) в совместном режиме с Secret Net. Все СЗИ настроены на авторизацию по устройству. Пользователь вводит только PIN от токена. Касательно антивируса - встроенный компонент МЭ отключен на этапе установки.

Share this post


Link to post
Share on other sites

Рабочий АРМ на базе ОС Windows 7 Pro x32, MS Office 2010 Pro, Adobe Acrobat 8.0, системные драйвера устройств и драйвера ruToken (v.2.85.00.0453). Из прикладного и системного ПО больше нет ничего.

По СЗИ имеем следующее - Антивирус Касперского 6.0 WS (либо Dr. Web Enterprise Suite 6.0), СЗИ от НСД "Secret Net 6.5 К" (автономный вариант), ПАК "Соболь 3.0" (PCI-E) в совместном режиме с Secret Net. Все СЗИ настроены на авторизацию по устройству. Пользователь вводит только PIN от токена. Касательно антивируса - встроенный компонент МЭ отключен на этапе установки.

Теоретически возможен конфликт с SecretNet, хотя с ним VipNet не сращивал ни разу. Работал, в основном, с СЗИ от НСД "Аура". Там проблемы иногда бывали следующего характера: из-за того, что Аура постоянно мониторила токен, чтобы по его отключению заблокировать компьютер, то доступа к токену иногда випнет не получал. Проблема решалась выниманием и вставкой токена. Может, попробовать данную функцию на "чистом" компьютере, чтобы иключить глюки vipnet?! Может, здесь тоже происходит какая-нибудь блокировка СЗИ?! Какая именно сложно сказать. Обычно в журнале СЗИ по таким проблемам бывает полезная информация.

Кстати, и подобная ситуация была. В некоторых инсталляциях при установке КриптоПро драйвер RuTokenа падал при входе в систему и не давал авторизоваться по токену (естественно, в связке с СЗИ от НСД).

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Номер обращение в техподдержку скиньте. Можно в личку. Попытаемся разобраться, кто там "невнятное" ответил.

Share this post


Link to post
Share on other sites

Номер обращение в техподдержку скиньте. Можно в личку. Попытаемся разобраться, кто там "невнятное" ответил.

Запрос № 001-00-131736. Сегодня получил от них еще одно сообщение. Проблему признали. Как говорят, виноват целиком и полностью ViPNet Client. Путей решения проблемы не предложили вообще никаких. Если, конечно, не считать решением обещание сертифицированного по КС3 клиента в январе 2013. ))

Share this post


Link to post
Share on other sites

Запрос № 001-00-131736. Сегодня получил от них еще одно сообщение. Проблему признали. Как говорят, виноват целиком и полностью ViPNet Client. Путей решения проблемы не предложили вообще никаких. Если, конечно, не считать решением обещание сертифицированного по КС3 клиента в январе 2013. ))

Естественно. Доработки в сертифицированный продукт нельзя вносить без пересертификации. Поэтому патчи не котируются. Хотя некоторые лицензиаты, которые внедряют VipNet, думают иначе. Сам жду сертифицированного клиента КС2 к началу следующего года, а то эта сертифицированная версия неудачной получилась.

Share this post


Link to post
Share on other sites

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

Сегодня на двух компах откатал сценарий с "ручным" переносом ключей и контейнеров на токен под правами администратора сетевого узла.

В УКЦ изначально создал DST-файлы без использования токенов. При таком раскладе первичная инициализация прошла успешно. Проверил авторизацию пользователей по паролю - все хорошо, в т.ч. после перезагрузки. Затем перенес ключи шифрования и контейнер закрытого ключа с сертификатом одного пользователя на токен, проверил авторизацию после перезагрузки - ошибок нет. Повторил все тоже самое для второго пользователя, перезагрузился, авторизовался успешно. В итоге получил рабочую станцию. Ошибка, описанная мною в посте №3, в этот раз не возникла, т. к. на токенах не было никаких контейнеров от предыдущей неудачной инициализации.

Т.е. по сути сам ViPNet Client не конфликтует с установленными СЗИ и с токенами работает корректно. А вот мастер первичной инициализации не может отработать до конца при использовании токенов.

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

By using this site, you agree to our Terms of Use.