Jump to content

Recommended Posts

Подключенные устройства.....

ruToken

Контейнер

sgn_cont

___________________________

Контейнер переключений подписи

Имя контейнера ХХХХ ХХХ ХХХ

Тип носителя Устройство

___________________________

Ключевой носитель ruToken

При попытке войти под устройством в Монитор выдает ошибку "Ошибка Инициализации"

Кто нибудь - имел дело с данным способом авторизации. Подскажите пожалуйста?

Самое интересное что с eToken - получалось.

Share this post


Link to post
Share on other sites

Этого контейнера недостаточно, чтобы зайти по устройству. Должен быть ещё контейнер cur_pers. Его также необходимо перенести.

Share this post


Link to post
Share on other sites

У нас в Казахстане распространен KazToken (казахстанский аналог ruToken, на том же микроконтроллере, но со своей немного измененной внутренней прошивкой).

Из УКЦ при переносе дистрибутивов я переношу на KazToken только ключ защиты (cur_pers), а ключ подписи (sgn_cont) оставляю в составе dst-файла.

Это особенность этого токена, т.к. асимметричные приватные ключи подписи не могут быть записаны на него извне и не могут извлекаться из него.

Первичную инициализацию Клиента делаю этим dst и указываю, что имеется токен с ключами защиты. Ключ подписи можно потом заново запросить с Клиента, при этом с помощью аппаратного ГСЧ токена создастся и сохранится на токене приватный ключ подписи и полученный от УКЦ сертификат также сохранится на токене. В качестве действующего выбираю этот новый сертификат.

Всё нормально работает.

Никаких ошибок не замечал.

Распишите свой порядок подготовки такой авторизации, начиная с выпуска dst в УКЦ.

Share this post


Link to post
Share on other sites

Неважно на каком этапе это делать. Можно уже с готового DST переносить из клиента оба контейнера через вкладку "ключи" настроек параметров безопасности. А в УКЦ можно указать сразу авторизацию по устройству и ключ подписи на устройстве. В этом случае DST будет сразу без этих контейнеров.

Share this post


Link to post
Share on other sites

На Rutoken S можно переносить оба ключевых контейнера, а на Rutoken ЭЦП только контейнер ключа защиты.

Это написано в Руководстве администратора УКЦ.

Share this post


Link to post
Share on other sites

Возможно Вы и правы, но я не сталкивался. В документации к УКЦ не нашёл. С RuToken ЭЦП не работал. У нас, в основном, Rutoken S используется.

Share this post


Link to post
Share on other sites

В доках к версии 3.2.9 и 3.2.10 это в админ-гайде к УКЦ написано и в пользовательском гайте на Клиент Monitor. А в прошлых версиях вроде отдельный документ был "External_Devices_Guide_Ru.pdf".

Но не в этом суть.

У инициатора темы проблема похоже с контейнером ключей защиты.

Можно просто воткнуть этот токен на комп с запущенным ViPNet Клиентом и с установленными для токена драйверами, и через "Сервис - Настройка параметров безопасности - Устройства" посмотреть какие випнетовские контейнеры на нем имеются.

Share this post


Link to post
Share on other sites

Возможно. Но нужно подождать что скажет вопрошающий. Хотя, он уже сказал что именно лежит на токене.

Share this post


Link to post
Share on other sites

Этого контейнера недостаточно, чтобы зайти по устройству. Должен быть ещё контейнер cur_pers. Его также необходимо перенести.

С проблемой разобрался. Камрад ты не прав - контейнер должен быть один sgn_cont. И не иначе. Для инициализации необходим passw - Это все должно быть на ключе - вот и все. Можно и без контейнеров - ключи все равно будут на ключе. Главное в другом - в описаниях "мануалах" не все дописано - на то оно и "мануал" - главное думать - а еще главнее если чего то нет в "мануалах" - это интуиция если ее нет то Камрады смерть не минуема :)!

Share this post


Link to post
Share on other sites

