Спецы Подскажите О Переносе На Rutoken

[Андрей - Иркутскъ]

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

ruToken

Контейнер

sgn_cont

___________________________

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

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

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

___________________________

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

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

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

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

[slavanchuk]

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

[ingenico]

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

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

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

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

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

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

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

[slavanchuk]

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

[ingenico]

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

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

[slavanchuk]

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

[ingenico]

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

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

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

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

[slavanchuk]

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

[Андрей - Иркутскъ]

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

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

[Андрей - Иркутскъ]

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

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

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

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

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

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

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

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

[Андрей - Иркутскъ]

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

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

[Андрей - Иркутскъ]

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

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

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

[Андрей - Иркутскъ]

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

У нас тоже S.

[Андрей - Иркутскъ]

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

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

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

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

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

[Андрей - Иркутскъ]

Камрады Всех благодарю за помощь.

[slavanchuk]

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

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

[Андрей - Иркутскъ]

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

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

[ingenico]

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

sgn_cont,passw

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

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

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

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

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

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

[slavanchuk]

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

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