Использование АПМДЗ для СКЗИ — пережиток прошлого. В настоящее время эти устройства создают больше проблем, чем обеспечивают безопасность.
Рассмотрим типовой функционал АПМДЗ
1. Про функционал генератора случайных чисел писал — это ок.
2. Контроль целостности. Да АПМДЗ контролирует целостность файлов, хорошо ли плохо вопрос немного другой, но контролирует он ее только в момент перезагрузки системы. А как часто у вас перезагружаются prod. сервера?
То есть пратическая ценность этого функционала близка к 0.
3. Позволяют блокировать загрузку со съемных носителей (CD, floppy,...). Опять таки, как часто перезагружается сервер?
4. Позволяют осуществлять аутентификацию пользователей в момент загрузки по идентификаторам. Опять момент загрузки.
5. АПДМЗ по документации должны подключаться в разъем Reset на мат. плате компа. Много у серверов разъемов Reset?
6. АПМДЗ могут хранить ключи шифрования. Возможно это и будет удобно, но есть другие хранилища — токены, которые не хуже.
Недостатки:
1. Применение BMC, таких как ILO, IPMI с АПМДЗ неоднозначно.
2. Чистый АПМДЗ легко обойти, достаточно вынуть девайс из компа. Исключение составляют замки с шифраторами от АНКАД, но они настояльно дорогие, что мне ни разу не удалось убедить из купить.
Резюме. АПМДЗ создавались во времена DOS. Тогда их функционал нес практическую ценность. Сейчас нужны другие системы.
Удостоверяющий центр Федерального казначейства ведет прием документов на изготовление ключей. Подходит дедушка, приносит документы и флешку.
Оператор УЦ смотрит флешку и говорит, у вас вместо запросов на сертификат на флешки лежат закрытые ключи.
Дед — А какая разница?
Да и не думаю, что из-за ключа стоимость от 2 до 5 тыс. руб., кто-то будет снимать электромагнитные наводки для выемки ключей из токена!!!
Я бы не был столь категоричен. Все завист от стоимости данных, которые защищены ключом. Например, если ключ от корр. счета Банка, на котором лежит несколько ярдов, то стоимость перехвата в данном случает будет зависит от стоимости приемника.
Широкополосник Rohde & Schwarz, который будет уметь такое стоил порядка 0,5 млн евров. Самопал на USRP существенно дешевле.
В точку, но это прописано, в документации по СКЗИ, сертифицированной по КС2.
Из полезных свойств аппаратного модуля довереной загрузки (АМДЗ) в данном случае является только генератор случайных чисел, все остальное очень натянуто и не выдерживает критики.
1) На текущий момент Криптопровайдер Vipnet CSP не может работать с подписью КриптоПРО CSP и наоборот — разный контейнеры закрытого ключа
Уточним. VIPNET CSP не может работать с ключевыми контейнерами сформированными КриптоПРО CSP, Но вы без проблем можете подписать запрос на сертификат сгенерированный из VIPNET CSP с помощью УЦ работающего на КриптоПРО CSP.
Поэтому тут вопрос скорее к Росстандарту и ФСБ России о том, что необходимо стандартизировать формат ключвых контейнеров.
2) реализовать через них TLS можно, но в достаточной степени геморройно,
Я бы сказал тут дело привычки. Поднять TLS на IIS+КриптоПРО CSP (серверный вариант) у меня занимало порядка 2-3 минут. Под *nix было сложнее.
В остальном согласен, за исключением цены — «Лицензия на право использования СКЗИ „КриптоПро CSP“ версии 3.9 на сервере 30 000,00р.», но тоже дороговато.
Проблема наших СКЗИ в том, что их преимущества для пользователей не очевидны.
По криптографии (взлом криптоалгоритма, баги криптосхем и т.д.) информационные системы ломают крайне редко, поэтому для обычного пользователя что отечественная библиотека СКЗИ, что импортная обеспечивают сравнимый уровень защиты, но в тоже время отечественные системы стоят денег, и порой довольно больших.
Более того, сама система использования отечественных СКЗИ — сертификация, реализация требований документации, и нормативки, например ФАПСИ 152 превращает все это просто в кошмар.
Игра с «экспортируемым» и «не экспортируемым» ключом справедлива практически для любых криптопровайдеров, что наших, что импортных. Можете ее легко повторить на чистой Windows.
Токены не являются чисто российским изобретением и применяются в том числе и за бугром. Более того и наши и импортные токены реализуют один стандарт — ISO/IEC 7816 + вариации, поэтому утверждать что наши токены хуже, не совсем корректно.
Ключ изначально созданный как «не экспортируемый» штатными средствами СКЗИ скопировать не получится. Но это не отменяет возможность применения других методов (см. комменты выше).
Только вот покупать токен, который позиционируется как токен с не извлекаемым ключом для этих целей (простановки галки «не экспортируемый» не нужно. Ровно тот же функционал вы получите не обычных токенах, которые стоят уверено дешевле.
Поясню. Вы взяли обычную флешку за 300 рублей, начали сгенерировали на ней ключ, поставили галку «не экспортируемый». Все, штатными средствами скопировать нельзя. Но не кто не отменял «Проводник Windows».
В случае токенов ситуация точно такая же.
Но если хочется чтоб ключ действительно нельзя было скопировать, то нужно использовать тот софт и те токены, что описаны в конце статьи, а не тот, что обычно втюхивают продавцы.
… все будет работать, имхо, через openssl+токен напрямую
А в чем координальное отличие? Вместо CSP будет требоваться OpenSSL, один cliet-side софт меняется на другой.
Утверждать что OpenSSL более безопасный чем тот же КриптоПРО CSP считаю не корректным. Надо сравнивать по моделям угроз и ТЗ систем для которых применяется СКЗИ.
В тоже время если вопрос в деньгах, то можно использовать бесплатный криптопровайдер VIPNET CSP или бесплатную версию КриптоПРО CSP (она становится таковой, когда заканчивается триал) правда у нее нет возможности формировать ЭП, можно только проверять.
Цель статьи как раз и было показать, что то ПО которое обычно продает УЦ не позволяет достичь тех характеристик, которые работники УЦ заявляют при продаже.
Отмечу, что рассматривается ситуация, когда нарушителю известны пароли и другая аутентификационная информация (например, брелки iButton и др.) используемая для защиты ключей от НСД.
На текущий момент, подобную защиту вы сможете обеспечить только если применяется честная схема с ФКН и (или) применяются HSM.
В типовой конфигурации УЦ используют следующие ключи:
1. Ключ самого УЦ или как он раньше назывался ключ уполномоченного лица удостоверяющего центра.
В типовом случае хранится в реестре CA (ФСБ в тоже время требует, чтобы использовался отчуждаемый носитель), для защиты применяют АПМДЗ Соболь или Аккорд. По хорошему должен хранится в HSM. Копирование ключа (если не используется HSM) возможно следующими способами:
— при наличии аутентификационной информации (паролей, идентификаторов iButton и др.) штатными средствами СКЗИ;
— при доступе к резервных копиям УЦ.
— из оперативной памяти, при наличии возможности запуска кода с правами Local System;
— из файла подкачки.
— при совершении сервисного обслуживания техники.
Если ключ хранится на отчуждаемом носителе (не ФКН) в сервной, то копирование возможно способами как указано далее.
2. Ключи авторизации работников УЦ. Данные ключи используются для авторизации персонала при осуществлении доступа к критически важным функциям таким как выпуск сертификата, заведение нового пользователя, отзыв сертификата, выпуск CRL и т.д. Как правильно данные ключи хранятся на «обычных» токенах, защищенных паролем + используется СКЗИ, от производителя УЦ.
Скопировать возможно следующими способами:
1. Штатными средствами СКЗИ (при наличии паролей от токенов)
2. Путем предвартиельного получения пароля от токена: соц. инжинирия, трояны.
3. Путем перехвата ключа в канале связи между компом и токеном: usbCAP, трояны
3. Инфраструктуре ключи, например ключи для организации TLS до Web-интефрейса УЦ. Обычно хранятся в реестре или в файлах. Способы копирования перечислены выше.
4. Ключи пользователей УЦ. Здесь я надеюсь, что у вас хранятся только открытые ключи. Хранение закрытых ключей на стороне УЦ дискредитирует всю схему PKI.
Ну и наконец универсальный способ (без принятия мер защиты) копирования любых ключей — side channel атаки, включая применение СТС (специальных технических средств негласного съема информации) и всеми горячо нелюбимый ПЭМИН.
Поэтому утверждение что в вашем УЦ нельзя скопировать ключи — довольно смелое :), корректней было бы сказать, что злоумышленник обладающий суммой X-рублей не сможет скопировать у вас ключи.
P.S. Кроме это по мимо ключей УЦ вы наверняка еще пользутесь услугами дистанционного банковского обслуживания Интернет Клиент-Банк, а это отдельная песня.
Скопировать ключи можно не с любых токенов, но довольно с многих.
Галкой «неизвлекамый» — вы наварено называете «не экспортируемый». Стоит отметить, что наличие данной галки — обрабатывается только СКЗИ. А это значит, что если ключевая информация доступна в обход СКЗИ (например, ключ хранятся на флешке или в реестре), то она может быть успешно скопирована не смотря на галку.
Таким образом, ответить на ваш вопрос о возможности копирования ключей, для которых стоит галка «не экспортируемый» можно следующим образом:
— Если к ключевой информации можно обратится в обход СКЗИ, то не смотря на эту галку их скопировать можно.
Применительно к токенам обходные маневры расписаны в статье
УЦ по распределенной схеме галки не ставит вообще никакие, так ключевую пару генерирует пользователь.
А по централизованной схеме, кто во что горазд.
У меня лично был опыт, когда при генерации ключа для ДБО ИКБ меня пустили за компьютер офицера безопасности Банка, ответственного за генерацию ключей, хотя в Банке я был впервые. Поэтому утверждать, что там делает УЦ по централизованной схеме это более чем смело.
А по поводу извлечения ключей — предлагаю просто попробовать. Возьмите (если у вас есть к ним доступ) ключи в вашей организации и попробуйте их скопировать :)
Я думаю после этого вы посмотрите на проблему под другим углом.
Уважаемый коллега, из КРИПТО-ПРО, согласен что аббревиатура ФКН это «ваше изобретение» (в хорошем смысле)
Когда писал статью, долго думал как назвать «токены с не извлекаемым ключом» по науке. Вы в своих статьях упоминаете термины «активный вычислитель» и др., на мой взгляд предлагаемые термины немного сложны для понимания не криптографам.
С другой стороны Функциональный ключевой носитель (ФКН) — сообщает базовые характеристики устройства:
— выполнение функций,
— хранение ключа.
Другое дело в том, что ваша реализации ФКН, возможно более продвинутая по сравнению с другими (ФКН от КРИПТО-ПРО, обеспечивает защиту канала связи между токеном и ЭВМ).
Таким образом термин ФКН на мой взгляд наиболее удачен в данном случае.
Давайте еще раз разберемся в чем разница между «не экспортируемым» ключом и «неизвлекаемым».
Например вы сгененрировали ключ и поставили галку что ключ неэкспортируемый. Что это значит? А значит это, то что средствами СКЗИ его скопировать не получиться. Но когда выполняется подпись документа, ключ с токена копируется в память ЭВМ, где обрабатывается криптопровайдером, Основной баг этой схемы в том, что ключ может быть похищен из ОЗУ.
Галочку что ключ «не экспортирумый» можно поставить и при генерации ключа на обычном токене, для этого необязательно покупть более дорогой токен с «неивзлекамым ключом».
Теперь рассмотрим неизвлекаемые ключи. В этой схеме ключи, хранящиеся на токенах никогда не подают в память ЭВМ все криптографические операции связанные с использованием ключа выполняются сугубо на токене. Таким образом ключ скоприровать невозможно.
В этом принципиальное отличие.
Суть статьи в том, что вы берете устройство — токен, заходите на сайт производителя, там везде токен с неизвлекаемым ключом это очень круто, безопасно и т.д. (с чем я согласен :)
Берете свое СКЗИ используете этот токен — СКЗИ работает, файлы подписываются, и у вас может сложится ложное мнение о том, что ваша схема — это схема с ФКН, но на самом деле нет.
На примере JaCarta — http://aladdin-rd.ru/catalog/jacarta/gost/specification. В ней исползуется чип — http://pdf1.alldatasheet.com/datasheet-pdf/view/255626/ATMEL/AT90SC25672RCT.html
Автор, подскажите… какой именно функционал содержит апплет в аппаратной части?
Про функционал не подскажу, этот вопрос лучше адресовать производителям токенов. Неплохая документация по токенам — http://dev.rutoken.ru/
Точнее: можно ли с помощью него реализовать шифрование ГОСТ без установки ГОСТ-криптобиблиотек непосредственно на рабочую станцию.
В общем случае так сделать нельзя. Прикладное ПО (например, MS outlook) обращается к крипторафическим библиотека по какому либо стандартному интерфейсу, например MS CryptoAPI. Для того чтобы этот интерфейс был доступен и нужны криптопровайдеры. НО. Можно пойти по пути как сделал КриптоАРМ. Они умеют самостоятельно общаться с токеном, фактически реализуя встроенную криптобиблиотеку.
УЦ — обычно применяют распределенную схему генерации ключей. В данной схеме они ожидают от нас запрос на сертификат + подписанные бумажки, после получения которых они выпускают сертификат. Генерацию ключей и размещение их на носителях осуществляет пользователь.
Но когда вы «покупаете подпись», то вам скорее всего понадобятся СКЗИ и токены, вот здесь и проявляют себя продавцы в полную силу и начинают продавать то, что вам не надо.
Рассмотрим типовой функционал АПМДЗ
1. Про функционал генератора случайных чисел писал — это ок.
2. Контроль целостности. Да АПМДЗ контролирует целостность файлов, хорошо ли плохо вопрос немного другой, но контролирует он ее только в момент перезагрузки системы. А как часто у вас перезагружаются prod. сервера?
То есть пратическая ценность этого функционала близка к 0.
3. Позволяют блокировать загрузку со съемных носителей (CD, floppy,...). Опять таки, как часто перезагружается сервер?
4. Позволяют осуществлять аутентификацию пользователей в момент загрузки по идентификаторам. Опять момент загрузки.
5. АПДМЗ по документации должны подключаться в разъем Reset на мат. плате компа. Много у серверов разъемов Reset?
6. АПМДЗ могут хранить ключи шифрования. Возможно это и будет удобно, но есть другие хранилища — токены, которые не хуже.
Недостатки:
1. Применение BMC, таких как ILO, IPMI с АПМДЗ неоднозначно.
2. Чистый АПМДЗ легко обойти, достаточно вынуть девайс из компа. Исключение составляют замки с шифраторами от АНКАД, но они настояльно дорогие, что мне ни разу не удалось убедить из купить.
Резюме. АПМДЗ создавались во времена DOS. Тогда их функционал нес практическую ценность. Сейчас нужны другие системы.
Удостоверяющий центр Федерального казначейства ведет прием документов на изготовление ключей. Подходит дедушка, приносит документы и флешку.
Оператор УЦ смотрит флешку и говорит, у вас вместо запросов на сертификат на флешки лежат закрытые ключи.
Дед — А какая разница?
Я бы не был столь категоричен. Все завист от стоимости данных, которые защищены ключом. Например, если ключ от корр. счета Банка, на котором лежит несколько ярдов, то стоимость перехвата в данном случает будет зависит от стоимости приемника.
Широкополосник Rohde & Schwarz, который будет уметь такое стоил порядка 0,5 млн евров. Самопал на USRP существенно дешевле.
Из полезных свойств аппаратного модуля довереной загрузки (АМДЗ) в данном случае является только генератор случайных чисел, все остальное очень натянуто и не выдерживает критики.
Уточним. VIPNET CSP не может работать с ключевыми контейнерами сформированными КриптоПРО CSP, Но вы без проблем можете подписать запрос на сертификат сгенерированный из VIPNET CSP с помощью УЦ работающего на КриптоПРО CSP.
Поэтому тут вопрос скорее к Росстандарту и ФСБ России о том, что необходимо стандартизировать формат ключвых контейнеров.
Я бы сказал тут дело привычки. Поднять TLS на IIS+КриптоПРО CSP (серверный вариант) у меня занимало порядка 2-3 минут. Под *nix было сложнее.
В остальном согласен, за исключением цены — «Лицензия на право использования СКЗИ „КриптоПро CSP“ версии 3.9 на сервере 30 000,00р.», но тоже дороговато.
Проблема наших СКЗИ в том, что их преимущества для пользователей не очевидны.
По криптографии (взлом криптоалгоритма, баги криптосхем и т.д.) информационные системы ломают крайне редко, поэтому для обычного пользователя что отечественная библиотека СКЗИ, что импортная обеспечивают сравнимый уровень защиты, но в тоже время отечественные системы стоят денег, и порой довольно больших.
Более того, сама система использования отечественных СКЗИ — сертификация, реализация требований документации, и нормативки, например ФАПСИ 152 превращает все это просто в кошмар.
Игра с «экспортируемым» и «не экспортируемым» ключом справедлива практически для любых криптопровайдеров, что наших, что импортных. Можете ее легко повторить на чистой Windows.
Токены не являются чисто российским изобретением и применяются в том числе и за бугром. Более того и наши и импортные токены реализуют один стандарт — ISO/IEC 7816 + вариации, поэтому утверждать что наши токены хуже, не совсем корректно.
Только вот покупать токен, который позиционируется как токен с не извлекаемым ключом для этих целей (простановки галки «не экспортируемый» не нужно. Ровно тот же функционал вы получите не обычных токенах, которые стоят уверено дешевле.
Поясню. Вы взяли обычную флешку за 300 рублей, начали сгенерировали на ней ключ, поставили галку «не экспортируемый». Все, штатными средствами скопировать нельзя. Но не кто не отменял «Проводник Windows».
В случае токенов ситуация точно такая же.
Но если хочется чтоб ключ действительно нельзя было скопировать, то нужно использовать тот софт и те токены, что описаны в конце статьи, а не тот, что обычно втюхивают продавцы.
А в чем координальное отличие? Вместо CSP будет требоваться OpenSSL, один cliet-side софт меняется на другой.
Утверждать что OpenSSL более безопасный чем тот же КриптоПРО CSP считаю не корректным. Надо сравнивать по моделям угроз и ТЗ систем для которых применяется СКЗИ.
В тоже время если вопрос в деньгах, то можно использовать бесплатный криптопровайдер VIPNET CSP или бесплатную версию КриптоПРО CSP (она становится таковой, когда заканчивается триал) правда у нее нет возможности формировать ЭП, можно только проверять.
Цель статьи как раз и было показать, что то ПО которое обычно продает УЦ не позволяет достичь тех характеристик, которые работники УЦ заявляют при продаже.
Отмечу, что рассматривается ситуация, когда нарушителю известны пароли и другая аутентификационная информация (например, брелки iButton и др.) используемая для защиты ключей от НСД.
На текущий момент, подобную защиту вы сможете обеспечить только если применяется честная схема с ФКН и (или) применяются HSM.
В типовой конфигурации УЦ используют следующие ключи:
1. Ключ самого УЦ или как он раньше назывался ключ уполномоченного лица удостоверяющего центра.
В типовом случае хранится в реестре CA (ФСБ в тоже время требует, чтобы использовался отчуждаемый носитель), для защиты применяют АПМДЗ Соболь или Аккорд. По хорошему должен хранится в HSM. Копирование ключа (если не используется HSM) возможно следующими способами:
— при наличии аутентификационной информации (паролей, идентификаторов iButton и др.) штатными средствами СКЗИ;
— при доступе к резервных копиям УЦ.
— из оперативной памяти, при наличии возможности запуска кода с правами Local System;
— из файла подкачки.
— при совершении сервисного обслуживания техники.
Если ключ хранится на отчуждаемом носителе (не ФКН) в сервной, то копирование возможно способами как указано далее.
2. Ключи авторизации работников УЦ. Данные ключи используются для авторизации персонала при осуществлении доступа к критически важным функциям таким как выпуск сертификата, заведение нового пользователя, отзыв сертификата, выпуск CRL и т.д. Как правильно данные ключи хранятся на «обычных» токенах, защищенных паролем + используется СКЗИ, от производителя УЦ.
Скопировать возможно следующими способами:
1. Штатными средствами СКЗИ (при наличии паролей от токенов)
2. Путем предвартиельного получения пароля от токена: соц. инжинирия, трояны.
3. Путем перехвата ключа в канале связи между компом и токеном: usbCAP, трояны
3. Инфраструктуре ключи, например ключи для организации TLS до Web-интефрейса УЦ. Обычно хранятся в реестре или в файлах. Способы копирования перечислены выше.
4. Ключи пользователей УЦ. Здесь я надеюсь, что у вас хранятся только открытые ключи. Хранение закрытых ключей на стороне УЦ дискредитирует всю схему PKI.
Ну и наконец универсальный способ (без принятия мер защиты) копирования любых ключей — side channel атаки, включая применение СТС (специальных технических средств негласного съема информации) и всеми горячо нелюбимый ПЭМИН.
Поэтому утверждение что в вашем УЦ нельзя скопировать ключи — довольно смелое :), корректней было бы сказать, что злоумышленник обладающий суммой X-рублей не сможет скопировать у вас ключи.
P.S. Кроме это по мимо ключей УЦ вы наверняка еще пользутесь услугами дистанционного банковского обслуживания Интернет Клиент-Банк, а это отдельная песня.
Галкой «неизвлекамый» — вы наварено называете «не экспортируемый». Стоит отметить, что наличие данной галки — обрабатывается только СКЗИ. А это значит, что если ключевая информация доступна в обход СКЗИ (например, ключ хранятся на флешке или в реестре), то она может быть успешно скопирована не смотря на галку.
Таким образом, ответить на ваш вопрос о возможности копирования ключей, для которых стоит галка «не экспортируемый» можно следующим образом:
— Если к ключевой информации можно обратится в обход СКЗИ, то не смотря на эту галку их скопировать можно.
Применительно к токенам обходные маневры расписаны в статье
А по централизованной схеме, кто во что горазд.
У меня лично был опыт, когда при генерации ключа для ДБО ИКБ меня пустили за компьютер офицера безопасности Банка, ответственного за генерацию ключей, хотя в Банке я был впервые. Поэтому утверждать, что там делает УЦ по централизованной схеме это более чем смело.
А по поводу извлечения ключей — предлагаю просто попробовать. Возьмите (если у вас есть к ним доступ) ключи в вашей организации и попробуйте их скопировать :)
Я думаю после этого вы посмотрите на проблему под другим углом.
Когда писал статью, долго думал как назвать «токены с не извлекаемым ключом» по науке. Вы в своих статьях упоминаете термины «активный вычислитель» и др., на мой взгляд предлагаемые термины немного сложны для понимания не криптографам.
С другой стороны Функциональный ключевой носитель (ФКН) — сообщает базовые характеристики устройства:
— выполнение функций,
— хранение ключа.
Другое дело в том, что ваша реализации ФКН, возможно более продвинутая по сравнению с другими (ФКН от КРИПТО-ПРО, обеспечивает защиту канала связи между токеном и ЭВМ).
Таким образом термин ФКН на мой взгляд наиболее удачен в данном случае.
Давайте еще раз разберемся в чем разница между «не экспортируемым» ключом и «неизвлекаемым».
Например вы сгененрировали ключ и поставили галку что ключ неэкспортируемый. Что это значит? А значит это, то что средствами СКЗИ его скопировать не получиться. Но когда выполняется подпись документа, ключ с токена копируется в память ЭВМ, где обрабатывается криптопровайдером, Основной баг этой схемы в том, что ключ может быть похищен из ОЗУ.
Галочку что ключ «не экспортирумый» можно поставить и при генерации ключа на обычном токене, для этого необязательно покупть более дорогой токен с «неивзлекамым ключом».
Теперь рассмотрим неизвлекаемые ключи. В этой схеме ключи, хранящиеся на токенах никогда не подают в память ЭВМ все криптографические операции связанные с использованием ключа выполняются сугубо на токене. Таким образом ключ скоприровать невозможно.
В этом принципиальное отличие.
Суть статьи в том, что вы берете устройство — токен, заходите на сайт производителя, там везде токен с неизвлекаемым ключом это очень круто, безопасно и т.д. (с чем я согласен :)
Берете свое СКЗИ используете этот токен — СКЗИ работает, файлы подписываются, и у вас может сложится ложное мнение о том, что ваша схема — это схема с ФКН, но на самом деле нет.
Проблема в том, что описываемый в статье случай, это что-то из разряда ввода потребителя в заблуждение.
На примере JaCarta — http://aladdin-rd.ru/catalog/jacarta/gost/specification. В ней исползуется чип — http://pdf1.alldatasheet.com/datasheet-pdf/view/255626/ATMEL/AT90SC25672RCT.html
Про функционал не подскажу, этот вопрос лучше адресовать производителям токенов. Неплохая документация по токенам — http://dev.rutoken.ru/
В общем случае так сделать нельзя. Прикладное ПО (например, MS outlook) обращается к крипторафическим библиотека по какому либо стандартному интерфейсу, например MS CryptoAPI. Для того чтобы этот интерфейс был доступен и нужны криптопровайдеры. НО. Можно пойти по пути как сделал КриптоАРМ. Они умеют самостоятельно общаться с токеном, фактически реализуя встроенную криптобиблиотеку.
УЦ — обычно применяют распределенную схему генерации ключей. В данной схеме они ожидают от нас запрос на сертификат + подписанные бумажки, после получения которых они выпускают сертификат. Генерацию ключей и размещение их на носителях осуществляет пользователь.
Но когда вы «покупаете подпись», то вам скорее всего понадобятся СКЗИ и токены, вот здесь и проявляют себя продавцы в полную силу и начинают продавать то, что вам не надо.