У нас в Казахстане распространен KazToken (казахстанский аналог ruToken, на том же микроконтроллере, но со своей немного измененной внутренней прошивкой).

Из УКЦ при переносе дистрибутивов я переношу на KazToken только ключ защиты (cur_pers), а ключ подписи (sgn_cont) оставляю в составе dst-файла.

Это особенность этого токена, т.к. асимметричные приватные ключи подписи не могут быть записаны на него извне и не могут извлекаться из него.

Первичную инициализацию Клиента делаю этим dst и указываю, что имеется токен с ключами защиты. Ключ подписи можно потом заново запросить с Клиента, при этом с помощью аппаратного ГСЧ токена создастся и сохранится на токене приватный ключ подписи и полученный от УКЦ сертификат также сохранится на токене. В качестве действующего выбираю этот новый сертификат.

Всё нормально работает.

Никаких ошибок не замечал.

Распишите свой порядок подготовки такой авторизации, начиная с выпуска dst в УКЦ.

В вашем случае Камрад все здорово. ruToken можно использовать и в начале первичной инициализации указать место хранения ключей, но так как не проведена инициализация то авторизоваться не получится, а вот после достаточно инициализировать добавлением на ключ passw и все поехали. Там будет и сертификат и все прочее. Но под строкой "Контейнеры ключей на устройстве" в моем случае присутствуют только, - sgn_cont,passw. Надо понимать следующее я описываю только свой VipNet. У вас может другой? Тогда - вот это поворот" Как сказал "Мэтр".

Share this post


Link to post
Share on other sites

Неважно на каком этапе это делать. Можно уже с готового DST переносить из клиента оба контейнера через вкладку "ключи" настроек параметров безопасности. А в УКЦ можно указать сразу авторизацию по устройству и ключ подписи на устройстве. В этом случае DST будет сразу без этих контейнеров.

Можно но лучше не надо - так как надо сразу подумать - по журналу то что вы будете передовать администратору безопасности? Это знаете ли вопрос уже больше основывающийся на приказах и всем таком - чем регулируется деятельность шифрооргана так и записывать и передовать. В данном случае камрад вопрос о последующей эксплуатации - передачу ужо миновали будем считать - теперь вот был вопрос не только подпись - но и блокирнуть АРМ - на случай работы за ним не желательных лиц - ну и вообще контроль чтобы был. Опять же все в соответствии с нормативной базой применяемой к средствам Вычислительной Техники.

Share this post


Link to post
Share on other sites

На Rutoken S можно переносить оба ключевых контейнера, а на Rutoken ЭЦП только контейнер ключа защиты.

Это написано в Руководстве администратора УКЦ.

Скорее всего!

Share this post


Link to post
Share on other sites

Возможно Вы и правы, но я не сталкивался. В документации к УКЦ не нашёл. С RuToken ЭЦП не работал. У нас, в основном, Rutoken S используется.

У нас тоже S.

Share this post


Link to post
Share on other sites

В доках к версии 3.2.9 и 3.2.10 это в админ-гайде к УКЦ написано и в пользовательском гайте на Клиент Monitor. А в прошлых версиях вроде отдельный документ был "External_Devices_Guide_Ru.pdf".

Но не в этом суть.

У инициатора темы проблема похоже с контейнером ключей защиты.

Можно просто воткнуть этот токен на комп с запущенным ViPNet Клиентом и с установленными для токена драйверами, и через "Сервис - Настройка параметров безопасности - Устройства" посмотреть какие випнетовские контейнеры на нем имеются.

Это в том случае если они есть - эти самые контейнеры. При перво-начальном переносе они конечно же перенесутся. Даже если вы их удалите они все равно там будут самое интересное, VipnetMonitor помнит что там они есть скажем так "коряво" даже форматунув ключик - АРМ все равно блокируется, то есть если извлечь ключ то все блокернется и все такое. Но как только вы пере загрузитесь - войти нужно будет только под паролем.

Share this post


Link to post
Share on other sites

С проблемой разобрался. Камрад ты не прав - контейнер должен быть один sgn_cont. И не иначе. Для инициализации необходим passw - Это все должно быть на ключе - вот и все. Можно и без контейнеров - ключи все равно будут на ключе. Главное в другом - в описаниях "мануалах" не все дописано - на то оно и "мануал" - главное думать - а еще главнее если чего то нет в "мануалах" - это интуиция если ее нет то Камрады смерть не минуема :)!

Вот по поводу passw Вы не правы. Этого для авторизации хватит, но персональные ключи пользователя будут храниться на жёстком диске компьютера. Если вы не используете дополнительные носители, то вы обязаны (согласно регламенту безопасности, в случае защиты, к примеру, персональных данных) хранить cur_pers на токене, а не passw (что представляет соболь лишь пароль к ключам). Так что, контейнера должно быть два.

Share this post


Link to post
Share on other sites

Вот по поводу passw Вы не правы. Этого для авторизации хватит, но персональные ключи пользователя будут храниться на жёстком диске компьютера. Если вы не используете дополнительные носители, то вы обязаны (согласно регламенту безопасности, в случае защиты, к примеру, персональных данных) хранить cur_pers на токене, а не passw (что представляет соболь лишь пароль к ключам). Так что, контейнера должно быть два.

Дык Камрад яж не Юзаю соболь я это все применяю непосредственно к VipNet. Ключик изъял и комп просит тремя пальцами нажать - ну а там естественно и пароль Юзера. Блокируется так же как будто стражевский ключь изъял. Ну контейнеров конеш я могу залить два - а вот что система сама делает дак ей видней то есть переносит сама то что нужно.

Share this post


Link to post
Share on other sites

В вашем случае Камрад все здорово. ruToken можно использовать и в начале первичной инициализации указать место хранения ключей, но так как не проведена инициализация то авторизоваться не получится, а вот после достаточно инициализировать добавлением на ключ passw и все поехали. Там будет и сертификат и все прочее. Но под строкой "Контейнеры ключей на устройстве" в моем случае присутствуют только, - sgn_cont,passw. Надо понимать следующее я описываю только свой VipNet. У вас может другой? Тогда - вот это поворот" Как сказал "Мэтр".

sgn_cont,passw

Вы наверное используете метод аутентификации ViPNet "Пароль на устройстве"? Когда на токене хранится парольный ключ (хэш пароля) пользователя, на котором зашифрованы ключи защиты пользователя (cur_pers).

Инфотекс его поддерживает, но не рекомендует:

Внимание! Использовать способ аутентификации "Пароль на устройстве" для входа в ПО ViPNet Монитор крайне не рекомендуется. Данный способ аутентификации предназначен для устройств устаревшего типа, в последующих версиях ПО ViPNet Монитор его поддержка будет прекращена. Рекомендуется использовать более надежный и безопасный способ аутентификации "Устройство".

А я описывал метод аутентификации "Устройство", когда и ключ защиты и ключ подписи на токене лежат. Именно он и рекомендуется для токенов.

А ViPNet у нас в Казахстане такой же как и у вас :) ... имеется в виду ПО, получаемое официально от Инфотекса....

Сами делаем только программно-аппаратные комплексы ViPNet Coordinator (по аналогии с российскими HW1000, HW100)... на основе ViPNet Coordinator Linux, собственной сборки линукса и собственного командного интерпретатора.

Share this post


Link to post
Share on other sites

Дык Камрад яж не Юзаю соболь я это все применяю непосредственно к VipNet. Ключик изъял и комп просит тремя пальцами нажать - ну а там естественно и пароль Юзера. Блокируется так же как будто стражевский ключь изъял. Ну контейнеров конеш я могу залить два - а вот что система сама делает дак ей видней то есть переносит сама то что нужно.

Сторонние системы (в том числе соболь и страж) тут непричём. Я только лишь в том, что ключи должны храниться на отчуждаемом носителе (в том числе и персональные ключи). Речь не о блокировке, а о корректном использовании ключевой информации на токене.

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
Sign in to follow this  

×

Important Information

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